Working with Large Values (double)

[jacob navia]

Le 04/03/2014 10:57, Juha Nieminen a écrit :

How many times have you become confused by it?

It is not a matter of confusion it is a matter that

1) this "operator" paradigm forces an incredible verbosity for changing
the width, etc, and precludes querying the output stream for getting the
current state, for instance, that could have been screwed somewhere. You
have to query the state with a function.

2) printf is a run time interpreter with a concise language It would be
extensible of course, if the C committee decided to extend it. It is not
extensible because C is no longer developed (c++ has destroyed it)

 

[Ian Collins]

Le 04/03/2014 10:52, Juha Nieminen a écrit :

Sure, better not. You could start by reading the problems of C++, for
instance here:

http://yosefk.com/c++fqa/index.html

Each language is an approximation to perfection Mr. Has some bright
things and some bad things. There is no magic bullet.

Unfortunately C++ inherited most the problems of C and added more of
it's own

 

[Ian Collins]

2) printf is a run time interpreter with a concise language It would be
extensible of course, if the C committee decided to extend it. It is not
extensible because C is no longer developed (c++ has destroyed it)

So you missed the memo on C11?

C is still being developed, just not in the way you would like it to.

 

[woodbrian77]

Unfortunately C++ inherited most the problems of C

True, but a lot of those problems have been addressed
over time.

and added more of
it's own

True, but a lot of those problems have been addressed
over time. C++ isn't perfect, but it has been improved
quite a bit over the years.

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

 

[jacob navia]

Le 04/03/2014 22:07, Ian Collins a écrit :

So you missed the memo on C11?

C is still being developed, just not in the way you would like it to.

Of course not. Nobody in C uses printf. What we need is a new threading
model and a new standard for threads that will replace pthreads and
windows threads. Microsoft and Unix guys will rewrite all their software
for the new C standard.

That is the direction we need C to go.

 

[jacob navia]

Le 04/03/2014 23:00, (e-mail address removed) a écrit :

C++ isn't perfect, but it has been improved
quite a bit over the years.

Exactly. I agree with that.

Like every other computer language!

My point is that we are not in a religious discussion but in a TECHNICAL
discussion where things should be examined without any hype.

jacob

 

[woodbrian77]

It's a rigid, fixed format that's not extensible, type-safe or abstract.
Sure, it's short, but that's about it.

I don't know what you mean with abstract. Should it be
grouped with extensible?

Are there any iostream implementations that are thought
to be good?

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

 

[Öö Tiib]

Le 04/03/2014 10:52, Juha Nieminen a écrit :

Most awful piece of code I have seen during my life was written in C#.
That does not mean that C# is bad programming language. It means that
author of the code was weak software developer.

I know no programming languages in what it is lot harder to express
nonsense than using LISP. That does not mean that our industry is in
same spot as in 1958. We simply do not need software that is written
by stupid people; smart people however can well avoid expressing
idiocy without external aid.

Sure, better not. You could start by reading the problems of C++, for
instance here:

http://yosefk.com/c++fqa/index.html

Yossi Kreinin has not updated that site for 5 years, what happened to
him? Major changes have taken place with C++ meanwhile. Experience
indicates that rather good changes.
What he complained...
C++ compiles slowly? Buy bigger build farm.
C++ contains features that he dislikes? Don't use these, it stays Turing
complete.
C++ does not have GC? Take some GC lib ... to me it feels like mounting
snowplough to race car ... but YMMV.
He likes C more? Use C then.
Too lot of words about such nonsense issues.

 

[Victor Bazarov]

Le 04/03/2014 10:52, Juha Nieminen a écrit :

[...]

Sure, better not. You could start by reading the problems of C++, for
instance here:

http://yosefk.com/c++fqa/index.html

Yossi Kreinin has not updated that site for 5 years, what happened to
him? Major changes have taken place with C++ meanwhile. Experience
indicates that rather good changes.
What he complained...
C++ compiles slowly? Buy bigger build farm.
C++ contains features that he dislikes? Don't use these, it stays Turing
complete.
C++ does not have GC? Take some GC lib ... to me it feels like mounting
snowplough to race car ... but YMMV.
He likes C more? Use C then.
Too lot of words about such nonsense issues.

