Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123793 > unrolled thread

"Herb Sutter: Why C++ Is Growing and What C++26 Means for Production Systems "

Back to article view | Back to comp.lang.c++

Contents

  "Herb Sutter: Why C++ Is Growing and What C++26 Means for Production Systems " Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-09 02:13 -0500
    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Production Systems " Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-05-09 07:31 -0400
      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-09 14:57 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-05-09 21:57 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Paul Rubin <no.email@nospam.invalid> - 2026-05-10 01:24 -0700
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 03:30 -0700
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-10 15:44 +0000
            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-05-10 20:24 +0000
              Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for geodandw <geodandw@gmail.com> - 2026-05-10 17:52 -0400
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 22:07 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-05-11 08:00 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-11 08:22 +0000
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-11 12:20 +0100
                    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-11 15:08 +0000
                      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-12 15:21 +0100
                        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 15:06 +0000
                          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-12 17:27 +0100
                            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:49 +0000
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "J-P. Rosen" <rosen@adalog.fr> - 2026-05-11 16:16 +0200
                    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 02:21 +0000
                      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:42 +0000
                        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 20:37 +0000
                          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:52 +0000
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2026-05-11 19:44 +0200
                    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:30 +0000
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-11 22:33 +0000
                    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:38 +0000
                      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 20:38 +0000
                        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:55 +0000
                          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for David Brown <david.brown@hesbynett.no> - 2026-05-13 10:17 +0200
                            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-14 08:01 +0000
                              Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for David Brown <david.brown@hesbynett.no> - 2026-05-14 11:22 +0200
                                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-14 15:00 +0000
                          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-13 21:33 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-01 05:49 +0000
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Paul Rubin <no.email@nospam.invalid> - 2026-10-31 22:57 -0700
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-02 11:32 -0500
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 16:08 +0000
            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for David Brown <david.brown@hesbynett.no> - 2026-05-10 18:36 +0200

Page 2 of 2 — ← Prev page 1 [2]

#123846 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 doesn’t 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 doesn’t. Ada has unsigned integers, Java
>doesn’t. 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.

[toc] | [prev] | [next] | [standalone]

#123851 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 “PODs” (I think it calls
them “primitive types”) and classes/structs. I think the limitations
you point to apply to C++ as well. And possibly even Ada.

There are languages where “every value is an object”. Python is
probably the most popular one right now -- and justifiably so.

[toc] | [prev] | [next] | [standalone]

#123854 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 “PODs” (I think it calls
>them “primitive types”) 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 “every value is an object”. 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.

[toc] | [prev] | [next] | [standalone]

#123833 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 – 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

[toc] | [prev] | [next] | [standalone]

#123844 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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.

[toc] | [prev] | [next] | [standalone]

#123841 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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.

[toc] | [prev] | [next] | [standalone]

#123845 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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.

[toc] | [prev] | [next] | [standalone]

#123852 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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

> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro 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.

[toc] | [prev] | [next] | [standalone]

#123855 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 D’Oliveiro 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.

[toc] | [prev] | [next] | [standalone]

#123856 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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 D’Oliveiro 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>

[toc] | [prev] | [next] | [standalone]

#123859 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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)
{
:
}

[toc] | [prev] | [next] | [standalone]

#123860 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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)
>> {
>>     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)
> {
> :
> }
> 

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.)

[toc] | [prev] | [next] | [standalone]

#123861 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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.

[toc] | [prev] | [next] | [standalone]

#123857 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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

> On Tue, 12 May 2026 20:38:59 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:
>>
>>> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro 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 don’t really know much about C++, do you?

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

[toc] | [prev] | [next] | [standalone]

#125543 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

On Sun, 1 Nov 2026 01:34:01 -0000 (UTC), Kevin Chadwick wrote:

>> Its a PITA because you have to have it correct before it compiles,
>> as opposed to C++ where you don't.
>
> SO much fun troubleshooting at runtime instead.

Kidding, right?

It’s been a while since I did some C++ code, but I remember wading
through *massive* screeds of error messages every time there was a
type mismatch on some function argument, and the GNU C++ compiler
would list *every single possible overload candidate*, so you got
dozens, possibly even hundreds, of lines of messages just for one
error. And you had to check them *all* to be sure which one you meant,
and to figure out what to fix to get the compiler to agree.

[toc] | [prev] | [next] | [standalone]

#125544 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> It’s been a while since I did some C++ code, but I remember wading
> through *massive* screeds of error messages

Haskell is like that too, but the trick for both Haskell and C++ is that
the diagnostics are usually accurate about what line number has the
error.  So you can often look at the code at that location and figure
out what is wrong, without having to examine the error message too
carefully.

C++ Concepts are supposed to decrease the message spew by a lot as well.

[toc] | [prev] | [next] | [standalone]

#125625 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

Lawrence D’Oliveiro wrote this screed in ALL-CAPS (fixed):

> On Sun, 1 Nov 2026 01:34:01 -0000 (UTC), Kevin Chadwick wrote:
>
>>> Its a PITA because you have to have it correct before it compiles,
>>> as opposed to C++ where you don't.
>>
>> SO much fun troubleshooting at runtime instead.
>
> Kidding, right?
>
> It’s been a while since I did some C++ code, but I remember wading
> through *massive* screeds of error messages every time there was a
> type mismatch on some function argument, and the GNU C++ compiler
> would list *every single possible overload candidate*, so you got
> dozens, possibly even hundreds, of lines of messages just for one
> error. And you had to check them *all* to be sure which one you meant,
> and to figure out what to fix to get the compiler to agree.

I see those a lot, but in almost all cases I can ignore all the
follow-on information and go to the offending line of code and
then *doh* slap my forehead.

I'll admit it's a pain when you forget the closing "}" of a
universal initializer.

-- 
	"But I don't want to go on the cart..."
	"Oh, don't be such a baby!"
	"But I'm feeling much better..."
	"No you're not... in a moment you'll be stone dead!"
		-- Monty Python, "The Holy Grail"

[toc] | [prev] | [next] | [standalone]

#123803 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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).

[toc] | [prev] | [next] | [standalone]

#123804 — Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web