Re: Help needed

[Real Troll]

On 03/04/2020 12:38, Gerry Wolff wrote:
> I have a general problem in developing C++ programs, and I would be glad of help. Let me explain:
>
> * In 2004 to 5 I developed a largish program with no significant problems using C++ in MS Visual Studio.
>
> * Now I want to develop the program some more but I find that C++ in MS Visual Studio is very much more complicated than it was before, and very difficult to use. Many ‘errors’ get flagged in a program that was working well and I am finding it very difficult to clear them.
>
> * To be more precise, I need help with two programs: the original program and a much simpler program that I need for the new project. That second program is causing me problems as well.
>
> * It would be very helpful if someone with relevant skills could help get things working again. If you know of a better IDE, please let me know.
>
> * It would be helpful but not essential if we were both in the same time zone, or close. I’m in the UK in the GMT time zone (latitude 0).
>
> * This project is part of a long-time research program, and I would of course give credit for help with programming in papers arising from the new research.
>
> * Information about the research program may be seen on http://www.cognitionresearch.org/sp.htm, and more briefly on http://www.cognitionresearch.org/extras/key_publications.htm.
>
> * If you would be willing to help, please get in touch via j...@cognitionresearch.org. Please say something briefly about your experience with Visual C++, and the time you would have available to work on what I’ve described.
>
> Many thanks!
>
> Gerry Wolff
>

I suggest try using Embarcadero's C++ builder.  There is a community
edition that users can download free of charge.

<https://www.embarcadero.com/products/cbuilder/starter>

You could also create a free account on github and the community members
here or elsewhere can have a look at the code and suggest changes.  You
keep the control on the code that goes in the final product but
community members can make suggestions.

<https://github.com/features>

Other newsgroups are:

comp.lang.c++

You could cross-post your posts to that other group like I have done here.

[Gerry Wolff]

In case of doubt, here is the message I previously posted on alt.comp.lang.learn.c-c++.

I have a general problem in developing C++ programs, and I would be glad of help. Let me explain:

* In about 2004 to 2005, I developed a largish program with no significant problems using C++ in MS Visual Studio.

* Now I want to develop the program some more but I find that C++ in MS Visual Studio is very much more complicated than it was before, and very difficult to use. Many ‘errors’ get flagged in a program that was working well and I am finding it very difficult to clear them.

* To be more precise, I need help with two programs: the original program and a much simpler program that I need for the new project. That second program is causing me problems as well.

* It would be very helpful if someone with relevant skills could help get things working again. If you know of a better IDE, please let me know.

* It would be helpful but not essential if we were both in the same time zone, or close. I’m in the UK in the GMT time zone (latitude 0).

* This project is part of a long-time research programme, and I would of course give credit for help with programming in papers arising from the new research.

* Information about the research program may be seen on http://www.cognitionresearch.org/sp.htm, and more briefly on http://www.cognitionresearch.org/extras/key_publications.htm.

* If you would be willing to help, please get in touch via j...@cognitionresearch.org. Please say something briefly about your experience with Visual C++, and the time you would have available to work on what I’ve described.

Many thanks!

Gerry Wolff

--
Dr J. Gerard Wolff PhD CEng MIEEE MBCS
CognitionResearch.org
j...@cognitionresearch.org; +44 (0) 1248 712962, +44 (0) 7746 290775; Twitter: @gerrywolff65, Skype: gerry.wolff; Web: www.cognitionresearch.org; CognitionResearch.org, Menai Bridge, UK.

[Mr Flibble]

On 03/04/2020 17:56, Gerry Wolff wrote:
> In case of doubt, here is the message I previously posted on alt.comp.lang.learn.c-c++.
>
> I have a general problem in developing C++ programs, and I would be glad of help. Let me explain:
>
> * In about 2004 to 2005, I developed a largish program with no significant problems using C++ in MS Visual Studio.
>
> * Now I want to develop the program some more but I find that C++ in MS Visual Studio is very much more complicated than it was before, and very difficult to use. Many ‘errors’ get flagged in a program that was working well and I am finding it very difficult to clear them.
>
> * To be more precise, I need help with two programs: the original program and a much simpler program that I need for the new project. That second program is causing me problems as well.
>
> * It would be very helpful if someone with relevant skills could help get things working again. If you know of a better IDE, please let me know.
>
> * It would be helpful but not essential if we were both in the same time zone, or close. I’m in the UK in the GMT time zone (latitude 0).
>
> * This project is part of a long-time research programme, and I would of course give credit for help with programming in papers arising from the new research.
>
> * Information about the research program may be seen on http://www.cognitionresearch.org/sp.htm, and more briefly on http://www.cognitionresearch.org/extras/key_publications.htm.
>
> * If you would be willing to help, please get in touch via j...@cognitionresearch.org. Please say something briefly about your experience with Visual C++, and the time you would have available to work on what I’ve described.
>
> Many thanks!

Why can't you do it yourself? Afraid of learning new things? As you fix the errors you will learn modern C++: something that won't happen if you get someone else to do it.

/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," Byrne 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."

[Bonita Montero]

I just tried to compile your SP62-program. There are a lot assignments
of string-literals to non-const string-pointers. In C++ every string
-literal has the type "const char *"; I don't know if this has ever
been different in earlier versions of C++, but earlier versions of
MSVC accepted the assignment of string-literals to char-pointers. So
you have to make your c-strings const. And there are a lot of erors
which advise you to use safe versions of C-runtime-functions which
are not prone to buffer-overflows. You can disable this errors by
defining _CRT_SECURE_NO_WARNINGS or you could use the safer versions
the error-message shows you.

[Ned Latham]

Mr Flibble wrote:
> Gerry Wolff wrote:
> >
> > In case of doubt, here is the message I previously posted on
> > alt.comp.lang.learn.c-c++.
> >
> > I have a general problem in developing C++ programs, and I would be
> > glad of help. Let me explain:
> >
> > * In about 2004 to 2005, I developed a largish program with no
> > significant problems using C++ in MS Visual Studio.
> >
> > * Now I want to develop the program some more but I find that C++
> > in MS Visual Studio is very much more complicated than it was
> > before, and very difficult to use. Many "errors" get flagged in
> > a program that was working well and I am finding it very difficult
> > to clear them.

Versionitis; a virus that emerged out of the murk of Micro$soft.

> > * To be more precise, I need help with two programs: the original
> > program and a much simpler program that I need for the new project.
> > That second program is causing me problems as well.
> >
> > * It would be very helpful if someone with relevant skills could
> > help get things working again. If you know of a better IDE, please
> > let me know.

What you need is a stable language. Or perhaps... downgrade to the
version you know, and stay there.

A better system would help too, though if your projects need the M$
environment, you're pretty much locked in.

> > * It would be helpful but not essential if we were both in the same
> > time zone, or close. I'm in the UK in the GMT time zone (latitude 0).
> >
> > * This project is part of a long-time research programme, and I would
> > of course give credit for help with programming in papers arising
> > from the new research.
> >
> > * Information about the research program may be seen on
> > http://www.cognitionresearch.org/sp.htm, and more briefly
> > on http://www.cognitionresearch.org/extras/key_publications.htm.
> >
> > * If you would be willing to help, please get in touch via
> > j...@cognitionresearch.org. Please say something briefly about
> > your experience with Visual C++, and the time you would have

> > available to work on what I???ve described.

>
> Why can't you do it yourself?

Why assume a lack of ability?

> Afraid of learning new things? As you
> fix the errors you will learn modern C++:

C++ has become a moving target and a profligate producer of maintenance
nightmares. My own projects are okay so far, but I've had to make so
many fatuous changes that I'm now actively looking for languages to
port them to.

----snip----

[Bonita Montero]

> I just tried to compile your SP62-program. There are a lot assignments
> of string-literals to non-const string-pointers. In C++ every string
> -literal has the type "const char *"; I don't know if this has ever
> been different in earlier versions of C++, but earlier versions of
> MSVC accepted the assignment of string-literals to char-pointers.

> So you have to make your c-strings const. ...

You could set up a VC++ console project and disable conformance mode
in the project-settings. Along with the the define I told about you
would get away almost every error.
And you're using the function tzset which should be replaced with
_tzset.
And you're using a lot of uninized variables as function-parameters;
that's a lot of bugs.

[Melzzzzz]

On 2020-04-03, Ned Latham <nedl...@woden.valhalla.oz> wrote:
>
> C++ has become a moving target and a profligate producer of maintenance
> nightmares. My own projects are okay so far, but I've had to make so
> many fatuous changes that I'm now actively looking for languages to
> port them to.

Which one? C++ is backward compatible so far I see.
>
> ----snip----
Perhaps M$ compiler makes problems, but that is because that is M$...


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[James Kuyper]

On 4/3/20 1:57 PM, Ned Latham wrote:
> Mr Flibble wrote:
>> Gerry Wolff wrote:

...

>>> * Now I want to develop the program some more but I find that C++
>>> in MS Visual Studio is very much more complicated than it was
>>> before, and very difficult to use. Many "errors" get flagged in
>>> a program that was working well and I am finding it very difficult
>>> to clear them.
>
> Versionitis; a virus that emerged out of the murk of Micro$soft.

Your historical view is a bit short-sighted. Versionitis predates
Microsoft. It even predates computers - people were coming out with new
versions of things too fast for the users to keep up with them even
before computers became available to speed up the process.

...

>> Why can't you do it yourself?
>
> Why assume a lack of ability?

"... I am finding it very difficult ..." is a bit of a clue.

[Christian Gollwitzer]

Am 03.04.20 um 19:35 schrieb Bonita Montero:

