cout slower than printf

[Mr Flibble]

Why are implementers of C++ stdlibs such lazy fuckers? Just noticed that
libstdc++ creates a separate temporary sprintf format string for EACH
number you want to output and then uses that string in an internal call
to sprintf (or its equivalent) for each number.

Yes code-reuse is good in general but here using the C stdlib in a C++
LIBRARY implementation resulting in poor performance is just not on.

This isn't a problem with C++ iostreams per se it is a problem with the
quality of their implementation. C++ iostreams could easily outperform
the C alternatives if a bit of effort was put in to leverage argument types.

/Flibble

[Alf P. Steinbach]

On 23.04.2016 01:22, Mr Flibble wrote:
> <snip> C++ iostreams could easily outperform

> the C alternatives if a bit of effort was put in to leverage argument
> types.

Both Dietmar Kuehl and Andrei Alexandrescu did work on that. I think
some of Dietmar's work is still available, and anyway, as I recall, it
influenced Dinkumware's implementation, used by Visual C++. Andrei's
fabled implementation had a striking acronym, that I don't recall, but I
think nobody ever saw any of it, only Andrei's occasional hints.

Cheers!,

- Alf

[Marcel Mueller]

On 23.04.16 01.22, Mr Flibble wrote:
> Why are implementers of C++ stdlibs such lazy fuckers? Just noticed that
> libstdc++ creates a separate temporary sprintf format string for EACH
> number you want to output and then uses that string in an internal call
> to sprintf (or its equivalent) for each number.

Well, it's up to the implementation.

> This isn't a problem with C++ iostreams per se it is a problem with the
> quality of their implementation.

Indeed. But it is one reason why I do almost never use iostreams.

> C++ iostreams could easily outperform
> the C alternatives if a bit of effort was put in to leverage argument
> types.

Obviously no one did the job for the last 20 years. And since the syntax
of the iostreams is that crazy (operator overloading just because it can
be done, stateful formatting) I'd rather implement my own I/O classes
than use iostreams. BTDT.

One of the first things when coding a new C++ application is a xprintf
function which returns std::string or whatever string class the
application prefers. *printf is still part of the C++ standard, so why
not to use it, unless something better exists? Modern compilers do type
checking with reasonable warnings for printf like functions.


Marcel

[Mr Flibble]

On 24/04/2016 20:34, Marcel Mueller wrote:

> One of the first things when coding a new C++ application is a xprintf
> function which returns std::string or whatever string class the
> application prefers. *printf is still part of the C++ standard, so why
> not to use it, unless something better exists? Modern compilers do type
> checking with reasonable warnings for printf like functions.

Why not use old inferior language features you ask? The same question
could be why use 'new' when you could use 'malloc'? Why use classes
when you can not use classes? Apparently you are unaware of the concept
of progress.

/Flibble

[Paavo Helde]

How do you define "progress"? Not every change is progress. Or
alternatively, not all kind of progress is good. I could draw examples
from former USSR and current North Korea, but to stay on topic I just
mention export templates and exception specifications.

When something like Boost.Format or C++ Format Library gets
standardized, printf() will become obsolete indeed. But not before.

Cheers
Paavo

[Marcel Mueller]

On 24.04.16 22.58, Mr Flibble wrote:
> On 24/04/2016 20:34, Marcel Mueller wrote:
>
>> One of the first things when coding a new C++ application is a xprintf
>> function which returns std::string or whatever string class the
>> application prefers. *printf is still part of the C++ standard, so why
>> not to use it, unless something better exists? Modern compilers do type
>> checking with reasonable warnings for printf like functions.
>
> Why not use old inferior language features you ask? The same question
> could be why use 'new' when you could use 'malloc'? Why use classes
> when you can not use classes?

Well, all of the features you mentioned have significant advantages.

> Apparently you are unaware of the concept
> of progress.

Progress for its own sake in this case. IMO iostreams are no progress
but just a proof of concept for the rather new language (at that time),
far away from pretty good concepts like STL that are born later. They
should be marked obsolete and replaced by something better. And awaiting
a better solution I am stuck with printf so far.
I have never seen any language with a comparable bad concept of string
formatting in my life. OK, if you include assembler languages iostreams
are not that bad. But even a PDP11/24 with a macro assembler is quite
usable.

Don't misunderstand. I like C++. Actually I prefer it - except for
iostreams.


Marcel

[Mr Flibble]

You can use Boost.Format NOW rather than waiting for it to be
standardized so there is no reason to use printf NOW.

/Flibble

[Mr Flibble]

On 24/04/2016 23:40, Marcel Mueller wrote:
> [snip] And awaiting

> a better solution I am stuck with printf so far.

Boost.Format mate.

/Flibble

[Marcel Mueller]

Unfortunately Boost is not supported on some of my platforms.


Marcel

[Jerry Stuckle]

So how do you output a class, i.e.

class MyClass {...};

MyClass my;
cout << my;

Can you do this with printf()?

Or how to you output to stdout, a file, or a string, in one method?

Have you looked at manipulators for formatting?

Speed is not the only factor involved - in fact, when it comes to I/O,
it is generally the LEAST important factor. Physical I/O will take much
more time than the function being called.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Jerry Stuckle]

That's not iostream's fault...

[Daniel]

On Sunday, April 24, 2016 at 10:15:22 PM UTC-4, Jerry Stuckle wrote:
> On 4/24/2016 6:40 PM, Marcel Mueller wrote:
>
> So how do you output a class, i.e.
>
> class MyClass {...};
>
> MyClass my;
> cout << my;

>
> Can you do this with printf()?
>

Of course. It's just as easy to implement a to_string function as it is <<

> Or how to you output to stdout, a file, or a string, in one method?

fprintf covers stdout, to_string covers string

> Have you looked at manipulators for formatting?

manipulators were never a good idea, too inflexible. For example, a common
output format of a double is show decimal point, minimally one trailing
zero after the decimal point, and no more than one trailing zero. That
can't even be expressed with the built in C++ manipulators. The right way
to handle formatting is with format strings, there's a lot of prior art
behind that, from COBOL on.

The C++ streams do have one advantage over the C functions in that they can
be associated with local versions of locales, that's a defect with the
printf, put, et all function signatures.

> Speed is not the only factor involved - in fact, when it comes to I/O,
> it is generally the LEAST important factor. Physical I/O will take much
> more time than the function being called.
>

In open source projects involving text serialization, where benchmarks are
published and affect how many users a project gets, people do anything to
avoid using C++ streams, or go to herculean efforts to get around the
inefficiencies of streams. They shouldn't have to do that.

Daniel

[Jerry Stuckle]

On 4/24/2016 11:21 PM, Daniel wrote:
> On Sunday, April 24, 2016 at 10:15:22 PM UTC-4, Jerry Stuckle wrote:
>> On 4/24/2016 6:40 PM, Marcel Mueller wrote:
>>
>> So how do you output a class, i.e.
>>
>> class MyClass {...};
>>
>> MyClass my;
>> cout << my;
>
>>
>> Can you do this with printf()?
>>
>
> Of course. It's just as easy to implement a to_string function as it is <<
>

Which means you can't use to_string for any different formatting.

>> Or how to you output to stdout, a file, or a string, in one method?
>
> fprintf covers stdout, to_string covers string
>

Which means you can't use to_string for any different formatting.

>> Have you looked at manipulators for formatting?
>
> manipulators were never a good idea, too inflexible. For example, a common
> output format of a double is show decimal point, minimally one trailing
> zero after the decimal point, and no more than one trailing zero. That
> can't even be expressed with the built in C++ manipulators. The right way
> to handle formatting is with format strings, there's a lot of prior art
> behind that, from COBOL on.
>

Yes, COBOL has another way to do it. But whether YOU think they are a
good idea or not, millions of programmers have been using them for over
a quarter century, with good results.

> The C++ streams do have one advantage over the C functions in that they can
> be associated with local versions of locales, that's a defect with the
> printf, put, et all function signatures.
>

Yes, that is one advantage. Another is their ability to use
manipulators to control formatting of the data. And, of course, you
don't need to tie up to_string just for I/O. And BTW - to_string
doesn't work well on input.

>> Speed is not the only factor involved - in fact, when it comes to I/O,
>> it is generally the LEAST important factor. Physical I/O will take much
>> more time than the function being called.
>>
> In open source projects involving text serialization, where benchmarks are
> published and affect how many users a project gets, people do anything to
> avoid using C++ streams, or go to herculean efforts to get around the
> inefficiencies of streams. They shouldn't have to do that.
>
> Daniel
>

Text serialization is not the only use for input/output. In fact, very
little of my C++ I/O work includes text serialization. Much more of it
has had to do with object serialization.

[Juha Nieminen]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> *printf is still part of the C++ standard, so why
> not to use it, unless something better exists? Modern compilers do type
> checking with reasonable warnings for printf like functions.

Use it if it suits the situation. But sometimes it doesn't. That's because
printf is not generic. If you have a generic type (eg. a template type, or
just a typedeffed name) you have no way of knowing what its format string
has to be. The printf family is unsuitable in this situation.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Juha Nieminen]

Daniel <daniel...@gmail.com> wrote:
> Of course. It's just as easy to implement a to_string function as it is <<

Perhaps the day that C++ supports introspection, but until then, it doesn't
work.

template<typename T>
void foo(const T& value)
{
std::cout << value;
}

Good luck determining there whether you need to call a to_string() method
of the parameter or not.

[jacobnavia]

Le 24/04/2016 22:58, Mr Flibble a écrit :
> Why not use old inferior language features you ask?

Of course. Using C, that old "inferior" language is faster... but that
is not so important of course.

> The same question
> could be why use 'new' when you could use 'malloc'?

Exactly.

> Why use classes
> when you can not use classes?

Exactly. Why everything must fit into a class hierarchy?

> Apparently you are unaware of the concept
> of progress.

Progress, as defined by some C++ heads, means complexifying everything
till simple things like printing a number becomes slow and utterly
complicated.

[Christian Gollwitzer]

Am 25.04.16 um 04:15 schrieb Jerry Stuckle:

> On 4/24/2016 6:40 PM, Marcel Mueller wrote:
>> Don't misunderstand. I like C++. Actually I prefer it - except for
>> iostreams.
>

> So how do you output a class, i.e.
>
> class MyClass {...};
>
> MyClass my;
> cout << my;
>
> Can you do this with printf()?

Write a virtual print/serialize function in your class. You rarely need
to "just print" it. Maybe even printf("%s", my.repr()) can be an easy
solution.

> Or how to you output to stdout, a file, or a string, in one method?

stdout and file works with fprintf. string is different, but you can
always print to a string first and then output to the target. The real
problem with sprintf is that you need to have the (limited) buffer first.

> Have you looked at manipulators for formatting?

How do you do i18n with iostreams? printf has positonal parameters, so
that you can change "This apple costs 18 dollars" into "18 dollars for
this apple" by the translator. I don't see a solution with iostreams.

> Speed is not the only factor involved - in fact, when it comes to I/O,
> it is generally the LEAST important factor. Physical I/O will take much
> more time than the function being called.

Often, yes. But iostreams are really slow. Try writing a large file and
you'll see.

Christian

[Ian Collins]

On 04/25/16 18:54, Christian Gollwitzer wrote:
>
> Often, yes. But iostreams are really slow. Try writing a large file and
> you'll see.

I really don't know why people keep bringing up this old chestnut:
unformatted iostream output is no slower and can be faster than stdio.
With iostreams we have full control of the underlying streambuf and
therefore any buffering.

You won't hear any arguments from me if you claim formatted output is
cumbersome, but unformatted is a different kettle of fish.

--
Ian Collins

[Daniel]

On Monday, April 25, 2016 at 2:15:09 AM UTC-4, Juha Nieminen wrote:

> Daniel wrote:
> > Of course. It's just as easy to implement a to_string function as it is <<
>
> Perhaps the day that C++ supports introspection, but until then, it doesn't
> work.
>

In C++, both to_string and the stream insertion operator<< require custom
implementations for MyClass. I think you know that, so I'm not quite
sure what your point is.

Daniel

[Jerry Stuckle]

On 4/25/2016 2:54 AM, Christian Gollwitzer wrote:
> Am 25.04.16 um 04:15 schrieb Jerry Stuckle:
>> On 4/24/2016 6:40 PM, Marcel Mueller wrote:
>>> Don't misunderstand. I like C++. Actually I prefer it - except for
>>> iostreams.
>>
>> So how do you output a class, i.e.
>>
>> class MyClass {...};
>>
>> MyClass my;
>> cout << my;
>>
>> Can you do this with printf()?
>
> Write a virtual print/serialize function in your class. You rarely need
> to "just print" it. Maybe even printf("%s", my.repr()) can be an easy
> solution.
>

Or, just use an iostream.

>> Or how to you output to stdout, a file, or a string, in one method?
>
> stdout and file works with fprintf. string is different, but you can
> always print to a string first and then output to the target. The real
> problem with sprintf is that you need to have the (limited) buffer first.
>

Exactly- the string is different. No buts.

>> Have you looked at manipulators for formatting?
>
> How do you do i18n with iostreams? printf has positonal parameters, so
> that you can change "This apple costs 18 dollars" into "18 dollars for
> this apple" by the translator. I don't see a solution with iostreams.
>

I don't see a solution for to_string.

>> Speed is not the only factor involved - in fact, when it comes to I/O,
>> it is generally the LEAST important factor. Physical I/O will take much
>> more time than the function being called.
>
> Often, yes. But iostreams are really slow. Try writing a large file and
> you'll see.
>
> Christian
>

I've written huge files over the years. No, iostreams are not as fast.
But the biggest delay has not been in the software.

[Jerry Stuckle]

Why even use a HLL at all? Just write everything in assembler (or
machine language).

[Daniel]

On Sunday, April 24, 2016 at 11:35:47 PM UTC-4, Jerry Stuckle wrote:
>
> Which means you can't use to_string for any different formatting.

True. Do you use manipulators for that, I mean for formatting a complex
object? I tend to use to_json, to_xml, pretty_print(thing, format_options),
etc.

> > manipulators were never a good idea, too inflexible.

> Yes, COBOL has another way to do it. But whether YOU think they are a
> good idea or not, millions of programmers have been using them for over
> a quarter century, with good results.

For some definition of "good results". But if you want to format a double to
show the decimal point and one and only one trailing zero, you can't do it
with the built-in manipulators, you have to strip the rest of the trailing
zeros yourself. Also, since the manipulators are expressed in code, you
can't easily put a format mask into configuration storage, which is something we frequently want to do.

In computer languages, C++ style manipulators are an evolutionary dead end,
no newer language outside the family has picked them up, nor will ever be
likely to.

I agree with Marcel Mueller, C++ needs better abstractions for input and
output.

Daniel

[Christian Gollwitzer]

Am 25.04.16 um 14:27 schrieb Jerry Stuckle:

> On 4/25/2016 2:54 AM, Christian Gollwitzer wrote:
>> How do you do i18n with iostreams? printf has positonal parameters, so
>> that you can change "This apple costs 18 dollars" into "18 dollars for
>> this apple" by the translator. I don't see a solution with iostreams.
>>
>
> I don't see a solution for to_string.

to_string is not needed. printf does it:

printf("This %1$s costs %2$s %3$d\n", "computer", "$", 18);
=> This computer costs $ 18

The printf string will then be read from a file and translated e.g. into
German, using different word order:

printf("%3$d %2$s für den %1$s bitte\n", "computer", "$", 18);
=> 18 $ für den computer bitte
(yes, "computer" should be uppercase, but still...)

In reality, the printf string is read from a config file (GNU gettext
does this. A similar example at
https://www.gnu.org/software/gettext/manual/html_node/c_002dformat-Flag.html
). This is not a theoretical use case, it happens every day many times
when I use the localized computer. But iostreams don't provide any
solution here. I'm not saying it's perfect, but here printf (or, more
likely, sprintf() in a GUI program), is the clear winner. There are
still problems, e.g. printf strings reading past the end of the
arguments, which might pose a security risk.

Serializing complex objects using iostreams seems an academic case to
me, but it might simply not have occured to me yet.

Christian

[Cholo Lennon]

I like Boost.Format, I use it in production code, but it is slower than
iostreams :-(


--
Cholo Lennon
Bs.As.
ARG

[Jerry Stuckle]

On 4/25/2016 8:39 AM, Daniel wrote:
> On Sunday, April 24, 2016 at 11:35:47 PM UTC-4, Jerry Stuckle wrote:
>>
>> Which means you can't use to_string for any different formatting.
>
> True. Do you use manipulators for that, I mean for formatting a complex
> object? I tend to use to_json, to_xml, pretty_print(thing, format_options),
> etc.
>

Definitely. It works quite well.

But also, there are many times I don't necessarily want the data in a
human-readable format. It might go into a file, for instance.

I can see why you think iostreams are so slow, though. I would never
use to_json, to_xml, etc. to write data unless it had to be in a format
compatible with many applications across a network or something similar.
That's what these formats were made for.

>>> manipulators were never a good idea, too inflexible.
>
>> Yes, COBOL has another way to do it. But whether YOU think they are a
>> good idea or not, millions of programmers have been using them for over
>> a quarter century, with good results.
>
> For some definition of "good results". But if you want to format a double to
> show the decimal point and one and only one trailing zero, you can't do it
> with the built-in manipulators, you have to strip the rest of the trailing
> zeros yourself. Also, since the manipulators are expressed in code, you
> can't easily put a format mask into configuration storage, which is something we frequently want to do.
>

Good enough tat millions of programmers around the world have been happy
with them. But as for the format mask - you're still thinking
procedural code, not object oriented.

> In computer languages, C++ style manipulators are an evolutionary dead end,
> no newer language outside the family has picked them up, nor will ever be
> likely to.
>

Possibly, but not for decades. Too many programs are using them for
them to be removed from the standards.

> I agree with Marcel Mueller, C++ needs better abstractions for input and
> output.
>
> Daniel
>

No language will ever be perfect for everyone. What's important is if
it meets the needs of a major majority of the users.

[Jerry Stuckle]

Sure, printf can do it. But you're still thinking in procedural terms,
not object oriented. The object can easily do such things in C++.

And printf is not object aware - you cannot, for instance, say

printf("%some user-defined formatting string\n", myObject);

You can say

cout << myObject <<\n;

And cout can be replaced with any ostream-derived object with no other
change.

[Mr Flibble]

On 25/04/2016 13:39, Daniel wrote:
> On Sunday, April 24, 2016 at 11:35:47 PM UTC-4, Jerry Stuckle wrote:
>>
>> Which means you can't use to_string for any different formatting.
>
> True. Do you use manipulators for that, I mean for formatting a complex
> object? I tend to use to_json, to_xml, pretty_print(thing, format_options),
> etc.
>
>>> manipulators were never a good idea, too inflexible.
>
>> Yes, COBOL has another way to do it. But whether YOU think they are a
>> good idea or not, millions of programmers have been using them for over
>> a quarter century, with good results.
>
> For some definition of "good results". But if you want to format a double to
> show the decimal point and one and only one trailing zero, you can't do it
> with the built-in manipulators, you have to strip the rest of the trailing
> zeros yourself. Also, since the manipulators are expressed in code, you
> can't easily put a format mask into configuration storage, which is something we frequently want to do.

Nonsense, trailing zeros are quite easy to achieve; the following
program outputs 1.0000:

#include <iostream>
#include <iomanip>

int main()
{
std::cout << std::fixed << std::setprecision(4) << 1.0 << "\n";
}

/Flibble

[Daniel]

On Monday, April 25, 2016 at 11:41:09 AM UTC-4, Jerry Stuckle wrote:
>
> I can see why you think iostreams are so slow, though.

Always nice to see that ah hah moment in our friends and acquaintances on
usenet.

> I would never
> use to_json, to_xml, etc. to write data unless it had to be in a format
> compatible with many applications across a network or something similar.
> That's what these formats were made for.

Using my own modest attempt at a json library for parsing and
serialization (published as open source), on my Dell Precision notebook,
it takes a little under 10 seconds to read a gigabyte of json text, and a
little under 2 seconds to write it, with insertion to an ostream and
extraction from an istream. Those numbers require some optimizations within
the library when reading and writing to the stream, without them, using
stream io simplistically, read would be about 5 times slower, and write 4
times slower (there are other open source json libraries that are faster,
but they have their own issues.)

Generally, I find these times acceptable for reading and writing a gigabyte
of text, and usually the amount of data I work with is somewhat smaller.
Typically, if I push a button on a python app which sends a json request to
C++ server to simulate some data and transfer it back as json over a socket,
the resulting 3D plot in the python app appears close to instantaneous. So
in most cases, I'm not particularly motivated to transfer anything except
text, given text's other advantages. In those other cases, I use Google
protocol buffers.

>
> >>> manipulators were never a good idea, too inflexible.
>

> Good enough tat millions of programmers around the world have been happy
> with them.

But perhaps not very, very happy. A little Google search will show you much
wailing and gnashing of teeth, many hacks and workarounds, and not a few
alternative toolkits for formatting.

> But as for the format mask - you're still thinking
> procedural code, not object oriented.

You weren't one of those who subscribed to JOOP, were you :-)

In any case, the substance of OO, abstract interfaces, is silent about
whether I want to keep the format of a number, date, currency, phone number
etc. as a string representation in a data store, where my users can
configure it without having to recompile a computer application.

Best regards,
Daniel

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/25/2016 10:15 AM, Christian Gollwitzer wrote:
>> Am 25.04.16 um 14:27 schrieb Jerry Stuckle:
>>> On 4/25/2016 2:54 AM, Christian Gollwitzer wrote:
>>>> How do you do i18n with iostreams? printf has positonal parameters, so
>>>> that you can change "This apple costs 18 dollars" into "18 dollars for
>>>> this apple" by the translator. I don't see a solution with iostreams.
>>>>
>>>
>>> I don't see a solution for to_string.
>>
>> to_string is not needed. printf does it:
>>
>> printf("This %1$s costs %2$s %3$d\n", "computer", "$", 18);
>> => This computer costs $ 18
>>
>> The printf string will then be read from a file and translated e.g. into
>> German, using different word order:
>>
>> printf("%3$d %2$s für den %1$s bitte\n", "computer", "$", 18);
>> => 18 $ für den computer bitte
>> (yes, "computer" should be uppercase, but still...)
>>

>

>Sure, printf can do it. But you're still thinking in procedural terms,
>not object oriented. The object can easily do such things in C++.
>
>And printf is not object aware - you cannot, for instance, say
>
>printf("%some user-defined formatting string\n", myObject);
>
>You can say
>
>cout << myObject <<\n;
>
>And cout can be replaced with any ostream-derived object with no other
>change.

As I must have an overloaded operator << in any class
to leverage your object formatting, I could as easily have
written a "dump" method in the class that outputs to a supplied
ostream or a "format" method that produces a std:string which
can be supplied to snprintf.

I would recommend that sprintf _never_ be used - 'snprintf' is
more secure.

[Daniel]

On Monday, April 25, 2016 at 1:04:37 PM UTC-4, Mr Flibble wrote:
> On 25/04/2016 13:39, Daniel wrote:
> >
> > For some definition of "good results". But if you want to format a double to
> > show the decimal point and one and only one trailing zero, you can't do it
> > with the built-in manipulators, you have to strip the rest of the trailing
> > zeros yourself.
>

> Nonsense, trailing zeros are quite easy to achieve; the following
> program outputs 1.0000:
>

My dear Mr Flibble, if something seems like nonsense to you, you should read
a little more carefully, and had you done that, you would have seen that the
requirement is to print 1.0, not 1.0000. (Generally, json and xml libraries want to preserve as much precision in the output as possible, subject to other requirements including round-trip, economical use of space, and when there are a number of equivalent floating point representations, the shortest one. So these libraries never use fixed precision output.)

Best regards,
Daniel

[Scott Lurndal]

I cannot see how that's better than 'printf("%4.1f\n", 1.0)'.

(note that Daniel specified only 1 trailing zero).

And you completely ignored his final point.

[Mr Flibble]

Don't be a fucktard mate.

std::cout << std::fixed << std::setprecision(1) << 1.0 << "\n";

outputs

1.0

/Flibble

[Daniel]

On Monday, April 25, 2016 at 1:43:22 PM UTC-4, Mr Flibble wrote:

> On 25/04/2016 18:36, Daniel wrote:
> >>
> > My dear Mr Flibble, if something seems like nonsense to you, you should read
> > a little more carefully, and had you done that, you would have seen that the
>> requirement is to print 1.0, not 1.0000.
>

> Don't be a fucktard mate.
>
> std::cout << std::fixed << std::setprecision(1) << 1.0 << "\n";
>
> outputs
>
> 1.0
>

If all of the numbers were "1", I would agree with you. But usually I have
other numbers.

>> (Generally, json and xml
>> libraries want to preserve as much precision in the output as possible, >> subject to other requirements including round-trip, economical use of
>> space, and when there are a number of equivalent floating point
>> representations, the shortest one. So these libraries never use fixed
>> precision output.)

But I do accept your gentle remonstrance for a "fucktard" moment, as my last
sentence is incorrect, I should have said, these libraries never use fixed
number of decimal places. They typically do use fixed precision, either 15 (for simple round trip), 16 (if preserving the precision of the input floating point numbers, and thus round trip) or 17 (if the double to text algorithm is Grisu2)

Best regards,
Daniel

[Jerry Stuckle]

On 4/25/2016 1:07 PM, Daniel wrote:
> On Monday, April 25, 2016 at 11:41:09 AM UTC-4, Jerry Stuckle wrote:
>>
>> I can see why you think iostreams are so slow, though.
>
> Always nice to see that ah hah moment in our friends and acquaintances on
> usenet.
>

I see the sarcasm went "whoosh".

>> I would never
>> use to_json, to_xml, etc. to write data unless it had to be in a format
>> compatible with many applications across a network or something similar.
>> That's what these formats were made for.
>
> Using my own modest attempt at a json library for parsing and
> serialization (published as open source), on my Dell Precision notebook,
> it takes a little under 10 seconds to read a gigabyte of json text, and a
> little under 2 seconds to write it, with insertion to an ostream and
> extraction from an istream. Those numbers require some optimizations within
> the library when reading and writing to the stream, without them, using
> stream io simplistically, read would be about 5 times slower, and write 4
> times slower (there are other open source json libraries that are faster,
> but they have their own issues.)
>

And reading/writing binary files would be even faster.

> Generally, I find these times acceptable for reading and writing a gigabyte
> of text, and usually the amount of data I work with is somewhat smaller.
> Typically, if I push a button on a python app which sends a json request to
> C++ server to simulate some data and transfer it back as json over a socket,
> the resulting 3D plot in the python app appears close to instantaneous. So
> in most cases, I'm not particularly motivated to transfer anything except
> text, given text's other advantages. In those other cases, I use Google
> protocol buffers.
>

That's fine. What happens when you use iostreams and optimize the
buffer usage?

>>
>>>>> manipulators were never a good idea, too inflexible.
>>
>> Good enough tat millions of programmers around the world have been happy
>> with them.
>
> But perhaps not very, very happy. A little Google search will show you much
> wailing and gnashing of teeth, many hacks and workarounds, and not a few
> alternative toolkits for formatting.
>

YOU might not be happy, but those programmers are. Sure, you 'll see
wailing and gnashing of teeth, etc. But it's only the people who don't
like it who are posting. And that's a pretty small number of the total
C++ programmers in the world.

>> But as for the format mask - you're still thinking
>> procedural code, not object oriented.
>
> You weren't one of those who subscribed to JOOP, were you :-)
>

No, but I've been doing OO for over a quarter century, and taught it to
corporations for about 1/2 that time.

> In any case, the substance of OO, abstract interfaces, is silent about
> whether I want to keep the format of a number, date, currency, phone number
> etc. as a string representation in a data store, where my users can
> configure it without having to recompile a computer application.
>
> Best regards,
> Daniel
>
>

Sure, you are free to store the data in any format you wish. But the
key here is the object defines its own storage format and is responsible
for that format.

And why would they need to "configure it without having to recompile a
computer application"? And if they do, how do they do it with printf?

[Jerry Stuckle]

Sure. The object is responsible for its own formatting.

The object being responsible for itself is one of the basic premises of
object oriented programming.

> I would recommend that sprintf _never_ be used - 'snprintf' is
> more secure.
>

[Rosario19]

On Sat, 23 Apr 2016 00:22:09 +0100, Mr Flibble wrote:

>Why are implementers of C++ stdlibs such lazy fuckers? Just noticed that
>libstdc++ creates a separate temporary sprintf format string for EACH
>number you want to output and then uses that string in an internal call
>to sprintf (or its equivalent) for each number.
>
>Yes code-reuse is good in general but here using the C stdlib in a C++
>LIBRARY implementation resulting in poor performance is just not on.

why? if use the same functions that C stdio; the only reason i can
think would be the code is not localizated in the same place in memory
and there are many calls in different parts of memory [instead of a
loop or function calls in some little region of memory]


>This isn't a problem with C++ iostreams per se it is a problem with the
>quality of their implementation. C++ iostreams could easily outperform
>the C alternatives if a bit of effort was put in to leverage argument types.

>/Flibble

[Juha Nieminen]

Daniel <daniel...@gmail.com> wrote:
> Also, since the manipulators are expressed in code, you
> can't easily put a format mask into configuration storage, which is
> something we frequently want to do.

Which, incidentally, is one of the major security flaws typical of C
which many programmers aren't aware of (unless you go through the
trouble of implementing a checking code that meticulously validates
the format string before using it).

[Juha Nieminen]

I'm talking about the code that uses the stream to output the value.
How can that code know if it should just output the value as-is, or
whether it should call the .to_string() method of it? Especially
if the code is eg. templated.

[Juha Nieminen]

Christian Gollwitzer <auri...@gmx.de> wrote:
> Write a virtual print/serialize function in your class. You rarely need
> to "just print" it. Maybe even printf("%s", my.repr()) can be an easy
> solution.

And obviously this solution works fine and dandy if 'my' happens to be
a more abstract or generic type (such as a template type)?

[leigh.v....@googlemail.com]

Because printf is doing one thing whilst cout is doing three things multiple times for EACH number:

1. Changing state for each manipulator call
2. Generating a sprintf format string
3. Calling sprintf.

[woodb...@gmail.com]

On Friday, April 22, 2016 at 6:22:12 PM UTC-5, Mr Flibble wrote:

Leigh, Please don't swear here.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Mr Flibble]

On 26/04/2016 18:51, woodb...@gmail.com wrote:
> On Friday, April 22, 2016 at 6:22:12 PM UTC-5, Mr Flibble wrote:
>
> Leigh, Please don't swear here.

'This video may contain sexual swearwords, I'm afraid. There are 28
'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf

https://www.youtube.com/watch?v=42UCpOzTbNU

/Flibble

[Robert Wessel]

Unless I missed where this thread was restricted to only POSIX
compliant systems, positional parameters are not actually a standard
feature of printf format strings. And so the ordering problem is not
actually any better for printf than for iostreams.

[Öö Tiib]

Yes they perhaps mix up GNU gettext, POSIX extensions, standard 'printf'
and 'boost::format'. Actually reordering of words solves only one
trivial difference in languages. Most others remain. All those grammatical
cases, conjugations, counted plurals etc.

English example: achieve that "1st", "2nd", "3rd", "4th", "5th" is
written correctly with whatever of those 'printf's.

[Dombo]

Op 25-Apr-16 om 0:56 schreef Mr Flibble:

> On 24/04/2016 23:40, Marcel Mueller wrote:
>> [snip] And awaiting
>> a better solution I am stuck with printf so far.
>
> Boost.Format mate.

Has anyone tried cppformat (https://github.com/cppformat/cppformat)? It
looks promising, but so far I've only seen the authors claims.