Is anybody reminded by this all of the Aesop's fable about the fox and
the grapes?

V

 

[Jorgen Grahn]

Le 04/03/2014 10:52, Juha Nieminen a écrit :
[...]
Sure, better not. You could start by reading the problems of C++, for
instance here:

http://yosefk.com/c++fqa/index.html

....
He likes C more? Use C then.
Too lot of words about such nonsense issues.

Is anybody reminded by this all of the Aesop's fable about the fox and
the grapes?

Not really, but it's a bit sad and disturbing. What is it about
C++ that makes some people spend so much energy badmouthing it?

And why is comp.lang.c++ tied up discussing these issues, which
were mostly old news twenty years ago when Stroustrup wrote
"design & evolution of C++"? What's next -- Elvis or Tommy Steele?

/Jorgen

 

[88888 Dihedral]

Le 26/02/2014 23:30, Jorgen Grahn a écrit :








Exactly, and I like specially the last one:



std::cout << ForTheNSA(some_customer);



!!!

OH, C++ was banned before in NASA
and military research related projects
before. But that was relaxed.

 

[jacob navia]

Le 05/03/2014 23:40, Jorgen Grahn a écrit :

Not really, but it's a bit sad and disturbing. What is it about
C++ that makes some people spend so much energy badmouthing it?

If you care to follow this thread, all started with the c++ people
badmouthing C, what here is (of course) nothing new since c++ started.

I complained about people always telling that C"c is horrible" etc. I
took exception against an assertion that "printf" was "one of the worst
designs ever".

Of course bad mouthing c is OK for you.


I just said that:

1) C++ output formatting design is based on a wrong design decision:
operator overloading.

2) This leads to overly verbose and inflexible code.

That is "badmouthing c++"?

ANY critique of this thing is forbidden or what?

jacob

 

[Ian Collins]

I just said that:

1) C++ output formatting design is based on a wrong design decision:
operator overloading.

Which is open for debate. After using C++ for a while, one starts to
think of << and >> as insert and extract operators and their use appears
natural. I often include an insert operator for vector like containers,
mainly to have the convenience of chaining.

2) This leads to overly verbose and inflexible code.

It certainly can be verbose if anything other than trivial formatting is
required, but in a significant majority of the code I've written or seen
it isn't.

I don't see where you get inflexible from, especially in a comparison
with printf and friends where the language standard has to be updated to
output a new type. One of the good things about C++ streams is that
they *are* very flexible. It's not just the ability to provide insert
and extract operators for any type, but those operators can be used to
stream to and from objects other than stdin and stdout.

That is "badmouthing c++"?
Nope.

ANY critique of this thing is forbidden or what?

Nope, just be ready to back it up.

 

[David Brown]

Le 05/03/2014 23:40, Jorgen Grahn a écrit :

If you care to follow this thread, all started with the c++ people
badmouthing C, what here is (of course) nothing new since c++ started.

It is worth noting that this is a C++ newsgroup - people here mostly
choose to use C++ rather than C because they think it is a better
language for their use. So it is not particularly surprising to find a
discussion here about why the C++ way is better than the C way. You'll
find the opposite in comp.lang.c.

Of course it is always reasonable to have a discussion about different
ways to solve problems, or different programming techniques and styles.
printf and <iostream> have their pros and cons, and comparison and
dialogue helps both language users and language designers.

What Jorgen was talking about was the inordinate effort that some people
- such as the C++ FQA author - seem to spend in complaining about C++.
No one minds a discussion about a C++ feature that is controversial or
that you don't particularly like, but it is hard to understand why
someone would spend countless hours on an obsessive site like the FQA.
Of course, some of the points raised in the FQA are valid - and some of
those have been addressed in C++11. But many points are just a hate
campaign against C++, and that helps no one.

I complained about people always telling that C"c is horrible" etc. I
took exception against an assertion that "printf" was "one of the worst
designs ever".