I also tried to compile the SP71 program. There were only 7 real errors.
There is the idiotic for-scoping that was wrong in VC6. In VC 6, if you
write

for (int i=0; i<n; i++) { }

then the i variable belongs to the outer block, whereas in C++ since
1998 it belongs to the for block. So shift this to

int i;
for (i=0; i<n; i++) { }

to get the same effect. Then there was an default-to-int static variable
without a type; even the compiler knew how to fix it:


SP71_lib.cpp:16155:9: error: C++ requires a type specifier for all
declarations
static column_counter = 0 ;
~~~~~~ ^
1 error generated.

and a missing comma in a sequence of declarations; I wonder how that
ever could compile.

Now it compiles on clang, but with 283 warnings, of course. Here's the diff:

Apfelkiste:Tests chris$ diff -r SP_new/ SP
diff -r SP_new/SP71_head.h SP/SP71_head.h
660c660
< {symbol *s ; int i; for (i = 0; i < sequence_depth; i++)
---
> {symbol *s ; for (int i = 0; i < sequence_depth; i++)
diff -r SP_new/SP71_lib.cpp SP/SP71_lib.cpp
2347c2347
< for (int i = 1; i < start_col_2; i++)
---
> for (i = 1; i < start_col_2; i++)
12200c12200
< *t_pattern = get_row_pattern(bottom_row),
---
> *t_pattern = get_row_pattern(bottom_row)
16155c16155
< static int column_counter = 0 ;
---
> static column_counter = 0 ;
Only in SP_new/: a.out
Apfelkiste:Tests chris$


Christian

[Mr Flibble]

On 03/04/2020 21:01, Christian Gollwitzer wrote:
> Am 03.04.20 um 19:35 schrieb Bonita Montero:
>> I just tried to compile your SP62-program. There are a lot assignments
>> of string-literals to non-const string-pointers. In C++ every string
>> -literal has the type "const char *"; I don't know if this has ever
>> been different in earlier versions of C++, but earlier versions of
>> MSVC accepted the assignment of string-literals to char-pointers. So
>> you have to make your c-strings const. And there are a lot of erors
>> which advise you to use safe versions of C-runtime-functions which
>> are not prone to buffer-overflows. You can disable this errors by
>> defining _CRT_SECURE_NO_WARNINGS or you could use the safer versions
>> the error-message shows you.
>
> I also tried to compile the SP71 program. There were only 7 real errors. There is the idiotic for-scoping that was wrong in VC6. In VC 6, if you write

VC6 is NOT a C++ compiler, it is VC6 compiler.

[Jorgen Grahn]

On Fri, 2020-04-03, Ned Latham wrote:
...

> C++ has become a moving target and a profligate producer of maintenance
> nightmares. My own projects are okay so far, but I've had to make so
> many fatuous changes that I'm now actively looking for languages to
> port them to.

Which changes would that be? Between, say a decent version two
decades ago (C++98) and a well-supported one today (C++11)?

I can imagine that there have been painful changes to /Visual Studio/
during these decades, but they would be about deviations from the
standard, extensions to the language, and bugs it used to allow.
GCC had that last kind, too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ned Latham]

Melzzzzz wrote:
> On 2020-04-03, Ned Latham <nedl...@woden.valhalla.oz> wrote:
>>
>> C++ has become a moving target and a profligate producer of maintenance
>> nightmares. My own projects are okay so far, but I've had to make so
>> many fatuous changes that I'm now actively looking for languages to
>> port them to.
>
> Which one? C++ is backward compatible so far I see.

GCC. C++ is *not* backwards compatible.

> Perhaps M$ compiler makes problems, but that is because that is M$...

That's a given, but in this case an element of the M$ disease has been
incorporated into C++. Thay have, and have had for decades now, undue
influence with standards committees.

[Ned Latham]

James Kuyper wrote:

> Ned Latham wrote:
> > Gerry Wolff wrote:
> ...
> > > * Now I want to develop the program some more but I find that C++
> > > in MS Visual Studio is very much more complicated than it was
> > > before, and very difficult to use. Many "errors" get flagged in
> > > a program that was working well and I am finding it very difficult
> > > to clear them.
> >
> > Versionitis; a virus that emerged out of the murk of Micro$soft.
>
> Your historical view is a bit short-sighted. Versionitis predates
> Microsoft.

Wrong. That was a different phenomenon called "planned obsolenence".

----snip----

[Ned Latham]

Jorgen Grahn wrote:
> Ned Latham wrote:
> ...
> > C++ has become a moving target and a profligate producer of maintenance
> > nightmares. My own projects are okay so far, but I've had to make so
> > many fatuous changes that I'm now actively looking for languages to
> > port them to.
>
> Which changes would that be? Between, say a decent version two
> decades ago (C++98) and a well-supported one today (C++11)?

Exception throwing: once an option, now the default.
"namespace": once an option, now a requirement.

I suppose I should confess that the bugs in C(++) are also part of my
problem with C++. They are the defective string definition in C, and
the defective post-increment semenatic of C++.

----snip----

[Ned Latham]

Sorry. "semantic".

[Ned Latham]

Sorry. "obsolescence"

[Bo Persson]

On 2020-04-03 at 22:05, Mr Flibble wrote:
> On 03/04/2020 21:01, Christian Gollwitzer wrote:
>> Am 03.04.20 um 19:35 schrieb Bonita Montero:
>>> I just tried to compile your SP62-program. There are a lot assignments
>>> of string-literals to non-const string-pointers. In C++ every string
>>> -literal has the type "const char *"; I don't know if this has ever
>>> been different in earlier versions of C++, but earlier versions of
>>> MSVC accepted the assignment of string-literals to char-pointers. So
>>> you have to make your c-strings const. And there are a lot of erors
>>> which advise you to use safe versions of C-runtime-functions which
>>> are not prone to buffer-overflows. You can disable this errors by
>>> defining _CRT_SECURE_NO_WARNINGS or you could use the safer versions
>>> the error-message shows you.
>>
>> I also tried to compile the SP71 program. There were only 7 real
>> errors. There is the idiotic for-scoping that was wrong in VC6. In VC
>> 6, if you write
>
> VC6 is NOT a C++ compiler, it is VC6 compiler.
>

True, in a way. Note that VC6 was published slightly before the C++98
standard was completed.

In 1997, when VC6 was implemented, the draft for the standard said that
the loop variable *should* be visible in the outer scope. Then that rule
was changed, and the standard was published.


Bo Persson

[Ben Bacarisse]

Bonita Montero <Bonita....@gmail.com> writes:

> ... In C++ every string literal has the type "const char *";

In fact they have array type. "abc" has type "array of 4 const char".
Of course, in most contexts array-valued expressions "decay" to pointer
values.

--
Ben.

[James Kuyper]

On 4/3/20 5:58 PM, Ned Latham wrote:
> Jorgen Grahn wrote:
>> Ned Latham wrote:
>> ...
>>> C++ has become a moving target and a profligate producer of maintenance
>>> nightmares. My own projects are okay so far, but I've had to make so
>>> many fatuous changes that I'm now actively looking for languages to
>>> port them to.
>>
>> Which changes would that be? Between, say a decent version two
>> decades ago (C++98) and a well-supported one today (C++11)?
>
> Exception throwing: once an option, now the default.
> "namespace": once an option, now a requirement.

Could you identify the specific changes in the text of the standard that
you're referring to, and when they happened? I'm not sure what those
descriptions mean - every interpretation I've been able to come up with
is something that, as far as I know, either has never been true, or has
always been true - either way, there wasn't a change. However, I'm not
yet fully up-to-date on anything more recent than C++98. I'm fairly
up-to-date on C++2003, and understand many of the more recently added
features well enough to make use of them.

> I suppose I should confess that the bugs in C(++) are also part of my
> problem with C++. They are the defective string definition in C, and
> the defective post-increment semenatic of C++.

Could you identify what you consider to be defective about C++'s
post-increment semantic?

[Ned Latham]

James Kuyper wrote:
> Ned Latham wrote:
> > Jorgen Grahn wrote:
> > > Ned Latham wrote:
> > > ...
> > > > C++ has become a moving target and a profligate producer of
> > > > maintenance nightmares. My own projects are okay so far, but
> > > > I've had to make so many fatuous changes that I'm now actively
> > > > looking for languages to port them to.
> > >
> > > Which changes would that be? Between, say a decent version two
> > > decades ago (C++98) and a well-supported one today (C++11)?
> >
> > Exception throwing: once an option, now the default.
> > "namespace": once an option, now a requirement.
>
> Could you identify the specific changes in the text of the standard that
> you're referring to, and when they happened?

No. I don't geek around with committee standards. The only C++ standard
that I know is Stroustrup's: "Programming in C++", vol 3, 1997.

Exception throwing was optional back then, which suits me fine, because
one of my projects is a library, and that is no place for exceptions
(frankly, I think they encourage sloppy programming, and I eschew them
at all times, not just in libraries). At some point, which I haven't
reached yet, it became the default. When I reach that point, I'll be
dropping back to the previous compiler.

Namespace wasn't on the curriculum when I started learning C++.
I don't know when it was introduced, but in his book (vol 3) Stroustrup
seems to imply that it's a new thing. He discusses, for example,
"transitioning" to it. Now, it seems, its use is compulsory.

I will not tolerate that either.

> I'm not sure what those
> descriptions mean - every interpretation I've been able to come up with
> is something that, as far as I know, either has never been true, or has
> always been true - either way, there wasn't a change. However, I'm not
> yet fully up-to-date on anything more recent than C++98. I'm fairly
> up-to-date on C++2003, and understand many of the more recently added
> features well enough to make use of them.

I'd rather put that learning curve into designing and implementing
a well-thought-out language.

> > I suppose I should confess that the bugs in C(++) are also part of my
> > problem with C++. They are the defective string definition in C, and
> > the defective post-increment semenatic of C++.
>
> Could you identify what you consider to be defective about C++'s
> post-increment semantic?

It doesn't work with non-native types.
Post-decrement too, of course.

[Ian Collins]

On 04/04/2020 17:58, Ned Latham wrote:
> James Kuyper wrote:
>>

>> Could you identify the specific changes in the text of the standard that
>> you're referring to, and when they happened?
>
> No. I don't geek around with committee standards. The only C++ standard
> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>
> Exception throwing was optional back then, which suits me fine, because
> one of my projects is a library, and that is no place for exceptions
> (frankly, I think they encourage sloppy programming, and I eschew them
> at all times, not just in libraries). At some point, which I haven't
> reached yet, it became the default. When I reach that point, I'll be
> dropping back to the previous compiler.

Default, where? May contemporary projects (and Google's coding
standards) don't permit exceptions.

> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,
> "transitioning" to it.

Namespaces where introduced in the origin 1998 C++ standard, the one
described in Stroustrup's third edition.

> Now, it seems, its use is compulsory.

Says who?

>> Could you identify what you consider to be defective about C++'s
>> post-increment semantic?
>
> It doesn't work with non-native types.
> Post-decrement too, of course.

How so?

--
Ian.

[Ned Latham]

Ian Collins wrote:
> Ned Latham wrote:
> > James Kuyper wrote:
> > >
> > > Could you identify the specific changes in the text of the standard that
> > > you're referring to, and when they happened?
> >
> > No. I don't geek around with committee standards. The only C++ standard
> > that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
> >
> > Exception throwing was optional back then, which suits me fine, because
> > one of my projects is a library, and that is no place for exceptions
> > (frankly, I think they encourage sloppy programming, and I eschew them
> > at all times, not just in libraries). At some point, which I haven't
> > reached yet, it became the default. When I reach that point, I'll be
> > dropping back to the previous compiler.
>
> Default, where? May contemporary projects (and Google's coding
> standards) don't permit exceptions.

You use cout, you risk an exception.
How do they prevent them from occurring?

> > Namespace wasn't on the curriculum when I started learning C++.
> > I don't know when it was introduced, but in his book (vol 3) Stroustrup
> > seems to imply that it's a new thing. He discusses, for example,
> > "transitioning" to it.
>
> Namespaces where introduced in the origin 1998 C++ standard, the one
> described in Stroustrup's third edition.
>
> > Now, it seems, its use is compulsory.
>
> Says who?

I do.

> > > Could you identify what you consider to be defective about C++'s
> > > post-increment semantic?
> >
> > It doesn't work with non-native types.
> > Post-decrement too, of course.
>
> How so?

I just told you. It doesn't work.

[Paavo Helde]

On 4.04.2020 0:58, Ned Latham wrote:
> Jorgen Grahn wrote:
>> Ned Latham wrote:
>> ...
>>> C++ has become a moving target and a profligate producer of maintenance
>>> nightmares. My own projects are okay so far, but I've had to make so
>>> many fatuous changes that I'm now actively looking for languages to
>>> port them to.
>>
>> Which changes would that be? Between, say a decent version two
>> decades ago (C++98) and a well-supported one today (C++11)?
>
> Exception throwing: once an option, now the default.
> "namespace": once an option, now a requirement.

Exception throwing and namespaces were both in the first 1998 C++
standard. The problem with MSVC++ used to be that it purposefully chose
to not follow the C++ standard in some places, but this has been mostly
fixed in recent versions.

What I find seriously objectionable is that the new C++ standards are
actually *removing* things from the standard like std::auto_ptr and
throw(), causing maintenance issues for old legacy codebases.

[Ned Latham]

Paavo Helde wrote:
> On 4.04.2020 0:58, Ned Latham wrote:
> > Jorgen Grahn wrote:
> > > Ned Latham wrote:
> > > ...
> > > > C++ has become a moving target and a profligate producer of maintenance
> > > > nightmares. My own projects are okay so far, but I've had to make so
> > > > many fatuous changes that I'm now actively looking for languages to
> > > > port them to.
> > >
> > > Which changes would that be? Between, say a decent version two
> > > decades ago (C++98) and a well-supported one today (C++11)?
> >
> > Exception throwing: once an option, now the default.
> > "namespace": once an option, now a requirement.
>
> Exception throwing and namespaces were both in the first 1998 C++
> standard.

As options.

> The problem with MSVC++ used to be that it purposefully chose
> to not follow the C++ standard in some places, but this has been mostly
> fixed in recent versions.
>
> What I find seriously objectionable is that the new C++ standards are
> actually *removing* things from the standard like std::auto_ptr and
> throw(), causing maintenance issues for old legacy codebases.

I don't use std: or throw(). They're both crocks, IMO.

Maintenance issues are nothing new with C++.

[Ian Collins]

On 04/04/2020 19:20, Ned Latham wrote:
> Paavo Helde wrote:
>> On 4.04.2020 0:58, Ned Latham wrote:
>>> Jorgen Grahn wrote:
>>>> Ned Latham wrote:
>>>> ...
>>>>> C++ has become a moving target and a profligate producer of maintenance
>>>>> nightmares. My own projects are okay so far, but I've had to make so
>>>>> many fatuous changes that I'm now actively looking for languages to
>>>>> port them to.
>>>>
>>>> Which changes would that be? Between, say a decent version two
>>>> decades ago (C++98) and a well-supported one today (C++11)?
>>>
>>> Exception throwing: once an option, now the default.
>>> "namespace": once an option, now a requirement.
>>
>> Exception throwing and namespaces were both in the first 1998 C++
>> standard.
>
> As options.

No different from now.

>> The problem with MSVC++ used to be that it purposefully chose
>> to not follow the C++ standard in some places, but this has been mostly
>> fixed in recent versions.
>>
>> What I find seriously objectionable is that the new C++ standards are
>> actually *removing* things from the standard like std::auto_ptr and
>> throw(), causing maintenance issues for old legacy codebases.
>
> I don't use std: or throw(). They're both crocks, IMO.

So you are bitching about stuff that's been a standard part of the
language for almost 23 years? That ship has sailed.

--
Ian.

[Ian Collins]

On 04/04/2020 18:35, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> James Kuyper wrote:
>>>>
>>>> Could you identify the specific changes in the text of the standard that
>>>> you're referring to, and when they happened?
>>>
>>> No. I don't geek around with committee standards. The only C++ standard
>>> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>>>
>>> Exception throwing was optional back then, which suits me fine, because
>>> one of my projects is a library, and that is no place for exceptions
>>> (frankly, I think they encourage sloppy programming, and I eschew them
>>> at all times, not just in libraries). At some point, which I haven't
>>> reached yet, it became the default. When I reach that point, I'll be
>>> dropping back to the previous compiler.
>>
>> Default, where? May contemporary projects (and Google's coding
>> standards) don't permit exceptions.
>
> You use cout, you risk an exception.

Do you?

> How do they prevent them from occurring?

Compile with exceptions disabled.

>>> Namespace wasn't on the curriculum when I started learning C++.
>>> I don't know when it was introduced, but in his book (vol 3) Stroustrup
>>> seems to imply that it's a new thing. He discusses, for example,
>>> "transitioning" to it.
>>
>> Namespaces where introduced in the origin 1998 C++ standard, the one
>> described in Stroustrup's third edition.
>>
>>> Now, it seems, its use is compulsory.
>>
>> Says who?
>
> I do.

Ah, so it isn't "compulsory". Good to know.

>>>> Could you identify what you consider to be defective about C++'s
>>>> post-increment semantic?
>>>
>>> It doesn't work with non-native types.
>>> Post-decrement too, of course.
>>
>> How so?
>
> I just told you. It doesn't work.

Yeah right, very helpful.

--
Ian.

[Ned Latham]

Ian Collins wrote:
> Ned Latham wrote:
> > Paavo Helde wrote:
> > > Ned Latham wrote:
> > > > Jorgen Grahn wrote:
> > > > > Ned Latham wrote:
> > > > > ...
> > > > > > C++ has become a moving target and a profligate producer of maintenance
> > > > > > nightmares. My own projects are okay so far, but I've had to make so
> > > > > > many fatuous changes that I'm now actively looking for languages to
> > > > > > port them to.
> > > > >
> > > > > Which changes would that be? Between, say a decent version two
> > > > > decades ago (C++98) and a well-supported one today (C++11)?
> > > >
> > > > Exception throwing: once an option, now the default.
> > > > "namespace": once an option, now a requirement.
> > >
> > > Exception throwing and namespaces were both in the first 1998 C++
> > > standard.
> >
> > As options.
>
> No different from now.

Crap.

> > > The problem with MSVC++ used to be that it purposefully chose
> > > to not follow the C++ standard in some places, but this has been mostly
> > > fixed in recent versions.
> > >
> > > What I find seriously objectionable is that the new C++ standards are
> > > actually *removing* things from the standard like std::auto_ptr and
> > > throw(), causing maintenance issues for old legacy codebases.
> >
> > I don't use std: or throw(). They're both crocks, IMO.
>
> So you are bitching

Try reading with somne attention and commenting with some civility, you fuck.

> about stuff that's been a standard part of the
> language for almost 23 years? That ship has sailed.

You don't get it. According to Paavo, they've been removed. By avoiding
them, I've avoided the inconsistencies and the maintenance issues that
their temporary presence caused.

But then, you'd have to be a programmer to get it.

[Ned Latham]

Ian Collins wrote:
> Ned Latham wrote:
> > Ian Collins wrote:
> > > Ned Latham wrote:

----snip----

> > > Default, where? May contemporary projects (and Google's coding
> > > standards) don't permit exceptions.
> >
> > You use cout, you risk an exception.
>
> Do you?

You wanna tell me how you don't?

> > How do they prevent them from occurring?
>
> Compile with exceptions disabled.

How?

----snip----

> > > > I don't know when it was introduced, but in his book (vol 3) Stroustrup
> > > > seems to imply that it's a new thing. He discusses, for example,
> > > > "transitioning" to it.
> > >
> > > Namespaces where introduced in the origin 1998 C++ standard, the one
> > > described in Stroustrup's third edition.
> > >
> > > > Now, it seems, its use is compulsory.
> > >
> > > Says who?
> >
> > I do.
>
> Ah, so it isn't "compulsory". Good to know.

What part of "it seems" did you fail to understand?

> > > > > Could you identify what you consider to be defective about C++'s
> > > > > post-increment semantic?
> > > >
> > > > It doesn't work with non-native types.
> > > > Post-decrement too, of course.
> > >
> > > How so?
> >
> > I just told you. It doesn't work.
>
> Yeah right, very helpful.

Get a clue. Increment has only one action, and I didn't mention
pre-increment. That leaves only one possibility.

[Jorgen Grahn]

On Fri, 2020-04-03, Christian Gollwitzer wrote:
> Am 03.04.20 um 19:35 schrieb Bonita Montero:
>> I just tried to compile your SP62-program. There are a lot assignments
>> of string-literals to non-const string-pointers. In C++ every string
>> -literal has the type "const char *"; I don't know if this has ever

...

>
> I also tried to compile the SP71 program. There were only 7 real errors.

...

Useful advise from Bonita and Christian!
(Unlike a lot of other stuff in this thread.)

[Bo Persson]

On 2020-04-04 at 09:22, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> Ian Collins wrote:
>>>> Ned Latham wrote:
>
> ----snip----
>
>>>> Default, where? May contemporary projects (and Google's coding
>>>> standards) don't permit exceptions.
>>>
>>> You use cout, you risk an exception.
>>
>> Do you?
>
> You wanna tell me how you don't?
>

cout will only throw those exceptions you have explicitly enabled by
calling cout.exceptions(exception_mask). So just don't.


https://en.cppreference.com/w/cpp/io/basic_ios/exceptions


Bo Persson

[Keith Thompson]

Ned Latham <nedl...@woden.valhalla.oz> writes:
[...]

> Try reading with somne attention and commenting with some civility,
> you fuck.

[...]

I request that everyone stop feeding this troll.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Ned Latham]

