Hello. I would like to start a thread with some noobs' questions. I ask myself about these points, promising to myself to do some search, and finally I forget them. I post these questions with just a few words. This way it's clear. If you have a short answer, it's better. Let's go!
PS : maybe this question could be debated in other section like Lounge...

1° Is there a difference for incrementation or decremention using these alternatives :
i++ or ++i
i-- or --i

2° They say that only noobs use using namespace std;

3° They say that using std::endl is a bad practice. Use instead \n. Why?

4° They say, don't use any system() command. It sucks. Why?

5° Macro is evil! Why?

6° printf or std::cout?

1. Used by itself, no difference. Used in an expression has side effects.
2. True
3. Not necessarily. Depends on local standards,
4. Opportunity for malware to creep in.
5. Not necessarily. Hides code. Can be convenient.
6. printf for C. cout for C++.

1. Yes. i++ is post-increment. This means that it returns as value the value of i before the increment using a copy. ++i is pre-increment. It increments i and then returns the new value as a ref without doing a copy. Unless you're using in an assignment and require post-inc, use ++i to avoid the copy - although not really significant until you use with a class with a non-trivial copy. Similar for pre/post decrement.

2) Yes.

3) std::endl first does a flush. \n doesn't. Not really important for std::cin but can have an effect when used with other streams (eg std::sstream, std::fstream etc)
https://stackoverflow.com/questions/213907/stdendl-vs-n

4) You have no idea what command is going to be executed. Which command depends upon the local PATH environment variable. Also there is no feedback re errors etc etc.
https://stackoverflow.com/questions/19468578/whats-so-bad-about-system

5) See https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives

6) printf() is part of c library. C++ has std::cout (and from C++20 std::format). But note that snprintf() can be useful if dealing with c-style strings instead of strcpy().

Concises and amazing answers which are really helpful. Thanks everyone ++

as for how you write text in a console, note that most programs are not console spew anymore. You may work on some, and certainly for personal or internal or back end uses, but the majority of projects and programs are going to have a GUI for most coders these days, and cout vs printf are not even a consideration, nor is endl.

Console is just another file device, and you will always need to know how to read from and write to file.

And many, many utilities still use stdin/stdout as their primary I/O — especially transformational utility programs. Knowing how to manage an I/O stream is never going to go out of style.

The console/terminal helps you learn by providing very direct, immediate feedback. Don’t discount it.

Fair enough. I don't think I have written a file at work that way in a long, long time either, but you are right to point it out.

Ok good to know that using using namespace std is for noobs.

what about:



instead of

std::cout and std::endl; in the whole program text. Is is still a nooby style?

@seeplus:

"std::endl first does a flush"

, what is a flush?

ninja01 wrote:
Ok good to know that using using namespace std is for noobs. what about: 1 2 using std::cout; using std::endl; instead of std::cout and std::endl; in the whole program text. Is is still a nooby style?

I'm going to copy the text I wrote in response to a very similar question on another forum some time ago:

In order to avoid naming conflicts with other code (remember new names are added in each new version of C++) all names in the standard library (except for a few exceptions) are part of the std namespace. That's why you have to write std::cout, std::cin, etc. You can do using std::cout; and then you can write cout without std::. This is fine from a name clashing point of view, but in my opinion it's not worth it. You would have to maintain lists of such names everywhere and have to think what names are in the list, should I add this name to the list, is this name still in use or can I remove it from the list? For me it's just easier to write std:: everywhere. I actually think std:: makes the code easier to read. It makes it clear what names are from the standard library. This is especially true if I read someone else's code because I don't have to wonder if for example max(a, b) calls std::max or if it's some function that the author wrote himself. I can understand if you prefer to use using namespace std; and I don't think it's the end of the world if you do use it. Beginners often use the standard library on almost every line and have few own functions and classes to confuse it with. However, in a larger program the standard library names are often less dominant, with lots of functions and types that have been created in the project or come from libraries other than the standard library, so std:: becomes less of a distraction and more of a useful info tag.

ninja01 wrote:
what is a flush?

Streams are often "buffered", meaning that instead of writing the output to the destination straight away they often store it in a buffer so that they can write more at once later. This is often better for performance and for the terminal it can also help reducing flickering (partial output being displayed).

Flushing means all the data that is stored in the buffer is written to the destination. After this the buffer will be empty.

Some streams automatically flush at the end of lines (std::cout usually do this unless you call std::ios::sync_with_stdio(false);) but otherwise flushing normally happens when the buffer is full or when it is explicitly flushed using something like std::flush or std::endl.

Note that std::cout and std::cin are tied so you normally don't need to flush when using these in combination. Using std::cin will automatically flush std::cout.

Some people argue that you should not use std::endl because you normally don't need a flush, and if you want to flush you should be explicit about it and use std::flush instead.

This is often better for performance and for the terminal...

