Why I'm now trailing main's int

[Frederick Gotham]

I now write the entry point to my C++ programs like this:

auto main(void) -> int
{

}

auto main(int argc, char **argv) -> int
{

}

for two reasons:

(1) I know it won't go through a C compiler
(2) I know the compiler is C++11 or above

[Bonita Montero]

When you think that's a substantial problem when programming
C++ drop the idea to program at all.

[Frederick Gotham]

On Friday, October 4, 2019 at 2:14:53 PM UTC+1, Bonita Montero wrote:

> When you think that's a substantial problem when programming
> C++ drop the idea to program at all.

It's up there with memset taking an int, and flipping the bits on an unsigned char after integer promotion

[Bonita Montero]

>> When you think that's a substantial problem when programming
>> C++ drop the idea to program at all.

> It's up there with memset taking an int, and flipping the bits on an unsigned char after integer promotion

Where's the problem?

[David Brown]

On 04/10/2019 15:08, Frederick Gotham wrote:
>
> I now write the entry point to my C++ programs like this:
>
> auto main(void) -> int
> {
>
> }
>
> auto main(int argc, char **argv) -> int
> {
>
> }
>
> for two reasons:
>
> (1) I know it won't go through a C compiler

I know my C++ code doesn't go through a C compiler because I use a C++
compiler to compile it.

If I were writing code that could be compiled as C or C++, and which I
was spreading around to people who don't have control of their build
processes, but I want to be sure it is never compiled as C, I'd add:

#ifndef __cplusplus
#error This code must be compiled as C++
#endif

> (2) I know the compiler is C++11 or above
>

I know my code is compiled with the required standard because I specify
it on the command line, in my makefile.

The main reason I would care about the standard version is because I use
features from a particular standard version. I see no point in doing
this artificially - if it makes sense to use a C++11 feature in your
code, use it.

And if I really require specific checking (as there are some subtle
changes in the versions, with code being valid but with different
meanings in different C++ versions), then I'd write:

#if __cplusplus < 201103
#error This code requires C++11 or newer
#endif


Write what you mean, and give clear, obvious error messages so there is
no doubt what has happened when someone has trouble compiling the code.
You really don't want people to fail to compile the code just because
you have written "auto main(void) -> int" - they will not judge you kindly.

[Frederick Gotham]

On Friday, October 4, 2019 at 2:30:34 PM UTC+1, David Brown wrote:

> Write what you mean, and give clear, obvious error messages so there is
> no doubt what has happened when someone has trouble compiling the code.
> You really don't want people to fail to compile the code just because
> you have written "auto main(void) -> int" - they will not judge you kindly.

But there's also the third reason

[Scott Lurndal]

What's that? Baiting the cognoscenti?

[Frederick Gotham]

On Friday, October 4, 2019 at 2:59:01 PM UTC+1, Scott Lurndal wrote:

> >But there's also the third reason
>
> What's that? Baiting the cognoscenti?

You have to admit it looks pretty damn cool, especially if you're been writing "int main" for a decade or two or three.

[Scott Lurndal]

Frankly if I was interested in verbosity, I'd program in COBOL :-)

int main(int argc, const char **argv) is just fine.

[Frederick Gotham]

On Friday, October 4, 2019 at 3:43:47 PM UTC+1, Scott Lurndal wrote:

> int main(int argc, const char **argv) is just fine.

That's as bad as using a C-style cast instead of static_cast

[Alf P. Steinbach]

On 04.10.2019 15:30, David Brown wrote:
> #if __cplusplus < 201103
> #error This code requires C++11 or newer
> #endif

Visual C++ 2019 doesn't support C++11 and newer values of `__cplusplus`
by default, and at some point not too far back earlier versions simply
didn't support it at all. g++ will generally go on to produce an
avalanche of diagnostics after the `#error`. I.e. the offered snippet
may work in theory, but it doesn't work well in practice.

One workaround for the Visual C++ 2019 behavior is to supply the
(obscure) `/Zc:__cplusplus` option that sets `__cplusplus`.

One workaround for the g++ behavior is to add an `#include` of a
non-existing header, which stops compilation:

#if !SOMETHING
# include "this_code_requires_something.oops"
#endif


- Alf

[Keith Thompson]

Why the added "const"? I know it prevents accidental modifications
to the argument strings, but it's not one of the forms specified
by the standard. It's unlikely that the added "const" would cause
any problems, but personally I prefer to stick to what the standard
actually guarantees. (Adding the "const" probably makes demons
fly out of your nose on the DS9K.)

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Scott Lurndal]

Keith Thompson <ks...@mib.org> writes:
>sc...@slp53.sl.home (Scott Lurndal) writes:
>> Frederick Gotham <cauldwel...@gmail.com> writes:
>>>On Friday, October 4, 2019 at 2:59:01 PM UTC+1, Scott Lurndal wrote:
>>>> >But there's also the third reason
>>>>
>>>> What's that? Baiting the cognoscenti?
>>>
>>>You have to admit it looks pretty damn cool, especially if you're been
>>>writing "int main" for a decade or two or three.
>>
>> Frankly if I was interested in verbosity, I'd program in COBOL :-)
>>
>> int main(int argc, const char **argv) is just fine.
>
>Why the added "const"? I know it prevents accidental modifications
>to the argument strings, but it's not one of the forms specified
>by the standard. It's unlikely that the added "const" would cause
>any problems, but personally I prefer to stick to what the standard
>actually guarantees. (Adding the "const" probably makes demons
>fly out of your nose on the DS9K.)

As you say, to prevent accidental modifications to the argument
strings (at least one standalone implementation I used protected the
argument strings by placing them in read-only memory).

[Mr Flibble]

You neglected to mention the fourth reason: you're a fucktard.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[David Brown]

On 04/10/2019 18:56, Alf P. Steinbach wrote:
> On 04.10.2019 15:30, David Brown wrote:
>> #if __cplusplus < 201103
>> #error This code requires C++11 or newer
>> #endif
>
> Visual C++ 2019 doesn't support C++11 and newer values of `__cplusplus`
> by default, and at some point not too far back earlier versions simply
> didn't support it at all.

Really? I never use MSVC, so I must accept your word for that. People
have been writing:

#ifdef __cplusplus
extern "C" {
#endif

at the start of header files for decades, so that they can be used in C
and C++ compilation. Are you telling me that hasn't worked for MSVC
until recently?

> g++ will  generally go on to produce an
> avalanche of diagnostics after the `#error`.

Sure. But they'd get that avalanche anyway - the only difference is the
message at the beginning (and the guarantee that the compilation will
fail, even if the other messages were warnings rather than errors). The
normal reaction to an avalanche of errors is to look for clues in the
first one. (This is especially easy if you use an IDE or smarter editor.)

> I.e. the offered snippet
> may work in theory, but it doesn't work well in practice.

It seems to me that it would work fine in practice, except perhaps with
MSVC.

>
> One workaround for the Visual C++ 2019 behavior is to supply the
> (obscure) `/Zc:__cplusplus` option that sets `__cplusplus`.

I'll remember that (whether I want to or not - it's the kind of obscure
thing that sticks in my mind).

>
> One workaround for the g++ behavior is to add an `#include` of a
> non-existing header, which stops compilation:
>
>    #if !SOMETHING
>    #  include "this_code_requires_something.oops"
>    #endif
>
>

That is a neat trick for a "fast fail". I'll remember that too -
thanks. (But I'll put the #error directive before the #include.)

[Bo Persson]

On 2019-10-05 at 13:00, David Brown wrote:
> On 04/10/2019 18:56, Alf P. Steinbach wrote:
>> On 04.10.2019 15:30, David Brown wrote:
>>> #if __cplusplus < 201103
>>> #error This code requires C++11 or newer
>>> #endif
>>
>> Visual C++ 2019 doesn't support C++11 and newer values of
>> `__cplusplus` by default, and at some point not too far back earlier
>> versions simply didn't support it at all.
>
> Really?  I never use MSVC, so I must accept your word for that.  People
> have been writing:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> at the start of header files for decades, so that they can be used in C
> and C++ compilation.  Are you telling me that hasn't worked for MSVC
> until recently?
>

This bit has worked all along. The question is what *value* the macro is
set to.

Apparently having indicated C++98 for 20 years will break some code if
it "suddenly" changes to a different value.

All sorted out in this blog post:

https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/

[James Kuyper]

Using a C-style cast when a static_cast<> should be able to do what you
intend to do, has the disadvantage that it can do a great many things
that a static_cast<> can't, and you will therefore fail to get the
warnings that a C++ implementation is required to give you if you try to
use static_cast<> to do one of those things.

What is the corresponding disadvantage of using that syntax?

You give the strong impression of using the newer syntax in a context
where it isn't needed, solely for the reason that it's new. That's not a
sufficiently good reason to criticize other peoples decision to do
otherwise. It's not the reason that C++'s named casts are preferred over
C-style casts.

[Öö Tiib]

On Saturday, 5 October 2019 00:24:59 UTC+3, Mr Flibble wrote:
> On 04/10/2019 15:30, Frederick Gotham wrote:
> > On Friday, October 4, 2019 at 2:59:01 PM UTC+1, Scott Lurndal wrote:
> >
> >>> But there's also the third reason
> >>
> >> What's that? Baiting the cognoscenti?
> >
> > You have to admit it looks pretty damn cool, especially if you're been writing "int main" for a decade or two or three.
>
> You neglected to mention the fourth reason: you're a fucktard.

It takes one to know one. ;)

[Öö Tiib]

On Saturday, 5 October 2019 14:00:27 UTC+3, David Brown wrote:
> On 04/10/2019 18:56, Alf P. Steinbach wrote:
> > On 04.10.2019 15:30, David Brown wrote:
> >> #if __cplusplus < 201103
> >> #error This code requires C++11 or newer
> >> #endif
> >
> > Visual C++ 2019 doesn't support C++11 and newer values of `__cplusplus`
> > by default, and at some point not too far back earlier versions simply
> > didn't support it at all.
>
> Really? I never use MSVC, so I must accept your word for that. People
> have been writing:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> at the start of header files for decades, so that they can be used in C
> and C++ compilation. Are you telling me that hasn't worked for MSVC
> until recently?

That did work but the value of __cplusplus was always 199711L.
Projects that use previous versions of VC as one of targets have
to check value of MS-specific macro (_MSC_VER) to do detailed
workaround of quirks and annoyances in those. VC++2003, VC++2005,
VC++2008 and VC++2010 were all supposed to support C++03 but
did it in slightly different ways. Some Boost library headers are
still quite full of such checks I trust.