Bo Persson wrote:
> Ned Latham wrote:
> > Ian Collins wrote:
> > > Ned Latham wrote:

> > > > Ian Collins wrote:
> >
> > ----snip----
> >
> > > > > Default, where? May contemporary projects (and Google's coding
> > > > > standards) don't permit exceptions.
> > > >
> > > > You use cout, you risk an exception.
> > >
> > > Do you?
> >
> > You wanna tell me how you don't?
>
> cout will only throw those exceptions you have explicitly enabled by
> calling cout.exceptions(exception_mask). So just don't.

I don't. But that's because I don't use *any* C++ libraries.

> https://en.cppreference.com/w/cpp/io/basic_ios/exceptions

Really? An incomplete section?

It shows how to set an exception mask. There's nothing there about
*disabling* exceptions. There's nothing there to say that they're
disbled without explicit enablement.

Similar with with the gcc man page. Plenty of options for exception
types, nothing about disabling them.

[Ned Latham]

Keith Thompson wrote:

> Ned Latham writes:
> > Ian Collins wrote:
> > > Ned Latham wrote:
> > > > Paavo Helde wrote:


> > > > > What I find seriously objectionable is that the new C++
> > > > > standards are actually *removing* things from the standard
> > > > > like std::auto_ptr and throw(), causing maintenance issues
> > > > > for old legacy codebases.
> > > >
> > > > I don't use std: or throw(). They're both crocks, IMO.
> > >
> > > So you are bitching
> >