Of course bad mouthing c is OK for you.


I just said that:

1) C++ output formatting design is based on a wrong design decision:
operator overloading.

That's opinion, not fact. So yes, expressing your opinion as though it
were an indisputable fact /is/ arguably badmouthing, and it makes it
hard to have a balanced discussion.

2) This leads to overly verbose and inflexible code.

Again, that's opinion and not fact.

That is "badmouthing c++"?

ANY critique of this thing is forbidden or what?

Critique is fine. It is fine to say "I think printf is better
because...". It is fine to say "I find <iostream> formatting to be ugly
and inflexible". It is fine to say "printf is a better choice in cases
such as...". It is also fine to say "C++ formatting would be better if
done like this..."

But saying "C++ output formatting design is based on a wrong design
decision", using "proof by repetition" as your justification, is not
constructive.


I have read enough of your posts to know that you have a lot of very
interesting ideas and opinions about C and C++, and your own variant of
"enhanced C". But I think we can get more discussion and less conflict
if you are a bit more open-minded, and accept that other people have
different opinions and different needs.

/Everyone/ who knows C++ has opinions about things that are "wrong" in
the language - it's such a big language (and library) that this is
inevitable. And the C++ language designers know this too - there are
lots of things that they would have done differently had they known what
they know now. Sometimes it is too late to change things, sometimes the
changes can be made in newer standards. But if the C++ language
designers picked a particular solution for a problem in hand (such as
output formatting), and you disagree with their design, isn't it a bit
presumptuous for you to declare that /you/ are right and all the people
behind C++ are wrong?

David

 

[Daniel]

Which is open for debate. After using C++ for a while, one starts to
think of << and >> as insert and extract operators and their use appears
natural.

Inserting and extracting in a specific order doesn't fit well with
internationalization, though.

It certainly can be verbose if anything other than trivial formatting is
required, but in a significant majority of the code I've written or seen
it isn't.

It should be possible to do nontrivial formatting with the standard input
and output features of the language, but in practice most nontrivial
formatting, e.g. formatting with 000's separators, formatting money,
internationalization etc. is done by calling format methods on strings.As someone with an interest in json parsers, I note that even something
as simple as the preferred json floating point output format, which is
truncate trailing zeros after the decimal point, except the one immediately
following the decimal point, cannot be accomplished with the floatfield
support alone (that's also true for printf.)

I don't see where you get inflexible from, especially in a comparison
with printf and friends

A comparison with printf and friends is probably not a great comparison,
when designing << and >>, the author obviously had the C functions in mind,
the limitations of floatfield are the same. >> has some disadvantages
compared to the C function, ease of internationalization being one, and it's
much slower! but it offers one huge advantage, overloading, which is the reason
most people including myself use it. Of course overloading could have been
achieved with a more sensibly designed io library.

those operators can be used to
stream to and from objects other than stdin and stdout.

Other languages such as Java offer much better abstractions for input
and output streams. A big reason incidentally why Java displaced much of C++
for data workflow server products, where byte streams in many, many different
encodings have to coexist. C++ people are still struggling with getting
unicode to work.

Not to mention that COBOL had a better model for masked output, and that
could have been considered prior art at the time.

And how did they manage to make << >> so slow! << >> seems to be the counter
example to the advice often heard here, don't optimize prematurely. If the
original architecture is inherently slow, there are limits to what even a
super optimizing compiler team can do with it.

Best regards,
Daniel

 

[Öö Tiib]

And how did they manage to make << >> so slow! << >> seems to be the counter
example to the advice often heard here, don't optimize prematurely. If the
original architecture is inherently slow, there are limits to what even a
super optimizing compiler team can do with it.

Is iostream slow? Here is test that I have observed that on some platforms C++
I/O performs 20% faster than C I/O and on others 50% slower. In general
neither should be used for truely performance-critical I/O.

/// THE TEST //////////////////////

#include <fstream>
#include <iostream>
#include <iomanip>

#include <cmath>
#include <cstdio>

#include <sys/time.h>

template <typename Func>
double benchmark(Func f, size_t iterations)
{
f();

timeval a, b;
gettimeofday(&a, 0);
for (; iterations --> 0
{
f();
}
gettimeofday(&b, 0);
return (b.tv_sec * (unsigned int)1e6 + b.tv_usec) -
(a.tv_sec * (unsigned int)1e6 + a.tv_usec);
}


struct CRead
{
CRead(char const* filename): _filename(filename) {}

void operator()() {
FILE* file = fopen(_filename, "r");

int count = 0;
while ( fscanf(file,"%s", _buffer) == 1 ) { ++count; }

fclose(file);
}

char const* _filename;
char _buffer[1024];
};

struct CppRead
{
CppRead(char const* filename): _filename(filename), _buffer() {}

enum { BufferSize = 16184 };

void operator()() {
std::ifstream file(_filename, std::ifstream::in);

// comment to remove extended buffer
file.rdbuf()->pubsetbuf(_buffer, BufferSize);

int count = 0;
std::string s;
while ( file >> s ) { ++count; }
}

char const* _filename;
char _buffer[BufferSize];
};


int main(int argc, char* argv[])
{
size_t iterations = 1;
if (argc > 1) { iterations = atoi(argv[1]); }

char const* oldLocale = setlocale(LC_ALL,"C");
if (strcmp(oldLocale, "C") != 0) {
std::cout << "Replaced old locale '" << oldLocale << "' by 'C'\n";
}

char const* filename = "largefile.txt";

CRead cread(filename);
CppRead cppread(filename);

// comment to use the default setting
bool oldSyncSetting = std::ios_base::sync_with_stdio(false);

double ctime = benchmark(cread, iterations);
double cpptime = benchmark(cppread, iterations);

// comment if oldSyncSetting's declaration is commented
std::ios_base::sync_with_stdio(oldSyncSetting);

std::cout << "C : " << ctime << "\n"
"C++: " << cpptime << "\n";

return 0;
}
/////////// HAVE FUN ////////////////

 

[Victor Bazarov]

struct CRead
{
CRead(char const* filename): _filename(filename) {}

void operator()() {
FILE* file = fopen(_filename, "r");

int count = 0;
while ( fscanf(file,"%s", _buffer) == 1 ) { ++count; }

fclose(file);
}

char const* _filename;
char _buffer[1024];
};

You've chosen the _least efficient_ method of counting strings
in C that you could find. At least dump the fscanf and use fgets.

Better would be simply to memory map the file and walk memory
(mmap, CreateFileMapping) counting newlines, windowing as necessary
for larger files.

You maybe a bit confused. He's not counting lines. He's reading
strings (sequences of non-whitespace characters). For counting lines in
C++ one could use 'getline'.

V

 

[Öö Tiib]

I did put correct quote here, because that was whole point of my posting.

You've chosen the _least efficient_ method of counting strings
in C that you could find. At least dump the fscanf and use fgets.

Better would be simply to memory map the file and walk memory
(mmap, CreateFileMapping) counting newlines, windowing as necessary
for larger files.

I did say exactly the same thing as reply to question why it is so slow.
Standard I/O is generic, (good enough for lot of cases) I/O that is about
as performant in C and in C++.

Where performance is needed there we always use platform-specific
APIs directly to get performance up and do not use neither C nor C++
standard library tools.

 

[jacob navia]

Thanks for that program. I obtain:

C : 7.66352e+06
C++: 9.3946e+06

In the implementation I tested the C++ routines call fscanf...

Machine Mac Pro (tower) 2.26 Ghz Quad core Intel Xeon
Mac OS X Version 10.9.2

compiler: g++
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0

 

[Victor Bazarov]

Thanks for that program. I obtain:

C : 7.66352e+06
C++: 9.3946e+06

In the implementation I tested the C++ routines call fscanf...

It only shows the [low] quality of that implementation, doesn't it? No
surprise there.

Machine Mac Pro (tower) 2.26 Ghz Quad core Intel Xeon
Mac OS X Version 10.9.2

compiler: g++
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0

V