Wednesday, September 22, 2021

Digest for comp.lang.c++@googlegroups.com - 11 updates in 3 topics

HorseyWorsey@the_stables.com: Sep 22 03:15PM

On Wed, 22 Sep 2021 16:16:57 +0200
>https://en.cppreference.com/w/cpp/utility/to_chars>.
 
>I gave a more or less full example in reply to the same posting you
>replied to.
 
Because a 20 line user function just to convert a number into a string is
soooo efficient.
 
But then someone who writes "auto main() -> int" instead of "int main()"
and then forgets the return value at the end anyway is probably not someone
who writes sensible code.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 22 05:57PM +0200


> But then someone who writes "auto main() -> int" instead of "int main()"
> and then forgets the return value at the end anyway is probably not someone
> who writes sensible code.
 
Attempt to troll someone else, please.
 
- Alf
HorseyWorsey@the_stables.com: Sep 22 04:05PM

On Wed, 22 Sep 2021 17:57:46 +0200
>> and then forgets the return value at the end anyway is probably not someone
>> who writes sensible code.
 
>Attempt to troll someone else, please.
 
Your example was a joke. Thats not trolling, thats a fact.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 22 08:46PM +0300

22.09.2021 17:16 Alf P. Steinbach kirjutas:
> https://en.cppreference.com/w/cpp/utility/to_chars>.
 
> I gave a more or less full example in reply to the same posting you
> replied to.
 
Yes, I saw your post later. You are right to_chars() ought to be faster
indeed. Unfortunately I have not had a chance yet to try it out.
 
Locale and speed issues are most severe for floating-point. At the
moment we are using Google's double-conversion library for
double->string conversion, this seems to be pretty fast as well.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 22 02:13PM -0700

HorseyWorsey@the_stables.com writes:
[...]
> But then someone who writes "auto main() -> int" instead of "int main()"
> and then forgets the return value at the end anyway is probably not someone
> who writes sensible code.
 
Were you not aware that reaching the closing "}" of main() does an
implicit "return 0;"?
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
"daniel...@gmail.com" <danielaparker@gmail.com>: Sep 22 02:42PM -0700

On Wednesday, September 22, 2021 at 8:18:27 AM UTC-4, Paavo Helde wrote:
 
> > So what would be the shiny new alternative in C++?
> std::to_string()
 
> https://en.cppreference.com/w/cpp/string/basic_string/to_string
 
Strange that in a language that's supposed to support genericity and
user provided allocators, we have these things that support neither
genericity or user provided allocators.
 
Daniel
Manfred <noname@add.invalid>: Sep 22 11:45PM +0200

On 9/20/2021 6:08 PM, David Brown wrote:
> On 20/09/2021 17:11, Bart wrote:
<snip>
>> without wasting too much compiler time on it.
 
> That's your view. It is not unique to you, but it is not the view of
> many other people.
 
Actually this view was (and still is) shared by the creators of C and of
C++.
In fact, that is the only reason (every language should have it as an
unavoidable axiom) that I can see for C to have a function like printf:
as a systems language, you don't need formatting support, you just need
the ability to send chars to some device.
But, since it is such a widely spread convenience, they decided to put
something in the standard library.
C++ tried to improve with iostreams, it was a genuine attempt, but the
result proved unpleasant.
 
(In other words, string formatting is properly a UI feature, so if you
seriously need it, get some serious UI library, which has intentionally
been left out of C and C++; or, if you have specific and limited needs,
write it yourself)
 
The key point is the word "basic" in Bart's sentence - it is the same as
"easy to use", what does it mean?
Definitions like this are obviously subjective, and they're a sure path
to disagreement.
 
I remember once some team was working on building support for some type
of device into some system - integration would consist of controlling
the device from C code, the system's language.
The team was asked by management about the requirements for the device;
the requirements came out along the lines of "it should be easy to use".
The result was that management bought a device that could be driven by
Excel.
David Brown <david.brown@hesbynett.no>: Sep 22 11:51PM +0200

On 22/09/2021 23:45, Manfred wrote:
>> many other people.
 
> Actually this view was (and still is) shared by the creators of C and of
> C++.
 
It is not part of the core language. It is part of the standard
library. That's a very different thing. In particular, the great
majority of printf implementations are written in C, the great majority
of iostream implementations are written in C++.
(Implementation-specific behaviour might be needed.) Printing is not a
special statement in either language - it is handled by library
functions that are optional (small embedded systems often don't use
them, for example), and can be replaced by alternatives.
Bart <bc@freeuk.com>: Sep 23 12:17AM +0100

On 22/09/2021 22:45, Manfred wrote:
> "easy to use", what does it mean?
> Definitions like this are obviously subjective, and they're a sure path
> to disagreement.
 
The first languages I used all had a version of PRINT, needed as the
primary display device was a teletype or VDU, but you also needed to
write to text files (Algol, Fortran, Pascal; even assembly could do it!)
 
So I find it difficult to get away from the idea that PRINT is anything
but a fundamental feature of a language. Even though applications may
work primarily with a GUI, or without a UI at all. Such an app may still
need to write out a config file ...
 
... or read one in. Which brings me to something that hasn't been
discussed: basic READ.
 
This was something that was so easy in the 1970s, and now so hard;
except in my own languages where I keep it simple:
 
int a, b, c
print "Prompt> "
readln a, b, c
println a, b, c
 
I tried it in C++ to see how well it coped:
 
#include <iostream>
 
int main()
{ int a,b,c;
std::cout << "Prompt> ";
std::cin >> a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
}
 
(Just look at that last line; 15 tokens and 35 sig. characters; compare
my 6 tokens and 12 characters...)
 
Anyway, this was quite poor:
 
* It doesn't like commas as separators as well as spaces
 
* If less than 3 numbers are present, it keeps waiting for me to enter
them on a subsequent line; very unfriendly
 
* If more than 3 are entered, those extra ones are not ignored; on the
next Prompt, those ones form the first part of the input of the new
line, very confusing. This input is supposed to be LINE ORIENTED.
 
* If I enter 12.34 56 78, it reads 12 for the first number, and zeros
for the next two, and apparently zeros also for all subsequent lines
 
 
None of those problems appear in mine:
 
* It reads at most 3 numbers from the line
 
* If fewer are present, it'll read them as zeros
 
* If more, they are ignored. Whatever is entered on one line NEVER
impinges on the next
 
* Numbers can be separated with commas or spaces
 
* Entering 12.34 56 78 is well behaved; it reads 12 56 78
 
There are some weaknesses in my static language version, but most are
fixed in my dynamic version (same code, but no 'int a,b,c'):
 
* A print item is read as int, float, string or bignum according to what
is entered
 
* Missing items are read as ""
 
* A type can be forced if needed
 
READ is intended as a casual feature to quickly and informally read such
input from a console or file. But it's amazing how accomplished it is
compared with major languages.
 
I'm sure C++ is also capable of the same things, but how much effort is
it? Do you have to do everything yourself? Maybe there's a Boost library
to do what used to be one line of code with Algol60.
 
My first programs were student exercises. Then, getting the 3 numbers
the task demanded was the easy bit!
Sam <sam@email-scan.com>: Sep 22 06:43PM -0400


> Coroutines should have stayed in the microsoft world, not added to the C++
> standard. They're a solution looking for a problem.
 
I was about to make this exact comment. You saved me the trouble of doing
that.
 
Microsoft hijacked the standardization process in order to get co-routines
into C++. std::threads' poor performance on MS-Windows has been documented,
due to underlying OS design and/or limitations. This was MS's way of
attempting to implement an alternative fake-multithreading that doesn't suck
on their platform.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 22 12:37PM -0700

On 9/21/2021 4:08 PM, Chris M. Thomasson wrote:
 
>>> Creating a working condvar can be very tricky. Have you
>>> tried to run  your implementation through a race detector? ...
 
>> Can you read ? I haven't built a condvar but a monitor-object.
 
Also, can you read the subject of this thread: "condvar-implementation" ?
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)