> > Try reading with some attention and commenting with some civility,
> > you fuck.
>

> I request that everyone stop feeding this troll.

I request that someone give the whatever that calls itself Keith
Thompson a dictionary and some coaching in civil discourse.

[David Brown]

<https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions>

Use "-fno-exceptions", and gcc will compile your C++ code as though the
language did not have exception support. It is a commonly used feature
- exceptions are good for some kinds of programming, less good for other
kinds.

[Paavo Helde]

I guess you probably confused throw() with exceptions. Both exceptions
and namespaces (incl. std::) are very much in C++, won't go anywhere,
are very useful, and I use them every day.

What is removed is the no-throw specification 'throw()'.
https://en.cppreference.com/w/cpp/language/except_spec :

Syntax
throw( ) (1) (deprecated in C++11)(removed in C++20)
throw(typeid, typeid, ...) (2) (deprecated in C++11)(removed in C++17)

[Alf P. Steinbach]

On 04.04.2020 06:58, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:
>>> Jorgen Grahn wrote:
>>>> Ned Latham wrote:
>>>> ...
>>>>> C++ has become a moving target and a profligate producer of
>>>>> maintenance nightmares. My own projects are okay so far, but
>>>>> I've had to make so many fatuous changes that I'm now actively
>>>>> looking for languages to port them to.
>>>>
>>>> Which changes would that be? Between, say a decent version two
>>>> decades ago (C++98) and a well-supported one today (C++11)?
>>>
>>> Exception throwing: once an option, now the default.
>>> "namespace": once an option, now a requirement.
>>
>> Could you identify the specific changes in the text of the standard that
>> you're referring to, and when they happened?
>
> No. I don't geek around with committee standards. The only C++ standard
> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.

At that time, close up to the first standardization in 1998, the /de
facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne
Stroustrup and Margaret Ellis, IIRC.

> Exception throwing was optional back then

The standard exception hierarchy wasn't finished until close up to
standardization, I believe about the time of that book, anyway after 1995.

As I recall Microsoft's Visual C++ didn't implement the new hierarchy
until some years after the standardization, I believe in Visual
Studio.NET in 2003 or so.

>, which suits me fine, because
> one of my projects is a library, and that is no place for exceptions
> (frankly, I think they encourage sloppy programming, and I eschew them
> at all times, not just in libraries). At some point, which I haven't
> reached yet, it became the default. When I reach that point, I'll be
> dropping back to the previous compiler.
>
> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,
> "transitioning" to it. Now, it seems, its use is compulsory.
>
> I will not tolerate that either.

1990's tools and techniques are fine, just fine, just not as convenient
as modern approach. Stick with what you know. However, you'll have to
adjust some details because compilers now generally conform to the ISO
standard and not the ARM, e.g. about lifetime of temporaries.

>> descriptions mean - every interpretation I've been able to come up with
>> is something that, as far as I know, either has never been true, or has
>> always been true - either way, there wasn't a change. However, I'm not
>> yet fully up-to-date on anything more recent than C++98. I'm fairly
>> up-to-date on C++2003, and understand many of the more recently added
>> features well enough to make use of them.
>
> I'd rather put that learning curve into designing and implementing
> a well-thought-out language.
>
>>> I suppose I should confess that the bugs in C(++) are also part of my
>>> problem with C++. They are the defective string definition in C, and
>>> the defective post-increment semenatic of C++.
>>
>> Could you identify what you consider to be defective about C++'s
>> post-increment semantic?
>
> It doesn't work with non-native types.
> Post-decrement too, of course.

You just have to defined custom operators where you want custom
operators and then, if properly defined, they work fine.

The post- operators take a dummy `int` argument, just to distinguish them.

Here's an example:


#include <iostream>
using namespace std; // Do this to get roughly pre-standard behavior.

struct Non_native
{
double amount;

operator double() const { return amount; }

void advance()
{
amount += 0.01;
}

Non_native operator++( int )
{
Non_native result = *this;
advance();
return result;
}
};

int main()
{
Non_native o = {3.14};

cout << "Originally " << o++ << "." << endl;
cout << "After: " << o << "." << endl;
}


- Alf

[Ned Latham]

David Brown wrote:
> Ned Latham wrote:
> > Bo Persson wrote:

----snip----

> > > cout will only throw those exceptions you have explicitly enabled by
> > > calling cout.exceptions(exception_mask). So just don't.
> >
> > I don't. But that's because I don't use *any* C++ libraries.
> >
> > > https://en.cppreference.com/w/cpp/io/basic_ios/exceptions
> >
> > Really? An incomplete section?
> >
> > It shows how to set an exception mask. There's nothing there about
> > *disabling* exceptions. There's nothing there to say that they're
> > disbled without explicit enablement.
> >
> > Similar with with the gcc man page. Plenty of options for exception
> > types, nothing about disabling them.
>
> <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions>
>
> Use "-fno-exceptions", and gcc will compile your C++ code as though the
> language did not have exception support.

I checked again. The nearest I can see is -mno-fp-exceptions. Different
versions, I suppose.

> It is a commonly used feature
> - exceptions are good for some kinds of programming, less good for other
> kinds.

Frankly, I can't see *any* use for it. It's nowhere near as context-
sensitive as making the object report the error to the caller.

But thanks for the info anyway. Indeed, thanx to all who contributed
to this subthread.

[Bonita Montero]

> Use "-fno-exceptions", and gcc will compile your C++ code as though the
> language did not have exception support.  It is a commonly used feature

> - ...
It's not a "commonly used feature" since nearly the whole standard
-library throws exceptions.

[Ned Latham]

