From Newsgroup: comp.lang.c++

"Herb Sutter: Why C++ Is Growing and What C++26 Means for Production
Systems"
https://www.youtube.com/watch?v=Qvr9MTAU_y4

"At the London C++ meetup last month, I participated on a panel where
each panelist gave a short introductory presentation. My 7-minute intro
(aka rCLlightning talkrCY) just got posted rCo you can view it here. The one-sentence blurb: rCLC++ is accelerating, and C++26 is built for what developers need now.rCY"

A 7 minute talk.

Hat tip to:
http://herbsutter.com/2026/04/29/london-meetup/

Lynn

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Lynn McGuire wrote this screed in ALL-CAPS:

"Herb Sutter: Why C++ Is Growing and What C++26 Means for Production Systems"
https://www.youtube.com/watch?v=Qvr9MTAU_y4

"At the London C++ meetup last month, I participated on a panel where
each panelist gave a short introductory presentation. My 7-minute intro
(aka rCLlightning talkrCY) just got posted rCo you can view it here. The one-sentence blurb: rCLC++ is accelerating, and C++26 is built for what developers need now.rCY"

A 7 minute talk.

Hat tip to:
http://herbsutter.com/2026/04/29/london-meetup/

Heh, I only recently started using C++17 features.

Herb talks about C++20 issues with:

- Modules. (They don't work.)
- Coroutines. (They're not actually coroutines.)
- Concepts. (Cool, but most of you won't ever write one.)

Apparently GCC will be getting contracts and reflection "soon".
--
I feel partially hydrogenated!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Sat, 9 May 2026 07:31:02 -0400
Chris Ahlstrom <OFeem1987@teleworm.us> gabbled:

Lynn McGuire wrote this screed in ALL-CAPS:

Hat tip to:
http://herbsutter.com/2026/04/29/london-meetup/

Heh, I only recently started using C++17 features.

Herb talks about C++20 issues with:

- Modules. (They don't work.)
- Coroutines. (They're not actually coroutines.)

Quite how they managed to come up with such an utter abortion of an implementation is anyones guess. They should have taken a look at how
Python does it - the function returns an iterator and you call "yield <result>" inside it. Done.

- Concepts. (Cool, but most of you won't ever write one.)

But morons conducting job interviews will still ask about them even though their company code doesn't contain them either.

Apparently GCC will be getting contracts and reflection "soon".

I can't wait for contracts and reflection in C++!

Said no one , ever.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Boltar@caprica.Universe wrote: |-------------------------------------------------------------------------------|
|"On Sat, 9 May 2026 07:31:02 -0400 |
|Chris Ahlstrom <OFeem1987@teleworm.us> gabbled: |

Lynn McGuire wrote this screed in ALL-CAPS: |

Hat tip to: |
http://herbsutter.com/2026/04/29/london-meetup/ |

|
Heh, I only recently started using C++17 features. |
|
Herb talks about C++20 issues with: |
|
- Modules. (They don't work.) |
- Coroutines. (They're not actually coroutines.) |

| |
|Quite how they managed to come up with such an utter abortion of an |
|implementation is anyones guess. They should have taken a look at how |
|Python does it - the function returns an iterator and you call "yield <result>"|
|inside it. Done. |
| |

- Concepts. (Cool, but most of you won't ever write one.) |

| |
|But morons conducting job interviews will still ask about them even though |
|their company code doesn't contain them either. |
| |

Apparently GCC will be getting contracts and reflection "soon". |

| |
|I can't wait for contracts and reflection in C++! |
| |
|Said no one , ever." |
|-------------------------------------------------------------------------------|

How about contracts in Eiffel or Ada?

Message-ID: <9c75e0f1-d977-40a3-b8c4-64751c6e0a39n@googlegroups.com>
says since
Date: Sat, 8 Apr 2023 10:27:16 -0700 (PDT)
-
|-------------------------------------------------------------------------| |"On Saturday, April 8, 2023 at 6:48:14rC>PM UTC+2, Simon Wright wrote: |

GCC 12.2.0 accepts this code with -gnat2022. |

| | |True! Cool... In my opinion, contracts are among the coolest (and maybe| |more exclusive) features of Ada" | |-------------------------------------------------------------------------|

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

boltar@caprica.universe writes:

http://herbsutter.com/2026/04/29/london-meetup/

Ok, I watched this video but meh, it said even C is growing, so merit
doesn't seem to be involved.

- Modules. (They don't work.)

That's unfortunate. I hadn't been paying attention but I had the
impression that they were promising.

- Coroutines. (They're not actually coroutines.)

Yeah true. More like protothreads.

They should have taken a look at how Python does it - the function
returns an iterator and you call "yield <result>" inside it. Done.

That's generators. Python coroutines are a mess because they were added
to the language a little bit at a time. There are even multiple
syntaxes (how unpythonic) for doing using them, generator-style and async/await.

- Concepts. (Cool, but most of you won't ever write one.)

I haven't used them in C++, but in Haskell they're called "type classes"
and people write them all the time. They are important. Does Ada have something similar? In C++ it might be that writing them is done mostly
by library implementers. But then they help the users by decreasing the hellishness of templated classes.

Apparently GCC will be getting contracts and reflection "soon".

I can't wait for contracts and reflection in C++!

Contracts seem like a good thing. They're important in Ada after all.

Reflection, that I don't know about.

That said, the video of Herb Sutter's talk showed an audience of old bald-headed guys, almost like a Lisp conference. For better or worse,
Rust seems to have all the energy now.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Paul Rubin <no.email@nospam.invalid> writes:
[...]

- Concepts. (Cool, but most of you won't ever write one.)

I haven't used them in C++, but in Haskell they're called "type classes"
and people write them all the time. They are important. Does Ada have something similar? In C++ it might be that writing them is done mostly
by library implementers. But then they help the users by decreasing the hellishness of templated classes.

Yes, Ada has something similar. C++ concepts are a (new) way to
specify constraints on template arguments. Ada has had that as an
inherent part of its generics feature since the beginning, in the
form of generic formal parameters.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Sun, 10 May 2026 01:24:40 -0700
Paul Rubin <no.email@nospam.invalid> gabbled:

boltar@caprica.universe writes:

They should have taken a look at how Python does it - the function
returns an iterator and you call "yield <result>" inside it. Done.

That's generators. Python coroutines are a mess because they were added

They're still co-routines. Ie they return to a remembered state each time they're called. They can be used generically as well as for generators.

Contracts seem like a good thing. They're important in Ada after all.

You ever had to program in Ada? Its a PITA.

bald-headed guys, almost like a Lisp conference. For better or worse,
Rust seems to have all the energy now.

Nah, just has a lot of loudy shouty types making a lot of noise. People have short memories - we had similar hype for Go and Ruby back in the day and
where are they now?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Paul Rubin <no.email@nospam.invalid> writes:

boltar@caprica.universe writes:

http://herbsutter.com/2026/04/29/london-meetup/

Reflection, that I don't know about.

It's compile time, so not as useful as the similar
Java feature (which offers run-time reflection).

With reflection, an application can obtain a list
of class member names, for example, along with
type information; or get the printable name
for an enumeration value (in debug or log messages,
for example).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 10/05/2026 18:08, Scott Lurndal wrote:

Paul Rubin <no.email@nospam.invalid> writes:

boltar@caprica.universe writes:

http://herbsutter.com/2026/04/29/london-meetup/

Reflection, that I don't know about.

It's compile time, so not as useful as the similar
Java feature (which offers run-time reflection).

With reflection, an application can obtain a list
of class member names, for example, along with
type information; or get the printable name
for an enumeration value (in debug or log messages,
for example).

It is more than that - C++26 reflection can also generate code, not just examine it. I don't know if all the details are finalised as yet, but
there are certainly interesting possibilities. I'm confident that it
will be of some use at least - I wrote code today that needed
copy-and-paste coding, which could have been generalised in C++26.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Boltar@caprica.Universe wrote:
|---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."| |---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 5/10/26 16:24, Niocl|is P||l Caile|in de Ghloucester wrote:

Boltar@caprica.Universe wrote: |---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."| |---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

Its a PITA because you have to have it correct before it compiles, as
opposed to C++ where you don't.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

In comp.lang.c++ geodandw <geodandw@gmail.com> wrote:

Its a PITA because you have to have it correct before it compiles, as opposed to C++ where you don't.

I have heard that Ada is being used in situations where correctness
is of utmost importance. One such field is aviation, I suppose.

br,
KK
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Correctness is a good thing.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Sun, 10 May 2026 17:52:30 -0400
geodandw <geodandw@gmail.com> gabbled:

On 5/10/26 16:24, Niocl|is P||l Caile|in de Ghloucester wrote:

Boltar@caprica.Universe wrote:
|---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."|
|---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

Its a PITA because you have to have it correct before it compiles, as >opposed to C++ where you don't.

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead of simply returning success/failure values.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 11/05/2026 09:22, boltar@caprica.universe wrote:

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

so, you're admitting that you've never seen Ada, Pascal has a horrible
syntax mainly because of it's semicolon as a separator mess. Semicolon's
end statements in Ada, also looks nothing like Pascal apart from begin
blocks, which aren't in block statements unlike Pascal.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Le 11/05/2026 |a 10:22, boltar@caprica.universe a |-crit :

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

Exceptions are much better for safety, since an exception cannot be ignored, while it is too easy to forget to check a success/failure return value.

"There is only one thing worse than a program that crashes: a program that produces wrong, but apparently correct results"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 11 May 2026 12:20:59 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 09:22, boltar@caprica.universe wrote:

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

so, you're admitting that you've never seen Ada, Pascal has a horrible

No, I never saw it while I was working on it, did everything blindfold.

syntax mainly because of it's semicolon as a separator mess. Semicolon's
end statements in Ada, also looks nothing like Pascal apart from begin >blocks, which aren't in block statements unlike Pascal.

The syntax is derived from pascal, stop pretending otherwise.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

boltar@caprica.universe wrote:

Its a PITA because its long winded like Java,

So Ada isn't optimal for code golf and obfuscation contests. Feel free
to choose another language for those purposes.
Each line or fragment of source code is written once and read many
times. Thus clarity is more important than saving keystrokes. Typing
speed isn't the bottleneck anyway. I spend more time thinking about the
correct solution than I do typing.

has the god awful pascal style syntax,

You mean a syntax that doesn't let you write "if(x = 0)" bugs? A syntax
that makes sense when read left-to-right, unlike C where the best way
to make sense of a declaration is to read it from the middle towards
both ends?
A syntax where instead of this:
}
}
}
}
you'll see this:
end if;
end loop;
end if;
end Foo;
If a closing brace is missing, a C/C++ compiler will spout lots of
misleading error messages, and then report the missing brace at the end
of the file rCo or even at the end of another file. An Ada compiler can
say "hey, an "end loop" is missing before this "end if" right here".
Yeah, how awful!

and far too many basic operations throw exceptions instead of simply returning success/failure values.

Here's an example from last year of how returning success/failure
values leads to bugs:
https://www.qualys.com/2025/02/18/openssh-mitm-dos.txt
Security researchers found several errors in the handling of error codes
in OpenSSH. One of them could be used to impersonate an SSH server. A
quote from their security advisory:
| - in verify_host_key() (when VerifyHostKeyDNS is enabled, at line 1538),
| if sshkey_from_private() returns any non-zero error code (at line
| 1543), then this error code is immediately returned to
| verify_host_key()'s caller (at line 1580);
|
| - unfortunately, in verify_host_key_callback() (verify_host_key()'s
| caller), only the return value -1 is treated as an error (at lines
| 101-103);
|
| - any other return value (for example, -2) is ignored, and zero
| (success) is mistakenly returned to verify_host_key_callback()'s
| caller (at line 104), as if no error had occurred, and without
| checking the server's host key at all.
With exceptions it's not so easy to get confused about what's success
and what's a failure.
Of course, code of lower quality than OpenSSH often neglects to check
for error codes at all. Forgetting to check for an exception doesn't
cause it to be silently treated as a success.
Bj||rn Persson
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 11 May 2026 16:16:04 +0200, J-P. Rosen wrote:

Le 11/05/2026 |a 10:22, boltar@caprica.universe a |-crit :

Its a PITA because its long winded like Java, has the god awful
pascal style syntax, and far too many basic operations throw
exceptions instead of simply returning success/failure values.

Exceptions are much better for safety, since an exception cannot be
ignored, while it is too easy to forget to check a success/failure
return value.

"There is only one thing worse than a program that crashes: a
program that produces wrong, but apparently correct results"

Worth also pointing out that Ada doesnrCOt require you to declare all
the exceptions a routine can return up front, unlike Java, where this
just adds to the clutter.

Also, Ada has typedefs, Java doesnrCOt. Ada has unsigned integers, Java doesnrCOt. Ada had generics from the start, Java had to tack them on afterwards, with some interesting consequences for backward
compatibiliy.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 11 May 2026 19:44:31 +0200
=?UTF-8?B?QmrDtnJu?= Persson <Bjorn@xn--rombobjrn-67a.se> gabbled: >boltar@caprica.universe wrote:

Its a PITA because its long winded like Java,

So Ada isn't optimal for code golf and obfuscation contests. Feel free
to choose another language for those purposes.

Each line or fragment of source code is written once and read many
times. Thus clarity is more important than saving keystrokes. Typing

I'm not going to defend the clarity of C++, frankly the syntax is a mess.
But overdone long windedness doesn't aid clarity any more than adding ever
more punctuation to the syntax does. As in all things there's a happy medium.

has the god awful pascal style syntax,

You mean a syntax that doesn't let you write "if(x =3D 0)" bugs? A syntax

Set and test is not always a bug depending on what construct its used in. Besides which, most (all?) modern C/C++ compilers will throw a warning anyway.

that makes sense when read left-to-right, unlike C where the best way
to make sense of a declaration is to read it from the middle towards
both ends?

Huh?

A syntax where instead of this:

}
}
}
}

Clean and tidy.

you'll see this:

end if;
end loop;
end if;
end Foo;

Yuck. Its visual noise.

If a closing brace is missing, a C/C++ compiler will spout lots of
misleading error messages, and then report the missing brace at the end
of the file =E2=80=93 or even at the end of another file. An Ada compiler c= >an
say "hey, an "end loop" is missing before this "end if" right here".
Yeah, how awful!

I'll give you that one.

and far too many basic operations throw exceptions instead of simply retu= >rning success/failure values.

Here's an example from last year of how returning success/failure
values leads to bugs:

https://www.qualys.com/2025/02/18/openssh-mitm-dos.txt

I'm sure they do, but sometimes checking return values is simpler and tidier than having to remember and check for everything that might end up in a
handler down the bottom of the code or even worse having begin-exception
blocks around every damn bit of code that might cause them if you don't
want a catch-all handler.

Security researchers found several errors in the handling of error codes
in OpenSSH. One of them could be used to impersonate an SSH server. A
quote from their security advisory:

There are many reasons for security holes in software. I imagine poor
checking of return codes is in the statistical noise compared to the more common ones.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 11 May 2026 22:33:09 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.

Really? The ONLY reason for the -> operator being overloaded for return
values is because thats how it was decided to implement lambda syntax
back in 2011 for reasons best known to themselves. Using it in normal
function definitions is frankly assinine.

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

etc is just poncy coding style in order to make the author seem smart plus
the syntax is idiotic because in this case "auto" is overloaded simply to be
a function start placeholder. If the semantics were sane it wouldn't be needed but I imagine that would make the lexical analysis even more complicated.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 02:21:51 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Mon, 11 May 2026 16:16:04 +0200, J-P. Rosen wrote:

"There is only one thing worse than a program that crashes: a
program that produces wrong, but apparently correct results"

Worth also pointing out that Ada doesnrCOt require you to declare all
the exceptions a routine can return up front, unlike Java, where this
just adds to the clutter.

Also, Ada has typedefs, Java doesnrCOt. Ada has unsigned integers, Java >doesnrCOt. Ada had generics from the start, Java had to tack them on >afterwards, with some interesting consequences for backward
compatibiliy.

Java generics are half arsed anyway making them utterly pointless. Template types can only be types derived from Object - ie not basic types such as
int or char - meaning their bring nothing to the table given all classes
are derived from Object anyway. Java generics are just syntactic sugar added
to keep some loudmouths happy.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient and insecure c then.

syntax mainly because of it's semicolon as a separator mess.
Semicolon's end statements in Ada, also looks nothing like Pascal
apart from begin blocks, which aren't in block statements unlike Pascal.

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient and >insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.

Looks exactly like it to me.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 12/05/2026 16:06, boltar@caprica.universe wrote:

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient
and insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

Have you not noticed you're also posting to the ada group?

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.

Looks exactly like it to me.

Then you haven't looked deeply enough.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 08:42:46 -0000 (UTC), boltar wrote:

Java generics are half arsed anyway making them utterly pointless.
Template types can only be types derived from Object - ie not basic
types such as int or char - meaning their bring nothing to the table
given all classes are derived from Object anyway. Java generics are
just syntactic sugar added to keep some loudmouths happy.

Java preserves the C++ distinction between rCLPODsrCY (I think it calls
them rCLprimitive typesrCY) and classes/structs. I think the limitations
you point to apply to C++ as well. And possibly even Ada.

There are languages where rCLevery value is an objectrCY. Python is
probably the most popular one right now -- and justifiably so.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:

On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.

Really? The ONLY reason for the -> operator being overloaded for
return values is because thats how it was decided to implement
lambda syntax back in 2011 for reasons best known to themselves.

There is another reason: a result type that depends on the argument
types.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 17:27:36 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 12/05/2026 16:06, boltar@caprica.universe wrote:

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold. >>>

So, you just came here to be an idiot troll, go back to your ancient
and insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

Have you not noticed you're also posting to the ada group?

Oddly enough I don't always read the header field lines when going through dozens of posts, no.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 20:37:01 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 12 May 2026 08:42:46 -0000 (UTC), boltar wrote:

Java generics are half arsed anyway making them utterly pointless.
Template types can only be types derived from Object - ie not basic
types such as int or char - meaning their bring nothing to the table
given all classes are derived from Object anyway. Java generics are
just syntactic sugar added to keep some loudmouths happy.

Java preserves the C++ distinction between rCLPODsrCY (I think it calls
them rCLprimitive typesrCY) and classes/structs. I think the limitations
you point to apply to C++ as well. And possibly even Ada.

Not to C++. Template types can be anything including basic types such as int.

There are languages where rCLevery value is an objectrCY. Python is
probably the most popular one right now -- and justifiably so.

Yes, I rather like Python though not for that reason. It Just Works, slowly, but IME it solves 90% of problems that in the past would have been written
in C++ or Java that don't require massive compute.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 12 May 2026 20:38:59 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:

On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.

Really? The ONLY reason for the -> operator being overloaded for
return values is because thats how it was decided to implement
lambda syntax back in 2011 for reasons best known to themselves.

There is another reason: a result type that depends on the argument
types.

Huh? You can't change the result type once you've defined it. If you want
an auto return type you don't add "-> <type>" on the end.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 13/05/2026 09:55, boltar@caprica.universe wrote:

On Tue, 12 May 2026 20:38:59 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:

On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.

Really? The ONLY reason for the -> operator being overloaded for
return values is because thats how it was decided to implement
lambda syntax back in 2011 for reasons best known to themselves.

There is another reason: a result type that depends on the argument
types.

Huh? You can't change the result type once you've defined it. If you want
an auto return type you don't add "-> <type>" on the end.

Yes, you do /exactly/ that if your return type depends on the argument
types.

template<typename T1, typename T2>
X add(T1 a, T2 b)
{
return a + b;
}

What type should X be? It depends on the types of "a" and "b" (which
might be class types here). So you can write:

template<typename T1, typename T2>
auto add(T1 a, T2 b) -> decltype(a + b)
{
return a + b;
}

It is fair to say that this form is less needed after C++14 return type deduction meant that you could often use "auto" without specifying the
return type like this. But of course for stand-alone function
declarations in a header without their implementation, you can't do
return type deduction - thus trailing return type can be useful.


You might also use it for complicated types, such as returning a
function pointer, where it is clearer:

int (*get_function_pointer(int x))(int);

auto get_func_pointer(int x) -> int(*)(int);

Many people find the second form easier to read (it's much like the
difference between typedef and using for type declarations).


<https://cppreference.com/cpp/language/function>

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Wed, 13 May 2026 07:55:05 -0000 (UTC), boltar wrote:

On Tue, 12 May 2026 20:38:59 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:

On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:

Its a PITA because its long winded like Java, has the god awful
pascal style syntax ...

Even C++ is now discovering why it can be preferable to have the
function return type specified after the arguments, rather than
before.

Really? The ONLY reason for the -> operator being overloaded for
return values is because thats how it was decided to implement
lambda syntax back in 2011 for reasons best known to themselves.

There is another reason: a result type that depends on the argument
types.

Huh? You can't change the result type once you've defined it. If you
want an auto return type you don't add "-> <type>" on the end.

You donrCOt really know much about C++, do you?

<https://cppreference.com/cpp/language/function>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Wed, 13 May 2026 10:17:32 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 13/05/2026 09:55, boltar@caprica.universe wrote:
template<typename T1, typename T2>
X add(T1 a, T2 b)
{
return a + b;
}

What type should X be? It depends on the types of "a" and "b" (which
might be class types here). So you can write:

template<typename T1, typename T2>
auto add(T1 a, T2 b) -> decltype(a + b)
{
return a + b;
}

A sane syntax would have been

template<typename T1, typename T2>
(T1 + T2) add(T1 a, T2 b)
{
:
}

But this is C++ so not a chance, lets make it as verbose as possible.

You might also use it for complicated types, such as returning a
function pointer, where it is clearer:

int (*get_function_pointer(int x))(int);

auto get_func_pointer(int x) -> int(*)(int);

I'll give you that, but the C function pointer syntax was unnecessarily
messy and there's no reason C++ couldn't have tidied it up even before std::function came along. Something like:

int (*(int))get_func_pointer(x)
{
:
}

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 14/05/2026 10:01, boltar@caprica.universe wrote:

On Wed, 13 May 2026 10:17:32 +0200
David Brown <david.brown@hesbynett.no> gabbled:

On 13/05/2026 09:55, boltar@caprica.universe wrote:
template<typename T1, typename T2>
X add(T1 a, T2 b)
{
-a-a-a-areturn a + b;
}

What type should X be?-a It depends on the types of "a" and "b" (which
might be class types here).-a So you can write:

template<typename T1, typename T2>
auto add(T1 a, T2 b) -> decltype(a + b)
{
-a-a-a-areturn a + b;
}

A sane syntax would have been

template<typename T1, typename T2>
(T1 + T2) add(T1 a, T2 b)
{
:
}

But this is C++ so not a chance, lets make it as verbose as possible.

You might also use it for complicated types, such as returning a
function pointer, where it is clearer:

int (*get_function_pointer(int x))(int);

auto get_func_pointer(int x) -> int(*)(int);

I'll give you that, but the C function pointer syntax was unnecessarily
messy and there's no reason C++ couldn't have tidied it up even before std::function came along. Something like:

int (*(int))get_func_pointer(x)
{
:
}

I don't think anyone sees the C or C++ type syntaxes as being the nicest conceivable for a programming language. But the languages are what they
are, stretching back to a time when the syntax choices were made as good design decisions. Modern C++ cannot start from scratch - new features
have to fit with the existing language, existing tools, existing
programmers, and existing code. Sometimes things can be "tidied up" a
bit - that's exactly the case for trailing return types. (It might have
been nicer if a new keyword - say, "func" - had been introduced to mean exactly the same as "auto" but only available for function declarations.
But new keywords are not free in an established language.)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 14 May 2026 11:22:47 +0200
David Brown <david.brown@hesbynett.no> gabbled:

I don't think anyone sees the C or C++ type syntaxes as being the nicest >conceivable for a programming language. But the languages are what they >are, stretching back to a time when the syntax choices were made as good >design decisions. Modern C++ cannot start from scratch - new features
have to fit with the existing language, existing tools, existing >programmers, and existing code. Sometimes things can be "tidied up" a
bit - that's exactly the case for trailing return types. (It might have >been nicer if a new keyword - say, "func" - had been introduced to mean >exactly the same as "auto" but only available for function declarations.
But new keywords are not free in an established language.)

True, but sometimes the bullet has to be bitten and they just need to
be introduced. If they cause backwards compat problems with older software thats just tough luck. Eg new, delete, virtual, try, throw etc were all new keywords that are not in C.

--- Synchronet 3.22a-Linux NewsLink 1.2