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

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

Re: We have a new standard!

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-01 18:25 +0200
    Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-01 16:33 +0000
      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-01 09:41 -0800
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 08:06 +0100
        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-02 09:23 +0000
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 13:51 +0100
            Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 14:07 +0000
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:54 +0100
                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 17:15 +0000
                  Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:58 -0800
                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:13 +0000
                      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:22 -0800
                        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:17 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:31 +0100
                            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 11:34 +0000
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 14:01 +0100
                                Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 15:49 +0000
                      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:42 -0800
                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-02 15:20 -0500
                  Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 13:43 +0100
                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 08:11 -0500
                      Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 16:33 +0200
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 10:50 -0500
                          Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 16:09 +0000
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:53 -0500
                              Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-03 17:10 +0000
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 12:14 -0500
                                  Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:13 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 18:17 +0100
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 13:58 -0500
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:39 +0100
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 09:56 -0500
                          Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 21:46 +0200
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 21:06 -0500
                              Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 18:32 -0800
                              Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-04 20:08 +0200
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 14:46 -0500
                                Re: We have a new standard! wij <wyniijj5@gmail.com> - 2025-01-05 07:14 +0800
                                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-06 08:38 +0000
                                  Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-07 08:40 -0500
                                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-07 14:04 +0000
                                      Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-08 14:52 -0500
                                        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-08 13:31 -0800
                                        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-09 08:39 +0000
                                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-07 21:32 -0500
                        Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:49 -0800
                      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 17:12 +0100
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:56 -0500
            Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 17:35 +0200
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:57 +0100
                Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 19:55 +0200
        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:40 -0800
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 09:42 +0100
      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:38 -0800
        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:09 +0000
          Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:19 -0800
            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:15 +0000
    Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-01 22:43 +0200
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 07:56 +0100
      Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-02 00:39 -0800
        Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 12:31 +0200
          Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 14:59 +0200
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 15:50 +0200
          Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-07 21:15 -0800
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-08 08:44 +0200
              Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-08 11:44 +0200
                Re: We have a new standard! James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-08 15:04 -0500
                Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 08:49 -0800
              Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 09:12 -0800
                Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-14 19:53 +0200
            Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-08 14:43 -0800
      Re: We have a new standard! scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:51 +0000
    Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 16:47 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#121422

On Tue, 7 Jan 2025 08:40:47 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wibbled:
>Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:
>
>> On Sat, 4 Jan 2025 20:08:00 +0200
>> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>>>On 04.01.2025 04:06, Sam wrote:
>>>> void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>>>
>>>That's the first good idea from you in this discussion. I still do not 
>>>see much point in exception specifications, but such a typedef would at 
>>>least make life easier for me on this Alternate Earth.
>>>
>>>PS. Nowadays they prefer `using` instead of `typedef`.
>>
>> I never understood the point of that. Why not increase the semantic scope
>> of "typedef" instead of having 2 keywords that in a lot of circumstances
>> do the same thing?
>
>Because using is a nicer to read?

Who knows. The C++ committee certainly has form on this - typename replaced 
class in template definitions when they realised 10 years after everyone else
that reusing class in that particular case was somewhat confusing.

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

#121427

Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:

> On Tue, 7 Jan 2025 08:40:47 -0500
> Chris Ahlstrom <OFeem1987@teleworm.us> wibbled:
>>Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:
>>
>>> On Sat, 4 Jan 2025 20:08:00 +0200
>>> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>>>>On 04.01.2025 04:06, Sam wrote:
>>>>> void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>>>>
>>>>That's the first good idea from you in this discussion. I still do not 
>>>>see much point in exception specifications, but such a typedef would at 
>>>>least make life easier for me on this Alternate Earth.
>>>>
>>>>PS. Nowadays they prefer `using` instead of `typedef`.
>>>
>>> I never understood the point of that. Why not increase the semantic scope
>>> of "typedef" instead of having 2 keywords that in a lot of circumstances
>>> do the same thing?
>>
>>Because using is a nicer to read?
>
> Who knows. The C++ committee certainly has form on this - typename replaced 
> class in template definitions when they realised 10 years after everyone else
> that reusing class in that particular case was somewhat confusing.