Paavo Helde wrote:
> On 4.04.2020 10:10, Ned Latham wrote:
> > Ian Collins wrote:

----snip----

> > > about stuff that's been a standard part of the
> > > language for almost 23 years? That ship has sailed.
> >
> > You don't get it. According to Paavo, they've been removed. By avoiding
> > them, I've avoided the inconsistencies and the maintenance issues that
> > their temporary presence caused.
>
> I guess you probably confused throw() with exceptions.

Could be. None of that stuff appeals to me, so I don't exactly go
out of my way to learn its ins and outs.

> Both exceptions
> and namespaces (incl. std::) are very much in C++, won't go anywhere,
> are very useful, and I use them every day.

We're polar opposites then. I avoid them every day (including std::).

> What is removed is the no-throw specification 'throw()'.
> https://en.cppreference.com/w/cpp/language/except_spec :
>
> Syntax
> throw( ) (1) (deprecated in C++11)(removed in C++20)
> throw(typeid, typeid, ...) (2) (deprecated in C++11)(removed in C++17)

*sigh* I dunno. It looked like a good language thirty years ago. Some
hangover shit from C, but overall one of the best.

[Ned Latham]

Alf P. Steinbach wrote:
> On 04.04.2020 06:58, Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > Jorgen Grahn wrote:
> > > > > Ned Latham wrote:
> > > > > ...
> > > > > > C++ has become a moving target and a profligate producer of
> > > > > > maintenance nightmares. My own projects are okay so far, but
> > > > > > I've had to make so many fatuous changes that I'm now actively
> > > > > > looking for languages to port them to.
> > > > >
> > > > > Which changes would that be? Between, say a decent version two
> > > > > decades ago (C++98) and a well-supported one today (C++11)?
> > > >
> > > > Exception throwing: once an option, now the default.
> > > > "namespace": once an option, now a requirement.
> > >
> > > Could you identify the specific changes in the text of the standard that
> > > you're referring to, and when they happened?
> >
> > No. I don't geek around with committee standards. The only C++ standard
> > that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>
> At that time, close up to the first standardization in 1998, the /de
> facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne
> Stroustrup and Margaret Ellis, IIRC.

Sounds familiar, though I don't have it.

> > Exception throwing was optional back then
>
> The standard exception hierarchy wasn't finished until close up to
> standardization, I believe about the time of that book, anyway after
> 1995.
>
> As I recall Microsoft's Visual C++ didn't implement the new hierarchy
> until some years after the standardization, I believe in Visual
> Studio.NET in 2003 or so.

'Sfunny. I've been toying with the notion of developing a language
that gives the programmer complete control of all elements of code
generation, and one of the thoughts was that it might be a good
idea to put a minimal version it out there and get help enhancing it.

C++ shows pretty clearly that it's a bad idea. (Well, if it's done by
committee.)

----snip----

> 1990's tools and techniques are fine, just fine, just not as convenient
> as modern approach. Stick with what you know.

That's one option. Another is a stable language, with context-sensitive
error control.

> However, you'll have to
> adjust some details because compilers now generally conform to the ISO
> standard and not the ARM,

I will not be doing that. Next time I hit a version that wants me to
alter my code, I'll dump it. Either downgrade or switch.

> e.g. about lifetime of temporaries.

I always regard those as lasting until their return.

With the declarations
# include <mclib.h> // The library I referred to earlier.
and
StringC one("I'm "), two("outta here.");

the command
(one + two).Write(stderr);

puts "I'm outta here." on the error stream.
And it (the temporary) really is.

----snip----

> > > Could you identify what you consider to be defective about C++'s
> > > post-increment semantic?
> >
> > It doesn't work with non-native types.
> > Post-decrement too, of course.
>
> You just have to defined custom operators where you want custom
> operators and then, if properly defined, they work fine.

Nope. With non-native types passed to functions they pass the
incremented value to the function.

> The post- operators take a dummy `int` argument, just to distinguish them.

I know. I spent weeks hacking the post- operators in an index class
designed to provide random access to a list class. Trying to hack
correct working into them. Managed it, but the hacks were ugly and
inefficient and prevented the compiler from picking up errors.
So LixtC, the indexor to ListC, has preincrements, but not post.

> Here's an example:
>
>
> #include <iostream>
> using namespace std; // Do this to get roughly pre-standard behavior.

Not me. Namespace is beyond the pale.

> struct Non_native
> {
> double amount;
>
> operator double() const { return amount; }

What's this for? It's not used, below.

>
> void advance()
> {
> amount += 0.01;
> }
>
> Non_native operator++( int )

double is non-native?

> {
> Non_native result = *this;
> advance();
> return result;
> }
> };
>
> int main()
> {
> Non_native o = {3.14};
>
> cout << "Originally " << o++ << "." << endl;
> cout << "After: " << o << "." << endl;
> }

I'm not even going to try it, Alf, And I bet you haven't done so.
That code requires overload operators = and << for the struct.

[Mr Flibble]

On 04/04/2020 12:51, Alf P. Steinbach wrote:
[snipped]

> using namespace std;        // Do this to get roughly pre-standard behavior.

No, just no.

/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," Byrne 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."

[Bonita Montero]

> And you're using a lot of uninized variables as function-parameters;
> that's a lot of bugs.

In some cases the variable is initialized in loop before and the
compiler can't see if the loop is actually executed. So if the
loop is actually exectuted at least only once nearly everything
is fine but you just have to set the variable to an aribtrary
value at initialization.

[James Kuyper]

On 4/4/20 12:58 AM, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:

...

>>> Exception throwing: once an option, now the default.
>>> "namespace": once an option, now a requirement.
>>
>> Could you identify the specific changes in the text of the standard that
>> you're referring to, and when they happened?
>
> No. I don't geek around with committee standards. The only C++ standard
> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>
> Exception throwing was optional back then, which suits me fine, because
> one of my projects is a library, and that is no place for exceptions
> (frankly, I think they encourage sloppy programming, and I eschew them
> at all times, not just in libraries). At some point, which I haven't
> reached yet, it became the default. When I reach that point, I'll be
> dropping back to the previous compiler.
>
> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,
> "transitioning" to it. Now, it seems, its use is compulsory.
>
> I will not tolerate that either.

What's with you? I only asked for a simple explanation for an obscure
comment.
OK, so you've made it clear that you're complaining about something you
know little about. That's fine - I'd feared that you were describing
some recent changes to the language that I hadn't noticed
(Unfortunately, for me, "recent" could include changes dating as far
back to C++2017).

Throwing exceptions and declaring namespaces remains optional, and are
not the default. Your function will throw exceptions only if it
explicitly uses throw(), or if it calls a subroutine that uses throw()
outside of a try-block - that's the same as it has always been.

Everything in the C++ standard library that can be declared inside a
namespace is so declared, and many routines in the standard library do
throw exceptions. Both of those statements have been true since shortly
after those features were added to the language. However, your own code
doesn't have to throw exceptions, use namespaces, or use the C++
standard library.

...

> I'd rather put that learning curve into designing and implementing
> a well-thought-out language.

Then I would recommend not bothering to monitor a newsgroup devoted to a
language that you hate.

...

>>> the defective post-increment semenatic of C++.
>>
>> Could you identify what you consider to be defective about C++'s
>> post-increment semantic?
>
> It doesn't work with non-native types.

It works with any user-defined type that defines an operator overload
for that operator, or can be implicitly converted to a type for which
it's permitted.

> Post-decrement too, of course.

That's not "of course" - the fact that you explicitly specified
"post-increment" implies that your complaint is specifically about that
operator. Based upon the reason you've given, I'm surprised that you're
not complaining equally strongly about all of the other arithmetic
operators. You can't apply any of the following operators to a
user-defined type: + - ! ^= &= <= >= [] * < |= && / > << || % += >> ^ -=
>>= -- & *= <<= | /= == ->* ~ %= !=

Unless, of course, an applicable operator overload is defined or there's
conversion operators or conversion constructors defined that will
convert a value of that type to a different type for which those
operators are permitted.

Note: in that list, "&" refers to the binary operator - unary & can, of
course, be applied to any object of any type.

[Paavo Helde]

04.04.2020 15:25 Ned Latham kirjutas:

> Paavo Helde wrote:
>> Both exceptions
>> and namespaces (incl. std::) are very much in C++, won't go anywhere,
>> are very useful, and I use them every day.
>
> We're polar opposites then. I avoid them every day (including std::).

Ignorance is bliss, they say.

>
> *sigh* I dunno. It looked like a good language thirty years ago. Some
> hangover shit from C, but overall one of the best.

