Friday, September 25, 2020

Digest for comp.lang.c++@googlegroups.com - 20 updates in 5 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 18 06:33PM +0100

On 18/09/2020 18:15, Paavo Helde wrote:
> 18.09.2020 18:40 Mr Flibble kirjutas:
 
>> Neither (f)printf nor iostreams are suitable for formatted output if such formatting is to include localization support; C++20 fmt should fix this inadequacy.
 
> So far all my locale-related efforts have been directed to *avoiding* any locale-specific formatting. Surprisingly difficult at times...
 
It is an unavoidable fact that different languages have varying grammars resulting in words (nouns, verbs etc) appearing in different relative positions in sentences; this is why (f)printf and iostreams simply do not work; not everyone uses English.
 
/Flibble
 
--
¬
Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 08:15PM +0300

18.09.2020 18:40 Mr Flibble kirjutas:
 
> Neither (f)printf nor iostreams are suitable for formatted output if
> such formatting is to include localization support; C++20 fmt should fix
> this inadequacy.
 
So far all my locale-related efforts have been directed to *avoiding*
any locale-specific formatting. Surprisingly difficult at times...
Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 09:06PM +0300

18.09.2020 20:33 Mr Flibble kirjutas:
> resulting in words (nouns, verbs etc) appearing in different relative
> positions in sentences; this is why (f)printf and iostreams simply do
> not work; not everyone uses English.
 
I know that :-) Changing the locale to non-English should work like
Babel fish, but somehow it doesn't.
 
And even if it worked like Babel fish it should not be used when writing
data which will be read by some other software only, not by a human being.
 
Our software is aimed at PhD level and there have not been any requests
to translate it, even when sold in China. That's just fortunate because
doing a correct translation seems to be a mission impossible (or at
least many times more expensive than the original project) these days,
even if printf or iostreams are not involved. Recent advent of
translation AI seems to make things worse, not better.
scott@slp53.sl.home (Scott Lurndal): Sep 18 06:41PM


>>> Neither (f)printf nor iostreams are suitable for formatted output if such formatting is to include localization support; C++20 fmt should fix this inadequacy.
 
>> So far all my locale-related efforts have been directed to *avoiding* any locale-specific formatting. Surprisingly difficult at times...
 
>It is an unavoidable fact that different languages have varying grammars resulting in words (nouns, verbs etc) appearing in different relative positions in sentences; this is why (f)printf and iostreams simply do not work; not everyone uses English.
 
Which is why gettext[*], in combination with printf argument position flags (e.g. %2$u), is
so useful for i18n.
 
[*] and/or the often proprietary versions in other unix flavors.
Juha Nieminen <nospam@thanks.invalid>: Sep 18 07:45PM

> Isn't it that printf can be now implemented in type safe manner?
 
Not exactly printf, but a very printf-like function yes, indeed.
 
https://en.cppreference.com/w/cpp/utility/format
Ian Collins <ian-news@hotmail.com>: Sep 19 12:46PM +1200

On 19/09/2020 06:06, Paavo Helde wrote:
> least many times more expensive than the original project) these days,
> even if printf or iostreams are not involved. Recent advent of
> translation AI seems to make things worse, not better.
 
You are lucky there! Our users are machine operators and technicians,
so all the UIs have to be translated for each market - and the are a lot
of them...
 
Translation is an expensive and time consuming process which has delayed
our product releases on more than one occasion. My team is lucky, all
our UIs are handled by our Android and Web teams.
 
--
Ian.
Juha Nieminen <nospam@thanks.invalid>: Sep 19 07:35PM

> Well, I find it ironic that you bring up efficiency in the context of
> iostreams, which are for sure the most inefficient way to output
> something from a C++ program.
 
How old is the information on which that claim is based?
 
I myself compared the speed of std::fwrite() vs. std::ostream::write()
and noticed a quite clear difference in favor of the former... something
like 15 years ago.
 
In order to update my experience I recently tried to repeat the experiment,
but the results were extremely inconclusive because I was unable to get
consistent results. The times I got were all over the place, from run to
run of the exact same binary. (This could be due to a myriad of reasons,
perhaps related to the hardware, the operating system, or the C runtime.
But summa summarum, I couldn't get a definitive answer whether fwrite
is still measurably faster than ostream::write.)
Ian Collins <ian-news@hotmail.com>: Sep 20 08:17AM +1200

On 19/09/2020 23:18, Jorgen Grahn wrote:
 
> My end users have always fallen in the (broad) "technician" category,
> and I have never heard anyone even suggest the /possibility/ of
> localization.
 
"Technician" in our context are those who calibrate the machines for
customers and operators. This process can be quite complex and any
misunderstandings can have bad consequences...
 
> never been involved in anything with a GUI. Plenty of UI, but no GUI.
 
> Maybe localization isn't important to the customers, but their UX experts
> insist on it out of habit?
 
Not for us; I can't imagine many international construction machine
operators speaking good enough English to work with an English only UI.
It is probably intuitive enough to learn, but localisation is essential
in most markets - can you imagine selling an English only system in France?
 
--
Ian.
scott@slp53.sl.home (Scott Lurndal): Sep 20 02:46PM


>I myself compared the speed of std::fwrite() vs. std::ostream::write()
>and noticed a quite clear difference in favor of the former... something
>like 15 years ago.
 
Well Paavo didn't say "from a standard-compliant C++" program.
 
read/write/pread/pwrite are much faster than any of the stdio-based
I/O mechanisms. mmap is also much more efficient. For certain
applications direct access to the device (unix raw files, linux O_DIRECT)
are the most efficient ways to access data.
Paavo Helde <eesnimi@osa.pri.ee>: Sep 20 06:00PM +0300

19.09.2020 22:35 Juha Nieminen kirjutas:
> perhaps related to the hardware, the operating system, or the C runtime.
> But summa summarum, I couldn't get a definitive answer whether fwrite
> is still measurably faster than ostream::write.)
 
I see somehow we got carried away from formatted ouput (fprintf() and
stream <<) to unformatted output (fwrite and ostream::write).
Unformatted output is faster for sure and fwrite and ostream::write
speeds might indeed be comparable, especially if the buffer sizes are large.
 
My claims were about formatted stream <<. For some fun I created a
little test program for comparing formatted output of a custom class A
the "official" stream way, and with a ToString() method suitable for
printf-like interfaces. You should need to call it with stdout
redirected to >NUL or >/dev/null, to leave out any console or actual
disk writing overhead.
 
VC++ 2017, x64 release build:
 
> test.exe >NUL
temp std::string: 0.478026 s
std::ostream::operator<<() : 3.09337 s
 
So it appears ToString() is over 6x faster than <<, with VC++.
 
On the other hand, g++ seems to cope with this test much better and
there the stream << is faster:
 
Cygwin g++ 9.3, -std=c++17 -O2 :
 
> ./a.exe >/dev/null
temp std::string: 0.580246 s
std::ostream::operator<<() : 0.364451 s
 
So maybe you are right in that (some) compiler writers are catching up
and streams are not so slow any more as they used to be. But as VC++ is
one of my major targets I cannot count on it yet.
 
 
The test program itself:
 
 
#include <string>
#include <cstdio>
#include <chrono>
#include <iostream>
#include <algorithm>
#include <random>
 
const int n = 1000000;
 
class A {
std::string name;
std::uint32_t value;
friend std::ostream& operator<<(std::ostream& stream, const A& a);
static std::mt19937 gRnd;
public:
A(): name("A"+std::to_string(gRnd())), value(gRnd()) {}
 
std::string ToString() const {
return name + ": " + std::to_string(value);
}
};
 
std::ostream& operator<<(std::ostream& stream, const A& a) {
stream << a.name << ": " << a.value;
return stream;
}
 
std::mt19937 A::gRnd;
 
int main() {
std::vector<A> data(n);
 
auto start1 = std::chrono::steady_clock::now();
for (const A& ref: data) {
printf("%s\n", ref.ToString().c_str());
}
auto finish1 = std::chrono::steady_clock::now();
 
auto start2 = std::chrono::steady_clock::now();
for (const A& ref: data) {
std::cout << ref << "\n";
}
auto finish2 = std::chrono::steady_clock::now();
 
fprintf(stderr, "temp std::string: %g s\n",
std::chrono::duration<double>(finish1-start1).count());
fprintf(stderr, "std::ostream::operator<<() : %g s\n",
std::chrono::duration<double>(finish2-start2).count());
}
Paavo Helde <eesnimi@osa.pri.ee>: Sep 21 08:27AM +0300

20.09.2020 20:59 Jorgen Grahn kirjutas:
> performance, but I could see from 'strace -c' that the std::cout code
> path changed: in terms of system calls it used writev(2) instead of
> write(2), and it wrote twice as much at each call.
 
FWIW, I tried to call sync_with_stdio(false) as well, but it did not
make any significant difference with VC++ either.
 
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 25 08:29PM +0100

> operators, not for `<<`.
 
> All assignment operators (including compound assignment) became very
> tightly sequenced in C++17.
 
Ah, right. I missed that change (and I thought this was a follow on
from the << discussion so I didn't check). My mistake.
 
FWIW, g++ 9.3.0-17ubuntu1~20.04 produces 0x1111.
 
--
Ben.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 20 11:22AM +0200

Am 15.09.20 um 08:55 schrieb Öö Tiib:
> Interesting trick, jumping to address of called function and letting
> it to return for you.
 
TCO (Tail Call Optimization) is probably as old as the assembler languages.
 
Definitely slow on modern hardware are indirect calls (or jumps) with a
calculated target. They usually result in pipeline stalls because they
are difficult to predict in hardware.
 
Conditional memory access is usually the fastest for min/max if
available on the target hardware.
 
 
Marcel
jacobnavia <jacob@jacob.remcomp.fr>: Sep 20 03:54PM +0200

Le 14/09/2020 à 17:35, Scott Lurndal a écrit :
 
> Given the intel/amd 'CMOVxx' instruction and the ARM "CSET" instruction,
> the compilers will generate the most optimal branchless code for a max
> check even without optimization.
 
In the arm target gcc will generate this code without optimization:
 
18 str x0, [sp, 8]
19 str x1, [sp]
20 ldr x0, [sp, 8]
21 ldr w1, [x0]
22 ldr x0, [sp]
23 ldr w0, [x0]
24 cmp w1, w0
25 bge .L2
26 ldr x0, [sp]
27 b .L3
28 .L2:
29 ldr x0, [sp, 8]
30 .L3:
 
Yes, it generates branches. your assertion above is falsified
Ian Collins <ian-news@hotmail.com>: Sep 20 02:57PM +1200

On 20/09/2020 14:32, Brian Wood wrote:
 
> So far there's not much interest in this and I'm
> thinking about joining Ben Shapiro and Dailywire in
> Nashville:
 
I've never heard of him, is he a C++ writer?
 
--
Ian.
Ian Collins <ian-news@hotmail.com>: Sep 20 04:42PM +1200

On 20/09/2020 16:01, Brian Wood wrote:
>> I've never heard of him, is he a C++ writer?
 
> He's a conservative journalist. He's a modern-day
> MLK Jr. in my opinion.
 
Ah, more crackpot US politics. Irrelevant to the sane world, move along...
 
--
Ian
Juha Nieminen <nospam@thanks.invalid>: Sep 18 01:42PM

> I'm interested in the 'halt deciders programs'. Suppose two TM's, one
> is computing and printing 1/3=0.333... another is pi=3.1415...
> Will the decoder halt? So I can investigate the reason?
 
Usually when talking about the halting program, the problem is if there's
a way to tell from a given program whether it will ever terminate or not.
I suppose the same can be applied to merely an algorithm description or
task description.
 
If the task is: "Compute and print all the decimals of 1/3", then it's
rather obvious that it will not halt. If the program has been implemented
correctly, it will never halt.
 
The problem is whether it's possible to create a program or algorithm
that tells you from any given other program whether it will eventually
halt or continue forever.
 
And this has nothing to do with debugging.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 17 05:11PM +0100


> What I was thinking with my original question is the syntax to pass,
> for example, a pointer to a two-dimensional array as a parameter to
> a function.
 
That's what you call it, but I would refer to passing a pointer to an
element of such an array (when I remember to be careful). Being 2D,
that element is itself an array, but that does not alter the term I'd
use. Without context, your terminology is open to misinterpretation.
 
> Typically if you just want to give a pointer to an array to a function,
> the function would declared for example like:
 
> void foo(int* values, size_t valuesAmount);
 
We may, casually, say that's a pointer to an array, but it isn't really.
It's a pointer to an int which may be located somewhere in an array, but
it need no be.
 
> first place. Many of the ones who know that it's theoretically possible
> don't know or remember the exact syntax. The syntax is, of course:
 
> void foo(int (*values)[100], size_t valuesAmount);
 
It's directly analogous to the syntax for function pointers, so I don't
find it hard to remember. C declarators (the bit of the type with the
stars and the []s and so on) use a little expression syntax. You
sometimes need parentheses to alter the binding:
 
*x[...] :: array of pointer
(*x)[...] :: pointer to array
*x(...) :: function returning pointer
(*x)(...) :: pointer to function.
 
Top tip: a cast operator is just a single declaration with the name
missing and the put in parentheses. So if you need the cast operator to
convert to a pointer to an array of 10 ints, it's just
 
(int (*)[10]) ...
 
--
Ben.
Juha Nieminen <nospam@thanks.invalid>: Sep 17 06:27PM

> missing and the put in parentheses. So if you need the cast operator to
> convert to a pointer to an array of 10 ints, it's just
 
> (int (*)[10]) ...
 
Another pro tip, which helps understand the sometimes weird-appearing
behavior of the 'typedef' keyword: To make a type alias, just write
the type definition exactly is you were defining a variable of that
type, and slap the keyword 'typedef' in front of it: Now instead of
the name you wrote being the name of a variable, it's the name of
the type alias.
 
That simple idea helps clearing up a lot of confusion about how
'typedef' works.
 
So, the simplest example is of course:
 
int anInteger; // variable definition
typedef int AnInteger; // type definition
 
Doesn't look like much of a tip with that example. However, the ingeniousness
of the tip becomes clearer when you consider how to declare type aliases
for more complicated cases. For instance, how to declare a type alias that
means "a pointer to a function taking an int and returning an int"?
Well, first thing how you would define a *variable* of that type:
 
int (*funcPtr)(int);
 
Now just slap 'typedef' in front of it, and you're done:
 
typedef int (*FuncPtr)(int);
 
Now 'FuncPtr' is a type alias for a function pointer of that type.
This explains the sometimes obscure-looking typedef syntax.
Bart <bc@freeuk.com>: Sep 17 09:49PM +0100

On 17/09/2020 19:27, Juha Nieminen wrote:
 
> int (*funcPtr)(int);
 
> Now just slap 'typedef' in front of it, and you're done:
 
> typedef int (*FuncPtr)(int);
 
It doesn't need to be in front:
 
int typedef (*FuncPtr)(int);
 
will work too. The typedef can go anywhere before any "*" or variable
name or "(".
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)