Stroustrup in section 23.2 of his 4th edition C++ book notes that
these two are equivalent:

    template<typename X>
    template<class X>

but that for typename X, X need not be a class.


-- 
Telling the truth to people who misunderstand you is generally promoting
a falsehood, isn't it?
		-- A. Hope

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

#121429

Chris Ahlstrom <OFeem1987@teleworm.us> writes:
[...]
> Stroustrup in section 23.2 of his 4th edition C++ book notes that
> these two are equivalent:
>
>     template<typename X>
>     template<class X>
>
> but that for typename X, X need not be a class.

X need not be a class in either case.

"""
You may prefer the shorter and equivalent form template<class C>. In
either case, C is a type name; it need not be the name of a class.
"""

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121431

On Wed, 8 Jan 2025 14:52:31 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wibbled:
>Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:
>> Who knows. The C++ committee certainly has form on this - typename replaced 
>> class in template definitions when they realised 10 years after everyone else
>
>> that reusing class in that particular case was somewhat confusing.
>
>Stroustrup in section 23.2 of his 4th edition C++ book notes that
>these two are equivalent:
>
>    template<typename X>
>    template<class X>
>
>but that for typename X, X need not be a class.

Huh? X doesn't have to be a class in the 2nd example either.

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

#121423

Chris Ahlstrom writes:

> Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:
>
> > I never understood the point of that. Why not increase the semantic scope
> > of "typedef" instead of having 2 keywords that in a lot of circumstances
> > do the same thing?
>
> Because using is a nicer to read?

I was wondering about that, too. I forget the exact keywords I used when  
searching for the answer, but I did read a convincing argument in favor of  
a using declaration.

This was not the main argument, but there are some things that can be done  
with using that cannot be done with a typedef. For example, using a real- 
life example:

template<typename basedon_t>
using derivedvaluelist=ref<derivedvalueListObj<basedon_t>,
                           derivedvalueListBase<basedon_t>>;

There is no equivalent typedef declaration, for this.

Given that, here's the main argument: if you originally start out with a  
using declaration, instead of a typedef:

using derivedvaluelist=ref<derivedvalueListObj, derivedvalueListBase>;

then, at some point later: going from that, to the template, looks more  
"logical" then replacing a typedef with something else, entirely.

TLDR: the "left" and the "right" side component, of the alias declaration,  
is consistent, versus swapped.

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

#121404

On 01/03/2025 06:33 AM, Paavo Helde wrote:
> On 03.01.2025 15:11, Sam wrote:
>> David Brown writes:
>>
>>> I think it became fairly quickly apparent that "throw(...)"
>>> specifiers were not as useful in practice as had been hoped, and
>>> relatively few programmers used them except in the form "throw()".
>>> So "throw(...)" was deprecated in C++11 and has been valid until
>>> C++17 (with compilers implementations being free to accept it as a
>>> non-standard extension far beyond that).
>>
>> It should be painfully obvious that the right thing to do should've
>> been to merge throw specifications into function signatures, allowing
>> exception handling to be validated at compile-time, i.e. what Java
>> did. Instead of that we have the current state of affairs where the only
>
> It might be obvious to you, but not for everybody. What exact problem
> can be solved by validating thrown exception classes at compile time?
> And how would a developer of a base class know which exceptions I might
> want to throw from an overridden virtual function in a derived class,
> which might be developed and compiled fully separately from the base class?
>
>
>  > half-assed solution is to have all exception classes derived from a
>  > superclass, i.e. std::exception, and then play musical chairs to catch
>  > exceptions.
>
> My Java is rusty, but isn't it in Java that all exception classes must
> be derived from a single superclass (Throwable)?
>
>

I think exceptions are critical, i.e. critically important
and necessary, simply because they can declare what otherwise
results that code that doesn't model what makes it undefined
behavior is undefined behavior, and any interface has an
arbitrarily not-impossible failure mode.

So, when Rust was like "we're safe and no exceptions"
I was like "that's un-safe and un-usual".
As are more than half of their "crates".

When Google style was like "we don't use exceptions"
I was like "did you forget setjmp and longjmp".

Anyways the exception specification particularly,
and everyone knows it's a real pain sometimes
because you have to learn the semantics and how
to reasonably catch exceptions besides die-ing,
or swallow-ing, just like handling "structured
return codes" or today's usual idea "exit 0 or exit 1",
has that it's like "fire and forget protocols",
who have no idea when they make huge puddles.


Then, C++ with "throw whatever you want", I understand
that entirely complicates the type-analysis, as with
regards to closures in types as it were, and that
having everything extend std::exception and throwing
refs as it were, seems the way of things though that
always confused me why it was refs instead of pointers,
figuring that should've come out the scope, anyways
I'm a big fan of exceptions they're very important rules.

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

#121393

On 03/01/2025 14:11, Sam wrote:
> David Brown writes:
> 
>> I think it became fairly quickly apparent that "throw(...)" specifiers 
>> were not as useful in practice as had been hoped, and relatively few 
>> programmers used them except in the form "throw()".  So "throw(...)" 
>> was deprecated in C++11 and has been valid until C++17 (with compilers 
>> implementations being free to accept it as a non-standard extension 
>> far beyond that).
> 
> It should be painfully obvious that the right thing to do should've been 
> to merge throw specifications into function signatures, allowing 
> exception handling to be validated at compile-time, i.e. what Java did. 

That's wrong on many levels.

First, what you think should be "obvious" now might not have been 
obvious at the time the relevant decisions were made - it's a lot easier 
to see problems with hindsight than to predict them in advance.

Secondly, what /you/ think is "obvious" can differ greatly from what 
other people think is obvious.  To /me/, it's obvious that dynamic 
exceptions are a bad idea in any compiled language suitable for systems 
programming.  Exceptions that can pass through functions are "hidden 
gotos" - clearly worse even than explicit "gotos".  Rather, it is 
"obvious" that the language should have had something akin to 
std::expected<> from the start, with syntactic sugar to reduce the 
boilerplate code to a minimal and compiler implementations using flag 
registers to get optimised code generation.  That's /obvious/.

Thirdly, you are again mistaking how Java supports exceptions. 
Unchecked exceptions in Java are not validated at compile time in any way.

Fourthly, you appear to be completely ignorant about the tools available 
in the early days of C++.  C++ had to work alongside existing linkers 
and related tools, which would not have been able to support such a 
system.  Even with more modern tools, to get a good system of checked 
exceptions without having to add an enormous source code burden on the 
programmer, you would need some kind of compiled interface file tracking 
exactly which exceptions each function could throw and pass on. 
Otherwise if "foo" calls "bar" and passes on any exception thrown by 
"bar" up the chain to the caller of "foo", you'd need to change the 
declaration of "foo" every time the list of exceptions throwable by 
"bar" (or any function it calls) changes.  That would be a nightmare in 
maintenance, and loses the whole point of exceptions.

Fifthly, you appear to be completely ignorant of how C++ is intended to 
work beside code written in C - the exception mechanism in C++ is 
designed to be transparent to C functions.  Without that, there would be 
no object code level compatibility.

> Instead of that we have the current state of affairs where the only 
> half-assed solution is to have all exception classes derived from a 
> superclass, i.e. std::exception, and then play musical chairs to catch 
> exceptions.
> 

There is no such requirement in C++.  For convenience, the exceptions 
thrown by standard library functions are all derived from 
std::exception, but you are free to throw whatever types you like.

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

#121395

David Brown writes:

> That's wrong on many levels.
>
> First, what you think should be "obvious" now might not have been obvious at  
> the time the relevant decisions were made - it's a lot easier to see  
> problems with hindsight than to predict them in advance.

It was obvious to me at the turn of the century, when I returned to C++  
after spending a brief time hacking Java, looked at what C++ did with  
exceptions, and LOLed.

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

#121374

On Thu, 2 Jan 2025 13:51:53 +0100
David Brown <david.brown@hesbynett.no> wrote:

> 
> Could this all have been done from the start of C++?  In theory, yes
> - in practice no.  std::format and std::print rely on various modern
> C++ features, such as compile-time evaluation of functions, 

It does not look like dependence of std::format on compile-time
evaluation is a requirement of standard rather than implementation
choice of g++ and of clang++.

MSVC 19.30.30706 compiles the following code just fine:

#include <cstdio>
#include <format>

int main(int argc, char** argv)
{
  if (argc >= 3) {
    std::string s = std::format(argv[1], argv[2]);
    printf("%s\n", s.c_str());
  }
  return 0;
}

When run, it produces expected results.

Or, may be, it's because this version of MSVC is not fully C++20
complient.

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

#121376

On 02/01/2025 16:35, Michael S wrote:
> On Thu, 2 Jan 2025 13:51:53 +0100
> David Brown <david.brown@hesbynett.no> wrote:
> 
>>
>> Could this all have been done from the start of C++?  In theory, yes
>> - in practice no.  std::format and std::print rely on various modern
>> C++ features, such as compile-time evaluation of functions,
> 
> It does not look like dependence of std::format on compile-time
> evaluation is a requirement of standard rather than implementation
> choice of g++ and of clang++.
> 
> MSVC 19.30.30706 compiles the following code just fine:
> 
> #include <cstdio>
> #include <format>
> 
> int main(int argc, char** argv)
> {
>    if (argc >= 3) {
>      std::string s = std::format(argv[1], argv[2]);
>      printf("%s\n", s.c_str());
>    }
>    return 0;
> }
> 
> When run, it produces expected results.
> 
> Or, may be, it's because this version of MSVC is not fully C++20
> complient.
> 

<https://en.cppreference.com/w/cpp/utility/format/format>

Apparently P2216R3 made compile-time checks for std::format a 
requirement.  I don't know where that fits with standard versions, or 
compiler support.  I am just going by what it says in the reference here.

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

#121378

On Thu, 2 Jan 2025 17:57:06 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 02/01/2025 16:35, Michael S wrote:
> > On Thu, 2 Jan 2025 13:51:53 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >   
> >>
> >> Could this all have been done from the start of C++?  In theory,
> >> yes
> >> - in practice no.  std::format and std::print rely on various
> >> modern C++ features, such as compile-time evaluation of functions,
> >>  
> > 
> > It does not look like dependence of std::format on compile-time
> > evaluation is a requirement of standard rather than implementation
> > choice of g++ and of clang++.
> > 
> > MSVC 19.30.30706 compiles the following code just fine:
> > 
> > #include <cstdio>
> > #include <format>
> > 
> > int main(int argc, char** argv)
> > {
> >    if (argc >= 3) {
> >      std::string s = std::format(argv[1], argv[2]);
> >      printf("%s\n", s.c_str());
> >    }
> >    return 0;
> > }
> > 
> > When run, it produces expected results.
> > 
> > Or, may be, it's because this version of MSVC is not fully C++20
> > complient.
> >   
> 
> <https://en.cppreference.com/w/cpp/utility/format/format>
> 
> Apparently P2216R3 made compile-time checks for std::format a 
> requirement.  I don't know where that fits with standard versions, or 
> compiler support.  I am just going by what it says in the reference
> here.
> 
>

P2216R3 was published 2 or 3 months after C++20. I also don't know if
rules allow for edition of the Standard to be changed retroactively.
Supposedly, it is part of C++23.

Anyway, I believe in good intention of the committee, but [so far]
results in practice are not great.
That is, on the MS side (19.30.30706) std::format() accepts any crap
without blinking. Hopefully, more recent versions work better.
On the gcc and clang sides quite new versions that I have installed
were able to catch few simple argument type bugs that I tried to
introduce, but error message were unhelpful.

For comparison, when the same type bugs are made in printf then all 3
compilers produce very informative warnings.

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

#121382

David Brown <david.brown@hesbynett.no> writes:
[...]
> IMHO the real mistake for iostreams for formatted output was making
> them modal - IO manipulators are a /terrible/ idea.

Agreed.

>                                                      The type system
> and overloading should have been used instead, so that we would write
> :
>
> 	cout << hex(x);
>
> instead of
>
> 	cout << hex << x << dec;

Note that the latter sets cout to decimal mode, not to whatever mode it
had before.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121385

On 02/01/2025 22:40, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> IMHO the real mistake for iostreams for formatted output was making
>> them modal - IO manipulators are a /terrible/ idea.
> 
> Agreed.
> 
>>                                                       The type system
>> and overloading should have been used instead, so that we would write
>> :
>>
>> 	cout << hex(x);
>>
>> instead of
>>
>> 	cout << hex << x << dec;
> 
> Note that the latter sets cout to decimal mode, not to whatever mode it
> had before.
> 

And that is the biggest problem with modal settings like this.  Putting 
it to what you guess is the most likely previous setting is the best you 
can do (without using extra wrapper code).

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

#121381

Muttley@dastardlyhq.com writes:
[...]
> Plus overloading << and >> was a cretinous decision. There was zero reason
> he couldn't have created some new operators to avoid confusion, <<< and >>>
> or <= , => for example where such combinations in C would never be legal
> syntax anyway.

<= is already an operator.  <<< and >>> are not, but at least >>>
exists in some other languages, which could lead to confusion
(admittedly that's not a very strong argument).

I wouldn't have minded having new operators for I/O, but I'm not sure
what characters would have been used.  Perhaps something involving
"@"?

In any case, I don't see the overloading of << and >> for I/O as
a big problem.  The predecence is a bit funny, but that can be
addressed with parentheses.  Visually, << and >> show the direction
in which the data is flowing.  (The statefulness of C++ streams is
deeply annoying, though.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121386

On Thu, 02 Jan 2025 13:38:17 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>Muttley@dastardlyhq.com writes:
>[...]
>> Plus overloading << and >> was a cretinous decision. There was zero reason
>> he couldn't have created some new operators to avoid confusion, <<< and >>>
>> or <= , => for example where such combinations in C would never be legal
>> syntax anyway.
>
><= is already an operator.  <<< and >>> are not, but at least >>>

True, my bad.

>exists in some other languages, which could lead to confusion
>(admittedly that's not a very strong argument).

Not sure why an operator existing in another language would cause confusion.
Does the "for" keyword being almost universal confuse C++ devs?

>I wouldn't have minded having new operators for I/O, but I'm not sure
>what characters would have been used.  Perhaps something involving
>"@"?

It doesn't have to be pretty, so long as its unique.

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

#121400

Muttley@DastardlyHQ.org writes:
> On Thu, 02 Jan 2025 13:38:17 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
[...]
>>I wouldn't have minded having new operators for I/O, but I'm not sure
>>what characters would have been used.  Perhaps something involving
>>"@"?
>
> It doesn't have to be pretty, so long as its unique.

It doesn't have to be unique, as demonstrated by several decades of
experience with << and >>.

In my opinion, legibility and ease of typing are more important than
uniqueness.  << and >> are easier to type and more visually suggestive
than, say, @< and @>.

C and C++ reuse operator symbols because they're chosen from the ASCII
punctuation characters, and there are only so many of them.  (Requiring
non-ASCII characters for some operators would be inconvenient; I don't
have them on my keyboard.)

Note that operators don't have to consist of punctuation symbols (see
sizeof, new, etc.).  An alternative might have been to introduce "in"
and "out" operators in place of ">> and "<<".  But I wouldn't suggest
making such a change now.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121408

On Fri, 03 Jan 2025 11:19:53 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> gabbled:
>Muttley@DastardlyHQ.org writes:
>> On Thu, 02 Jan 2025 13:38:17 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>[...]
>>>I wouldn't have minded having new operators for I/O, but I'm not sure
>>>what characters would have been used.  Perhaps something involving
>>>"@"?
>>
>> It doesn't have to be pretty, so long as its unique.
>
>It doesn't have to be unique, as demonstrated by several decades of
>experience with << and >>.

Something being used for decades doesn't mean its any good or C++ would
never have evolved from C with Classes.

>In my opinion, legibility and ease of typing are more important than
>uniqueness.  << and >> are easier to type and more visually suggestive
>than, say, @< and @>.

Easier to type? You're seriously going with that as a reason? How hard
exactly would <@ or <# be to type?

>Note that operators don't have to consist of punctuation symbols (see
>sizeof, new, etc.).  An alternative might have been to introduce "in"
>and "out" operators in place of ">> and "<<".  But I wouldn't suggest
>making such a change now.

No one is suggesting making the change now. This is with hindsight.

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

#121362

On 01.01.2025 18:25, Michael S wrote:
> On 27 Dec 2024 14:47:51 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) wrote:
> 
>>    According to one web site, C++23 (ISO/IEC 14882:2024) was released
>>    October 19, 2024.
>>
>>    (Sorry if it was mentioned here then, and I just did not notice!)
>>
>>
> 
> I tried std::print both with gcc 14.2 and with clang 19.1.6 under
> Windows/msys2 (ucrt variant of x86-64 toolsests). It works as
> advertised.
> That is, an Windows 7 in default console windows it works as advertised
> for as long as you had chosen a font that supports all languages that
> you want to see. A default (Lucudia Console) was not good enough for my
> mix of languages, but (less elegantly looking) Currier New did the job.
> Supposedly, on newer versions of Windows it will work with default
> fonts as well.
> For those who want to try it: new version of compiler is not enough,
> you have to install new C++ libraries (in my case,
> mingw-w64-ucrt-x86_64-libc++). And don't forget to specify -lstdc++exp
> during linking.
> 
> Now to why, despite said above, I wouldn't use std::print() in its
> current incarnation neither in production nor in hobby programs:
> because compilation is too slow. ~4 seconds on the old home PC. I
> didn't try on newer machines yet, but would be surprised if any of them
> beats 2 seconds. Which is way above my threshold of inconvenience.