C++ has many problems, but for me it's still the best language around.
It has never let me down, regardless of how low-level I need to go in
the implementation or how high level I want to go in the interfaces and
design. Most languages have built up high walls there, either in one (C)
or both directions (Java, C#, etc).

You are right in that the current C++ (and especially its idiomatic use)
is quite different from the pre-standard C++ dialects used in the last
century. If all your C++ knowlegde and experience becomes from year
1997, this just means that every opinion you express about current C++
is mostly just babbling.

[James Kuyper]

On 4/4/20 1:35 AM, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> James Kuyper wrote:

...

> You use cout, you risk an exception.

That hasn't changed - since shortly afer exceptions were first added to
the language, if you call a function that can throw an exception, and
don't catch the exception, your function will throw that exception.

> How do they prevent them from occurring?

try{ } catch{}.

>>> Namespace wasn't on the curriculum when I started learning C++.
>>> I don't know when it was introduced, but in his book (vol 3) Stroustrup
>>> seems to imply that it's a new thing. He discusses, for example,
>>> "transitioning" to it.

...

>>> Now, it seems, its use is compulsory.
>>
>> Says who?
>
> I do.

If the only reason it's compulsory is because you said it, and you don't
like it being compulsory, then I recommend that you stop saying that
it's compulsory. There's no one else whose said anything to make
explicit use of namespaces compulsory.

Strictly speaking, if you don't declare something inside an explicitly
declared namespace, it is implicitly declared in a separate unnamed
namespace, which is a separate namespace for each translation unit. So
declaring something inside a namespace is technically unavoidable.
However, the concept of an unnamed namespace has no practical effect on
your code - being implicit, it never needs to be named. The concept only
exists because it makes it easier to word various rules concerning
namespaces.

And again, that's a feature of the language that has existed since
shortly after namespaces were first added to the language - it is not a
change.

>>>> Could you identify what you consider to be defective about C++'s
>>>> post-increment semantic?
>>>
>>> It doesn't work with non-native types.
>>> Post-decrement too, of course.
>>
>> How so?
>
> I just told you. It doesn't work.

Unless you declare an applicable operator overload, in which case it
does work. Why would you want it to work on a user-defined type that
doesn't have such an overload? Why, for instance, should the standard
allow you to write myContainer++, and what in the world would you want
it to do if you did allow such a construct?

[David Brown]

On 04/04/2020 14:15, Ned Latham wrote:
> David Brown wrote:
>> Ned Latham wrote:
>>> Bo Persson wrote:
>
> ----snip----
>
>>>> cout will only throw those exceptions you have explicitly enabled by
>>>> calling cout.exceptions(exception_mask). So just don't.
>>>
>>> I don't. But that's because I don't use *any* C++ libraries.
>>>
>>>> https://en.cppreference.com/w/cpp/io/basic_ios/exceptions
>>>
>>> Really? An incomplete section?
>>>
>>> It shows how to set an exception mask. There's nothing there about
>>> *disabling* exceptions. There's nothing there to say that they're
>>> disbled without explicit enablement.
>>>
>>> Similar with with the gcc man page. Plenty of options for exception
>>> types, nothing about disabling them.
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions>
>>
>> Use "-fno-exceptions", and gcc will compile your C++ code as though the
>> language did not have exception support.
>
> I checked again. The nearest I can see is -mno-fp-exceptions. Different
> versions, I suppose.

Perhaps along with your pre-standard C++ from the early nineties, you
are using a compiler of that age. Either that, or you don't know how
options in gcc work. (If that's just lack of knowledge, it is easily
solved - follow the link I gave you.)

>
>> It is a commonly used feature
>> - exceptions are good for some kinds of programming, less good for other
>> kinds.
>
> Frankly, I can't see *any* use for it. It's nowhere near as context-
> sensitive as making the object report the error to the caller.
>

Do you assume that you know all the uses other people might have for
features in a language? You seem to be parading your ignorance and
self-centred views as though they were something to be proud of. The
C++ language, C++ programmers, and the programming world in general has
moved on in the last 25 years. You can stay in the past if you want,
but insulting and condemning everyone who has moved on is completely
inappropriate.

It is certainly the case that for most decisions and features there will
be some people who like them and find them useful, some who don't use
them but see no harm in them, and some who think they are a bad idea or
find them a problem. No one is suggesting that you have to adopt all
the new features of C++.

[James Kuyper]

On 4/4/20 3:22 AM, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> Ian Collins wrote:
>>>> Ned Latham wrote:

...

>>> You use cout, you risk an exception.
>>
>> Do you?
>
> You wanna tell me how you don't?

try { } catch{};

>>> How do they prevent them from occurring?
>>
>> Compile with exceptions disabled.
>
> How?

Disabling exceptions renders an implementation non-conforming. How to do
it is therefore outside the scope of the C++ standard, and is
implementation-specific. If your preferred implementation doesn't
provide such a method, your complaint is with the implementors, not with
the C++ language.

...

>>>> Namespaces where introduced in the origin 1998 C++ standard, the one
>>>> described in Stroustrup's third edition.
>>>>
>>>>> Now, it seems, its use is compulsory.
>>>>
>>>> Says who?
>>>
>>> I do.
>>
>> Ah, so it isn't "compulsory". Good to know.
>
> What part of "it seems" did you fail to understand?

The part where it represents anything other than a misconception on your
part.

>
>>>>>> Could you identify what you consider to be defective about C++'s
>>>>>> post-increment semantic?
>>>>>
>>>>> It doesn't work with non-native types.
>>>>> Post-decrement too, of course.
>>>>
>>>> How so?
>>>
>>> I just told you. It doesn't work.
>>
>> Yeah right, very helpful.
>
> Get a clue. Increment has only one action, and I didn't mention
> pre-increment. That leaves only one possibility.

Yes, but most of us have no trouble applying post-increment to
user-defined types that have an appropriate operator overload defined,
and see no reason to want to apply post-increment to a type that doesn't
define such an overload. Therefore, the fact that you want to apply
post-increment to a type where you can't apply post-increment is an
anomaly that calls for an more detailed explanation.

[David Brown]

It is a commonly used feature, since many C++ programming standards,
many C++ projects, and many companies do not use exceptions in their C++
code. A prime example is Google, whose coding standard disallows
exceptions. Another is the small embedded systems programming world
(roughly speaking, systems where the processor runs a single program
rather than an OS supporting multiple programs) where disabling
exceptions and RTTI is the norm. You will also find exceptions to be
disabled in many high-performance coding tasks, such as games.

Exceptions are definitely useful for many purposes, but equally
definitely not ideal in all systems. It is not a surprise that various
"error return" mechanisms such as "expected" and "optional" are on the
uptake. The proposals for a more lightweight and deterministic
exception mechanism may turn out to be a better compromise between
different error-handling solutions.

[Bonita Montero]

Sorry, what I told was nonsense.
I checked it with the following code:

unsigned f123();

unsigned f456( unsigned a, unsigned b )
{
unsigned j;
for( ; a != b; ++a )
j = f123();
return j;
}

The compiler can't say for sure if f123 is called. But
it doesn't complain about that f123 might not get called.

[Ian Collins]

On 05/04/2020 02:33, Ned Latham wrote:

> Alf P. Steinbach wrote:
>
>> Here's an example:
>>
>>
>> #include <iostream>
>> using namespace std; // Do this to get roughly pre-standard behavior.
>
> Not me. Namespace is beyond the pale.
>
>> struct Non_native
>> {
>> double amount;
>>
>> operator double() const { return amount; }
>
> What's this for? It's not used, below.

It is.

>>
>> void advance()
>> {
>> amount += 0.01;
>> }
>>
>> Non_native operator++( int )
>
> double is non-native?
>
>> {
>> Non_native result = *this;
>> advance();
>> return result;
>> }
>> };
>>
>> int main()
>> {
>> Non_native o = {3.14};
>>
>> cout << "Originally " << o++ << "." << endl;
>> cout << "After: " << o << "." << endl;
>> }
>
> I'm not even going to try it, Alf, And I bet you haven't done so.
> That code requires overload operators = and << for the struct.
>

No, it doesn't. The code compiles and behaves exactly as intended and
your inability to comprehend it clearly demonstrates what I thought all
along, you are clueless.

--
Ian.

[Ian Collins]

On 05/04/2020 02:27, James Kuyper wrote:
> On 4/4/20 12:58 AM, Ned Latham wrote:
>> James Kuyper wrote:
>>> Ned Latham wrote:
> ...
>>>> Exception throwing: once an option, now the default.
>>>> "namespace": once an option, now a requirement.
>>>
>>> Could you identify the specific changes in the text of the standard that
>>> you're referring to, and when they happened?
>>
>> No. I don't geek around with committee standards. The only C++ standard
>> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>>
>> Exception throwing was optional back then, which suits me fine, because
>> one of my projects is a library, and that is no place for exceptions
>> (frankly, I think they encourage sloppy programming, and I eschew them
>> at all times, not just in libraries). At some point, which I haven't
>> reached yet, it became the default. When I reach that point, I'll be
>> dropping back to the previous compiler.
>>
>> Namespace wasn't on the curriculum when I started learning C++.
>> I don't know when it was introduced, but in his book (vol 3) Stroustrup
>> seems to imply that it's a new thing. He discusses, for example,
>> "transitioning" to it. Now, it seems, its use is compulsory.
>>
>> I will not tolerate that either.
>
> What's with you?

It's called trolling :)

--
Ian.

[Sam]

Gerry Wolff writes:

> * This project is part of a long-time research programme, and I would of
> course give credit for help with programming in papers arising from the new
> research.

So, you're asking for assistance fixing old C++ code to the new C++ standard
in exchange for …credit in a research paper?

> * If you would be willing to help, please get in touch via
> j...@cognitionresearch.org. Please say something briefly about your
> experience with Visual C++, and the time you would have available to work on
> what I’ve described.

It seems like you have very high standards, for accepting free help. I'm
sure it would be an honor of a lifetime for someone to, most likely, sink
massive amounts of time in cleaning up old code base that, most likely, was
written by someone without much formal C++ training, knowledge, and
experience; in exchange for recognition in some research paper that few
people will ever read.

This is obviously a drive-by posting, and this is likely just pissing into
the wind: but you'll have far more success circulating your request amognst
graduate students in Comp Sci in your institution of higher learning. I
can't fathom anyone else caring to give a whit.

[James Kuyper]

On 4/4/20 9:33 AM, Ned Latham wrote:
> Alf P. Steinbach wrote:
>> On 04.04.2020 06:58, Ned Latham wrote:
>>> James Kuyper wrote:
>>>> Ned Latham wrote:
>>>>> Jorgen Grahn wrote:
>>>>>> Ned Latham wrote:
...

>> e.g. about lifetime of temporaries.
>
> I always regard those as lasting until their return.

I have no idea what "their return" is supposed to mean. The general rule
is that temporaries last until the end of the full-expression that
contains them. There's three main exceptions, the most important of
which occurs when a temporary is bound to a reference.

>>>> Could you identify what you consider to be defective about C++'s
>>>> post-increment semantic?
>>>
>>> It doesn't work with non-native types.
>>> Post-decrement too, of course.
>>
>> You just have to defined custom operators where you want custom
>> operators and then, if properly defined, they work fine.
>
> Nope. With non-native types passed to functions they pass the
> incremented value to the function.

Well, he did say "if properly defined". To reproduce behavior comparable
to that for the built-in types, you need merely declare the operator
overload as returning a value of the same type, and define the operator
overload to create a copy of the current object before incrementing it,
and to return that copy. You won't get the behavior you've described
above if you follow those rules.

>> struct Non_native
>> {
>> double amount;
>>
>> operator double() const { return amount; }
>
> What's this for? It's not used, below.

That implements a conversion from Non-native to double, and it is used

below.

>>
>> void advance()
>> {
>> amount += 0.01;
>> }
>>
>> Non_native operator++( int )
>
> double is non-native?

No, but Non_native contains a double, and is implicitly convertible to a
double. I'm curious - how did you misinterpret the above code so as to
lead to that question?

>> {
>> Non_native result = *this;
>> advance();
>> return result;
>> }
>> };
>>
>> int main()
>> {
>> Non_native o = {3.14};
>>
>> cout << "Originally " << o++ << "." << endl;

You said that operator double() was not used. It might help you
understand this code to realize that it's equivalent to the following:

cout << "Originally " << o.operator++(1).operator double()
<< "." << endl;

If you don't understand why those two statements are equivalent, please
explain what part you do understand, and we can fill in the rest.

>> cout << "After: " << o << "." << endl;

Similarly, that line is equivalent to:

cout << "After: " << o.operator double() << "." << endl;

>> }
>
> I'm not even going to try it, Alf, And I bet you haven't done so.
> That code requires overload operators = and << for the struct.

No, the rules of C++ cause operator double() to be called in each of the
relevant cases, and there are operators already defined for << working
on doubles. There's no need to declare or define operator=(); C++ rules
cause it to be implicitly declared and implicitly defined, and the
implicitly defined operator=() does precise what is needed. That's not
a coincidence - those rule were created specifically to save developers
the trouble of defining operator=() explicitly. You only need to
explicitly declare or define it in circumstance the implicit
declaration/definition doesn't do what you want it to do.

[Mr Flibble]

Give a whit? Typo there I think: give a shit is far more appropriate.

[Ned Latham]

James Kuyper wrote:
> On 4/4/20 12:58 AM, Ned Latham wrote:
>> James Kuyper wrote:
>>> Ned Latham wrote:
> ...
>>>> Exception throwing: once an option, now the default.
>>>> "namespace": once an option, now a requirement.
>>>
>>> Could you identify the specific changes in the text of the standard that
>>> you're referring to, and when they happened?
>>
>> No. I don't geek around with committee standards. The only C++ standard
>> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.

----snip----

> What's with you? I only asked for a simple explanation for an obscure
> comment.

You got it.

----snip----

> OK, so you've made it clear that you're complaining about something you
> know little about.

Wrong. You've made clear that your reading and comprehension are
defective.

----snip----

[Ned Latham]

Paavo Helde wrote:
> 04.04.2020 15:25 Ned Latham kirjutas:
> > Paavo Helde wrote:
> > > Both exceptions
> > > and namespaces (incl. std::) are very much in C++, won't go
> > > anywhere, are very useful, and I use them every day.
> >
> > We're polar opposites then. I avoid them every day (including std::).
>
> Ignorance is bliss, they say.

Avoidance and ignorance aren't the same thing.

> > *sigh* I dunno. It looked like a good language thirty years ago. Some
> > hangover shit from C, but overall one of the best.
>
> C++ has many problems, but for me it's still the best language around.

I use it (for now) because I like the power and the conciseness and the
OO paradigm. But if I could find a language with those qualities, plus
some other quaqlities I deem important, I'd switch in a heartbeat; fact
is, its syntax and readability are woeful and its dependence on
parentheses is a PITA.

Not to mention the afore-mentioned versionitis.

> It has never let me down, regardless of how low-level I need to go in
> the implementation or how high level I want to go in the interfaces and
> design.

What programming language ever has?

> Most languages have built up high walls there, either in one (C)

You can go very high level in C with ADT's.

> or both directions (Java, C#, etc).

Never used either.

> You are right in that the current C++ (and especially its idiomatic use)
> is quite different from the pre-standard C++ dialects used in the last
> century.

In fact, they've made it *so* different that a new name would be
appropriate.

> If all your C++ knowlegde and experience becomes from year
> 1997,

That's a pretty stupid premise.

> this just means that every opinion you express about current C++
> is mostly just babbling.

And the conclusion's in that category too.

[Ned Latham]

James Kuyper wrote:
> On 4/4/20 1:35 AM, Ned Latham wrote:
> > Ian Collins wrote:
> > > Ned Latham wrote:

----snip----

> > > > Now, it seems, its use is compulsory.
> > >
> > > Says who?
> >
> > I do.
>
> If the only reason it's compulsory is because you said it,

I didn't. Try paying attention to what you read.

----snip----

[Ned Latham]

David Brown wrote:
> Ned Latham wrote:

> > David Brown wrote:

----snip----

> > > It is a commonly used feature - exceptions are good for some kinds
> > > of programming, less good for other kinds.
> >
> > Frankly, I can't see *any* use for it. It's nowhere near as context-
> > sensitive as making the object report the error to the caller.
> >
>
> Do you assume that you know all the uses other people might have for
> features in a language?

Straw man. I know what exceptions are. And I repeat: it's nowhere near
as context-sensitive as making the object report the error to the caller.

----snip----

[Ned Latham]

Ian Collins wrote:
> On 05/04/2020 02:33, Ned Latham wrote:
> > Alf P. Steinbach wrote:
> >
> > > Here's an example:
> > >
> > >
> > > #include <iostream>
> > > using namespace std; // Do this to get roughly pre-standard behavior.
> >
> > Not me. Namespace is beyond the pale.
> >
> > > struct Non_native
> > > {
> > > double amount;
> > >
> > > operator double() const { return amount; }
> >
> > What's this for? It's not used, below.
>
> It is.

Liar.

> > >
> > > void advance()
> > > {
> > > amount += 0.01;
> > > }
> > >
> > > Non_native operator++( int )

> > > {
> > > Non_native result = *this;
> > > advance();
> > > return result;
> > > }
> > > };
> > >
> > > int main()
> > > {
> > > Non_native o = {3.14};
> > >
> > > cout << "Originally " << o++ << "." << endl;
> > > cout << "After: " << o << "." << endl;
> > > }
> >
> > I'm not even going to try it, Alf, And I bet you haven't done so.
> > That code requires overload operators = and << for the struct.
>
> No, it doesn't.

Wrong.

> The code compiles and behaves exactly as intended

Your intention to produce defective code is noted.

> and
> your inability to comprehend it clearly demonstrates what I thought all
> along, you are clueless.

Wrong pronoun, dimwit.

[Gerry Wolff]

On Friday, 3 April 2020 18:35:45 UTC+1, Bonita Montero wrote:
> I just tried to compile your SP62-program. There are a lot assignments
> of string-literals to non-const string-pointers. In C++ every string
> -literal has the type "const char *"; I don't know if this has ever
> been different in earlier versions of C++, but earlier versions of
> MSVC accepted the assignment of string-literals to char-pointers. So
> you have to make your c-strings const. And there are a lot of erors
> which advise you to use safe versions of C-runtime-functions which
> are not prone to buffer-overflows. You can disable this errors by
> defining _CRT_SECURE_NO_WARNINGS or you could use the safer versions
> the error-message shows you.

Many thanks for these and your other comments and suggestions that you made later.

With best wishes,

Gerry

[Gerry Wolff]

On Friday, 3 April 2020 21:01:37 UTC+1, Christian Gollwitzer wrote:
> Am 03.04.20 um 19:35 schrieb Bonita Montero:

> > I just tried to compile your SP62-program. There are a lot assignments
> > of string-literals to non-const string-pointers. In C++ every string
> > -literal has the type "const char *"; I don't know if this has ever
> > been different in earlier versions of C++, but earlier versions of
> > MSVC accepted the assignment of string-literals to char-pointers. So
> > you have to make your c-strings const. And there are a lot of erors
> > which advise you to use safe versions of C-runtime-functions which
> > are not prone to buffer-overflows. You can disable this errors by
> > defining _CRT_SECURE_NO_WARNINGS or you could use the safer versions
> > the error-message shows you.
>

> I also tried to compile the SP71 program. There were only 7 real errors.
> There is the idiotic for-scoping that was wrong in VC6. In VC 6, if you
> write
>
> for (int i=0; i<n; i++) { }
>
> then the i variable belongs to the outer block, whereas in C++ since
> 1998 it belongs to the for block. So shift this to
>
> int i;
> for (i=0; i<n; i++) { }
>
> to get the same effect. Then there was an default-to-int static variable
> without a type; even the compiler knew how to fix it:
>
>
> SP71_lib.cpp:16155:9: error: C++ requires a type specifier for all
> declarations
> static column_counter = 0 ;
> ~~~~~~ ^
> 1 error generated.
>
> and a missing comma in a sequence of declarations; I wonder how that
> ever could compile.
>
> Now it compiles on clang, but with 283 warnings, of course. Here's the diff:
>
> Apfelkiste:Tests chris$ diff -r SP_new/ SP
> diff -r SP_new/SP71_head.h SP/SP71_head.h
> 660c660
> < {symbol *s ; int i; for (i = 0; i < sequence_depth; i++)
> ---
> > {symbol *s ; for (int i = 0; i < sequence_depth; i++)
> diff -r SP_new/SP71_lib.cpp SP/SP71_lib.cpp
> 2347c2347
> < for (int i = 1; i < start_col_2; i++)
> ---
> > for (i = 1; i < start_col_2; i++)
> 12200c12200
> < *t_pattern = get_row_pattern(bottom_row),
> ---
> > *t_pattern = get_row_pattern(bottom_row)
> 16155c16155
> < static int column_counter = 0 ;
> ---
> > static column_counter = 0 ;
> Only in SP_new/: a.out
> Apfelkiste:Tests chris$
>
>
> Christian

Many thanks for these comments and suggestions.

With best wishes,

Gerry

[Gerry Wolff]

Contrary to what you suggest, I've had a brilliant response from someone who has done a very thorough review and updating of my SP71 C++ program. I could not have asked for more.

Gerry

[James Kuyper]

On 4/5/20 5:06 AM, Ned Latham wrote:
> James Kuyper wrote:
>> On 4/4/20 1:35 AM, Ned Latham wrote:
>>> Ian Collins wrote:
>>>> Ned Latham wrote:

...

>>>>> Now, it seems, its use is compulsory.
>>>>
>>>> Says who?

As a response to that comment, "Says who" should be interpreted as a
short form for the question "Who says that it's use is compulsory?".

>>> I do.

Which, in context, should mean "I say that it's use is compulsory.",
which is technically correct, since you did in fact say that in the your
immediately previous question - the line where you say precisely that is
still quoted at the top of this message. It seems, however, from your
response below, that this is not what you actually meant to say.

That's fine, because that's not actually the kind of answer he was
looking for. You were clearly merely describing something that you
didn't approve of. What he should have asked is "Who's making it
compulsory?". He's asking that for a very simple reason - he's not aware
of anyone having done so. Neither am I. If someone who has the authority
to do so is going to make it compulsory for me to use namespaces, then I
want to know who it is, so I can start the process of removing them from
authority. So could you please identify who that is?

>> If the only reason it's compulsory is because you said it,
>

> I didn't. ...

First you say "I do.", and now you're denying it?

On 4/4/20 12:58 AM, Ned Latham wrote:

> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,

> "transitioning" to it. Now, it seems, its use is compulsory.

And, as far as I know, that text, written by you, is the only text
anywhere that says that use of namespaces is compulsory. If I'm wrong
about that, please identify another piece of text that says so.

[James Kuyper]

On 4/5/20 5:19 AM, Ned Latham wrote:
> Ian Collins wrote:
>> On 05/04/2020 02:33, Ned Latham wrote:
>>> Alf P. Steinbach wrote:

...

>>>> operator double() const { return amount; }
>>>
>>> What's this for? It's not used, below.
>>
>> It is.
>
> Liar.

Give it a try. Modify that definition to monitor calls to that function:

operator double() const {
cout << endl << "Conversion from Non_native to double performed:"
<< amount << endl;
return amount.

}

>
>>>>
>>>> void advance()
>>>> {
>>>> amount += 0.01;
>>>> }
>>>>
>>>> Non_native operator++( int )
>>>> {
>>>> Non_native result = *this;
>>>> advance();
>>>> return result;
>>>> }
>>>> };
>>>>
>>>> int main()
>>>> {
>>>> Non_native o = {3.14};
>>>>
>>>> cout << "Originally " << o++ << "." << endl;
>>>> cout << "After: " << o << "." << endl;
>>>> }
>>>
>>> I'm not even going to try it, Alf, And I bet you haven't done so.
>>> That code requires overload operators = and << for the struct.
>>
>> No, it doesn't.
>
> Wrong.
>
>> The code compiles and behaves exactly as intended

Give it a try. Try to compile it, and you'll find it will compile
without error messages, and it shouldn't trigger any warnings, either.
Try to link it, and you'll find that it will link. Try to execute it,
and it will execute and produce output showing that the return value of
operator++ is the value before the increment, while the value stored in
o is the value after the increment. And if you add the monitoring that I
recommended, you'll find that operator double() is called twice. Here's
the results when I do it:

~/Programming/C++/testprog(57) g++ -std=c++98 -pedantic -Wall
-Wpointer-arith -Wcast-align -fno-enforce-eh-specs -ffor-scope
-fno-gnu-keywords -fno-nonansi-builtins -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wsign-promo
post-increment.cpp -o post-increment
~/Programming/C++/testprog(58) post-increment
Originally
Conversion from Non_native to double performed:3.14
3.14.
After:
Conversion from Non_native to double performed:3.15
3.15.

I used C++98, since you prefer old versions of C++, and that's the
oldest version gcc supports. It also produces the same results when
compiled using the latest version of C++ it supports.
Note that the other options I used are mainly to ensure that it produces
all of the warnings I consider reasonable - feel free to modify that
list. Let me know if you find an option whose addition or removal gives
you different results from mine.

> Your intention to produce defective code is noted.

That the above code has the behavior shown is guaranteed by the C++
standard (all versions).

[Mr Flibble]

I nearly always check error and convert it into an exception: this is the correct thing to do as attempting to manually propagate errors up the call stack is tedious, antiquated and fucktarded.

[Ned Latham]

James Kuyper wrote:
> Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > Ian Collins wrote:
> > > > > Ned Latham wrote:
> ...
> > > > > > Now, it seems, its use is compulsory.
> > > > >
> > > > > Says who?
>
> As a response to that comment, "Says who" should be interpreted as a
> short form for the question "Who says that it's use is compulsory?".

Wrong.

> > > > I do.
>
> Which, in context, should mean "I say that it's use is compulsory.",

Wrong.

----snip----

> > > If the only reason it's compulsory is because you said it,
> >
> > I didn't. ...
>
> First you say "I do.", and now you're denying it?

Wrong.

> On 4/4/20 12:58 AM, Ned Latham wrote:
> > Namespace wasn't on the curriculum when I started learning C++.
> > I don't know when it was introduced, but in his book (vol 3) Stroustrup
> > seems to imply that it's a new thing. He discusses, for example,
> > "transitioning" to it. Now, it seems, its use is compulsory.
>
> And, as far as I know, that text, written by you, is the only text
> anywhere that says that use of namespaces is compulsory.

And you're wrong again.

> If I'm wrong
> about that, please identify another piece of text that says so.

That's not the only alternative to your idiot misinterpretation.

Learn to read.

[Ned Latham]

Mr Flibble wrote:
> Ned Latham wrote:
> > David Brown wrote:
> > > Ned Latham wrote:
> > > > David Brown wrote:
> >
> > ----snip----
> >
> > > > > It is a commonly used feature - exceptions are good for some kinds
> > > > > of programming, less good for other kinds.
> > > >
> > > > Frankly, I can't see *any* use for it. It's nowhere near as context-
> > > > sensitive as making the object report the error to the caller.
> > >
> > > Do you assume that you know all the uses other people might have for
> > > features in a language?
> >
> > Straw man. I know what exceptions are. And I repeat: it's nowhere near
> > as context-sensitive as making the object report the error to the caller.
>
> I nearly always check error and convert it into an exception: this is the
> correct thing to do as attempting to manually propagate errors up the call
> stack is tedious,

One level is all it takes.

> antiquated

So's breathing. So what?

> and fucktarded.

You can always try Flubbing it.

[James Kuyper]

On 4/5/20 12:31 PM, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:
>>> James Kuyper wrote:
>>>> Ned Latham wrote:
>>>>> Ian Collins wrote:
>>>>>> Ned Latham wrote:
>> ...
>>>>>>> Now, it seems, its use is compulsory.
>>>>>>
>>>>>> Says who?
>>
>> As a response to that comment, "Says who" should be interpreted as a
>> short form for the question "Who says that it's use is compulsory?".
>
> Wrong.

OK - so you've made it clear that you're misunderstanding ordinary
English sentences. However, that's not a particular useful response,
because it lacks an explanation. As a result, I have no idea which
misunderstanding of that sentence is the one you believe to be correct.

This is long overdue - Plonk.

[Ned Latham]

James Kuyper wrote:
> Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > James Kuyper wrote:
> > > > > Ned Latham wrote:
> > > > > > Ian Collins wrote:
> > > > > > > Ned Latham wrote:
> > > ...
> > > > > > > > Now, it seems, its use is compulsory.
> > > > > > >
> > > > > > > Says who?
> > >
> > > As a response to that comment, "Says who" should be interpreted as a
> > > short form for the question "Who says that it's use is compulsory?".
> >
> > Wrong.
>
> OK - so you've made it clear that you're misunderstanding ordinary
> English sentences.

Wrong.

> However, that's not a particular useful response,
> because it lacks an explanation.

It doesn't need one.

> As a result, I have no idea which
> misunderstanding of that sentence is the one you believe to be correct.

That's because you don't understand English.

> This is long overdue - Plonk.

The action of a moral coward.

[Juha Nieminen]

Gerry Wolff <gerryw...@gmail.com> wrote:
> Contrary to what you suggest, I've had a brilliant response from someone who has done a very thorough review and updating of my SP71 C++ program. I could not have asked for more.

So you got someone to do your work for you, for free. Congratulations.

I wish I could have someone do my work for me, for free.

[Jorgen Grahn]

There's no reason for a sarcastic response. GW was responsing to
someone being rude and he handled that very well IMO.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .