New student in C++ with Linux/Windows question

[awsdert]

The portability of it depends on the compiler being modern enough, sometimes there is a reason for going with the old ones or going with super strict settings, but enough about that popojoe didn't start the thread for us to have a heated debate, instead let's just agree to disagree since we've debate it enough for him to make his own decision on the matter.

[cire]

The portability of it depends on the compiler being modern enough, sometimes there is a reason for going with the old ones or going with super strict settings,

I guess it's a good thing not many share your viewpoint, or we would all be eschewing C++98/03/11/14 in favor of "portable" pre-standard code.

[vlad from moscow]

@awsdert

it is better to develop good habits then it is to develop bad habits and then correct them later when the compiler screams at you for doing so.

I do no see bad habits. I see your lack of knowledge of C++.

[awsdert]

Just because I might not use a particular method does not mean I do not know it (although on this particular occasion it was a correct assumption), however that alone does not necessarily invalidate my statement.

As far as I'm aware it is considered good practice for developers to expect the unexpected, which actually makes my statement all the more true, if C++ did not inherit from C then yes I could agree that it was an acceptable habit but as it does I think it is better to just go with stricter habits then optimize later if the option is available.

[vlad from moscow]

@awsdert
if C++ did not inherit from C then yes I could agree that it was an acceptable habit but as it is not I think it is better to just go with stricter habits then optimize later if the option is available.

It is not some feature only of C++. The same valid in C. And it is not unexpected behaviour because function main is a special function of C/C++. So it is not clear what bad habits you are speaking about.

[andywestken]

Apparently the return-0-if-you-don't-expliclty-return-a-value is a new fangled feature introduced in C99. For C89 (aka C90), the standard states that the return value is undefined if you either do not return or you return nothing (i.e. return;.)

(I expect a lot of compilers did behave "nicely", as putting special case code into the C runtime which returned 0 when linked to C++ code but random junk for C would of have been pretty pointless. But it wasn't enforced by the C standard.)

I have to admit that I'm a "return-ist". I always use an explicit return in main, even though I know (and have known for some time) that it's an exception to the rule.

But that's the point. I believe that you should write in as consistent a way as possible, and that not returning from main means you have to make them a special case (unnecessarily; as nothing goes wrong if you return 0, obviously.) As main functions make up a very small percentage of the functions I write (unlike an absolute beginner, I guess?) it's easier for me to just code them just like any other int-returning function. So I don't have to worry about forgetting to onit the return.

Personnally I thing Strustroup made the wrong call in this case. It would have been much better to have just made not returing from main an error as that would have made everything nice and consistent.

Andy

[awsdert]

Thanks for a more helpful explanation of the behavior, I tend to try and develop for the more popular compilers yet at the same time keep the less common in mind. I would consider myself a novice still but I am now making my own framework in c89/c90 (because of VC not supporting beyond that), part of the reason I'm doing this is because other frameworks I've tried lack some of what I need, the other part is to start developing some better habits, and finally so I have some headers that bypass a lot of problems I encounter when I try to do things from scratch.