Whenever I recompile my program, the company-mandated security software 
will check it against viruses (again!) for 5 seconds at least. I have 
(almost) got used to it...

> 
> 
> Nevertheless, it is a step in right direction.
> Introduction of format() already showed that C++ committee is aware of
> of the fact that "Stroustrup streams" are crap not only relatively to
> format/printing facilities of more modern languages, but relatively
> to what we have in C as well. std::print() proves that committee is not
> only aware of the fact, but finally willing to consider fixes.

Half of the slowness of both in C printf() and C++ streams comes from 
the locale support, which is often unneeded and would just slow things 
down. If I have understood correctly, std::print() does not use locale 
by default, so has a chance to be much faster. If so, then definitely 
this is a step in the right direction.

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

#121364

On 01/01/2025 21:43, Paavo Helde wrote:
> On 01.01.2025 18:25, Michael S wrote:

>> Nevertheless, it is a step in right direction.
>> Introduction of format() already showed that C++ committee is aware of
>> of the fact that "Stroustrup streams" are crap not only relatively to
>> format/printing facilities of more modern languages, but relatively
>> to what we have in C as well. std::print() proves that committee is not
>> only aware of the fact, but finally willing to consider fixes.
> 
> Half of the slowness of both in C printf() and C++ streams comes from 
> the locale support, which is often unneeded and would just slow things 
> down. If I have understood correctly, std::print() does not use locale 
> by default, so has a chance to be much faster. If so, then definitely 
> this is a step in the right direction.
> 
> 

I have not tried std::format or std::print at all.

For my use, the old-style C++ iostreams are far too big - in small 
embedded systems, the amount of code pulled in to the link by even the 
simplest use is enormous.  (On many small systems, even standard 
"printf" is too bulky.)


If std::format and/or std::print can avoid such bulk, and be easily used 
with custom backends (typically I want the output sent to a serial 
port), it might be useful for me.

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

#121366

Paavo Helde <eesnimi@osa.pri.ee> writes:

[...]

> Half of the slowness of both in C printf() and C++ streams comes
> from the locale support, [...]

I find this assertion very hard to believe (specifically, for
printf();  I might guess that C++ streams have similar
performance characteristics, but I don't have nearly as much
experience with C++ streams as I do with printf()).

Is there anything else you can say about it besides an
unsupported assertion?

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web