. I hear the word terminal a lot, in my mind there is only one image: The terminal is a screen of a monitor, am I right?

Are there other terminals?

I guess what we use today are more accurately described as "terminal emulators", because they are not real terminals.
https://en.wikipedia.org/wiki/Terminal_emulator

What I mean is essentially a "console window".

On Windows it's called the "command prompt".

On Linux and other unix-like systems it's normally called "terminal".

@Peter87 I like both your replies. Thanks)

jonnin wrote:
the majority of projects and programs are going to have a GUI for most coders these days

Duthomhas wrote:
Console is just another file device, and you will always need to know how to read from and write to file. And many, many utilities still use stdin/stdout as their primary I/O — especially transformational utility programs. Knowing how to manage an I/O stream is never going to go out of style.

Indeed. To me, GUI is an abomination. I want programs that do compute. In HPC cluster that has no support for any GUI. No "terminal emulator" for the process either, because the jobs are started by scheduler somewhere at some time. The scheduler pipes stdout and stderr to files for convenience.

Granted, "majority of projects" might be for mobile phones these days, but even those do read some files?

2. They say that only noobs use using namespace std;

Preliminary draft of my "don't have 'using namespace std;' in C++ code" boilerplate:

https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice There are possible risks involved with having the using namespace std; directive in your code, risks that usually are not mentioned when learning C++. C++ Core Guidelines, SF6 & SF7: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-using Read the explanatory text before and after the SF6 sample. Having the using namespace std; directive in code is not an error. The people who have it in their code presumably know the risks. Do you know what can happen? It was originally supposed to be used with older C++ code that didn't have standard library namespaces and make it easier to transition that legacy code to newer C++ language versions. There are now safer C++ ways that are less likely to have risks, using declarations. https://www.learncpp.com/cpp-tutorial/using-declarations-and-using-directives/ There are a few select features of the C++ stdlib that require a using declaration to activate the desired feature. {need an example, fer shure} A popular 3rd party library, Boost, is multiple namespace structured that not having namespace declarations for the library is a pain with lots of repetitive typing that can get mistyped. The C++ Core Guidelines are suggestions, not "you must do this" requirements. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#SS-aims Personally I never have the using directive in my code, ever. I prefer to prefix std:: when using C++ stdlib features. Now it is automatic typing std::. I actually have to stop and think to NOT use it. I do have using declarations on occasions, though I try to use them very sparingly. On a case by case basis, mostly when using a C++/3rd party library feature buried in a namespace morass.

Addendum: using declarations are IMO just as much a nooby hack as the using directive. So you save a couple of characters when typing. When explicitly typing std:: (or boost:: or rtk::, etc.) every time I know what library I am using. The code self-documents itself.

5. Macro is evil! Why?

Using macros are more of a "bad practice" instead of being declared evil, they should be the last resort whenever possible. C++ has alternatives that preserve type safety, macros don't.

https://www.linkedin.com/pulse/why-considered-bad-practice-use-macros-c-herbert-elwood-gilliland-iii

3. They say that using std::endl is a bad practice. Use instead \n. Why?

It depends.

'\n' simply adds a newline character to the output buffer. std::endl inserts a newline character into the output buffer and also flushes the buffer so the pending data is written to the device. The console/terminal screen, file, etc.

Flushing the output buffer is an expensive I/O process, and can be costly in terms of time as well.

https://stackoverflow.com/questions/4751972/endl-and-flushing-the-buffer

Using std::endl exclusively instead of '\n' is not an error, Using std::endl shows the programmer isn't concerned about possible I/O and/or timing issues.

For most console/terminal based programs, C or C++, that isn't really a major issue. But it is something to remember when "why does my program run so slow?" issues happen.

For me it is more of a style issue. Repeatedly typing std::endl (or endl with a using directive/declaration) is more of a PITA than typing '\n'. Especially when outputting a string constant:
std::cout << "Hello World!" << std::endl;
vs.
std::cout << "Hello World!\n";

> There are a few select features of the C++ stdlib that require
> a using declaration to activate the desired feature. (need an example)

Many standard library functions (for example, many algorithms) expect their arguments to satisfy Swappable, which means that any time the standard library performs a swap, it uses the equivalent of using std::swap; swap(t, u); https://en.cppreference.com/w/cpp/named_req/Swappable

In generic code, using std::swap(x,y); instead of using std::swap; swap(x,y); is a newbie level mistake.

JLBorges, the example I would present for a using declaration is std::literals::string_literals::operator""s:

https://en.cppreference.com/w/cpp/string/basic_string/operator%22%22s

The same "a using declaration works better" with std::literals::string_view_literals::operator""sv

the example I would present for a using declaration is std::literals::string_literals::operator""s: The same "a using declaration works better" with std::literals::string_view_literals::operator""sv

Yeah - that's the exception that proves the rule! :)