Is this C or C++?

[crea]

Simple question. If the task is (for example):
"Write a C++ program which asks user his name (less than 20 chars) and
prints it."

Then, is this code a correct answer:

char name[100];
cout<<"Your name?"<<endl;
cin>>name;
cout<<name<<endl;

The point being, that the code uses C string "char name[]" and not C++
std::string.
C is a subset of C++, so isnt it logically speaking a C++ program?

[crea]

[Leigh Johnston]

Ask yourself what happens if user types in more than 99 characters.

/Leigh

[Barry Schwarz]

The belief that C is a proper subset of C++ is the source of many
misconceptions.

The fact that cin supports reading into a char array is what makes the
code legal C++. Whether using a std::string would make it more of a
C++ program is a philosophical discussion.

--
Remove del for email

[crea]

"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:w9GdnXTGEYr0QxbP...@giganews.com...

The task says its less than 20 chars ...

[crea]

"Barry Schwarz" <schw...@dqel.com> wrote in message
news:3vnn89l8cb3kr8nj5...@4ax.com...

> On Tue, 19 Nov 2013 21:44:40 -0000, "crea" <n...@com.notvalid> wrote:
>
>>Simple question. If the task is (for example):
>>"Write a C++ program which asks user his name (less than 20 chars) and
>>prints it."
>>
>>Then, is this code a correct answer:
>>
>>char name[100];
>>cout<<"Your name?"<<endl;
>>cin>>name;
>>cout<<name<<endl;
>>
>>The point being, that the code uses C string "char name[]" and not C++
>>std::string.
>>C is a subset of C++, so isnt it logically speaking a C++ program?
>
> The belief that C is a proper subset of C++ is the source of many
> misconceptions.

Ok, I did not really mean 100% like that, but in this example it does not
matter if its 100% or not.

>
> The fact that cin supports reading into a char array is what makes the

> code legal C++. Whether using a std::string would make it more of a
> C++ program is a philosophical discussion.

Here I think I agree.

But this might be a real "problem" in a school assignments, or in a
programming job interview, is asked to code something.

[crea]

"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:w9GdnXTGEYr0QxbP...@giganews.com...

[Jorgen Grahn]

Then I would ask why the buffer has room for 99?

Or I would avoid that discussion (and a whole family of related
discussions about trusting user input, trusting requirements and
documenting limitations and undefined behavior of a program) by using
std::string.

It's available, it's standard, so why use anything more complicated?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Victor Bazarov]

So why did you actually write "100" as the size of the array? Why not
20? Just "in case"? IOW, somewhere in the back of your mind there was
a lingering doubt that the user *just might* ignore what "the task says"
and enter more... Does this mean the code was a "correct" answer? Or
does it contain an error? It might be excusable as an answer to a
school assignment, but it won't fly at a job interview.

I understand that your question is probably not about that, but rather
about the use of arrays as compared to objects (char[] vs std::string).
The answer to that is that the use of arrays is *just as OK in C++ as
it is in C* and does not make your program, in which you need to use
arrays, suddenly "logically speaking" *not* C++.

Although, *technically* speaking, a program that cannot be compiled with
a C++ compiler can be considered "not C++". So, a syntax error could
make a program "not C++" despite of all efforts to the contrary.
Technically speaking, that is. ;-)

V
--
I do not respond to top-posted replies, please don't ask

[Paavo Helde]

Jorgen Grahn <grahn...@snipabacken.se> wrote in
news:slrnl8nqcl.h...@frailea.sa.invalid:

> Or I would avoid that discussion (and a whole family of related
> discussions about trusting user input, trusting requirements and
> documenting limitations and undefined behavior of a program) by using
> std::string.
>
> It's available, it's standard, so why use anything more complicated?

Indeed, std::string is much less complicated (to use) than a raw C-style
array. When coming from the C language side this might not be so obvious,
so trying to emphasise this point.

Cheers
Paavo

[crea]

"Victor Bazarov" <v.ba...@comcast.invalid> wrote in message
news:l6gq6d$ktv$1...@dont-email.me...

yes

> The answer to that is that the use of arrays is *just as OK in C++ as it
> is in C* and does not make your program, in which you need to use arrays,
> suddenly "logically speaking" *not* C++.
>


> Although, *technically* speaking, a program that cannot be compiled with a
> C++ compiler can be considered "not C++".

Ye, I think this could be said. In the example it was mixed though, so it
could be said its c++?

[crea]

"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:chars-2013...@ram.dialup.fu-berlin.de...

> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>>>>"Write a C++ program which asks user his name (less than 20 chars)
>>>>>and

>>Then I would ask why the buffer has room for 99?
>

> The question says that the name of the user has less than 20 chars.
> This does not exclude that the user may type in 200 chars.
> He might be a penetration tester whose name has less than 20 chars.
>

ye, so the if- was missing. This , and the 100, was not intetented to be the
point though...

>

[crea]

"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:chars-2013...@ram.dialup.fu-berlin.de...
> Jorgen Grahn <grahn...@snipabacken.se> writes:

>>>>>"Write a C++ program which asks user his name (less than 20 chars)
>>>>>and

>>Then I would ask why the buffer has room for 99?
>

[Victor Bazarov]

On 11/20/2013 2:52 AM, crea wrote:
> [..] In the example it was mixed though, so it

> could be said its c++?

Following the same logic, any program that can be successfully compiled
with a C++ compiler, *is* a C++ program. Technically speaking.

[Victor Bazarov]

On 11/20/2013 11:39 AM, Victor Bazarov wrote:
> On 11/20/2013 2:52 AM, crea wrote:
>> [..] In the example it was mixed though, so it
>> could be said its c++?
>
> Following the same logic, any program that can be successfully compiled
> with a C++ compiler, *is* a C++ program. Technically speaking.

Clarification: with a Standard-compliant C++ compiler.

[Öö Tiib]

On Wednesday, 20 November 2013 00:26:54 UTC+2, crea wrote:
> "Barry Schwarz" <schw...@dqel.com> wrote in message
> news:3vnn89l8cb3kr8nj5...@4ax.com...
> > On Tue, 19 Nov 2013 21:44:40 -0000, "crea" <n...@com.notvalid> wrote:
> >
> >>Simple question. If the task is (for example):
> >>"Write a C++ program which asks user his name (less than 20 chars) and
> >>prints it."
> >>
> >>Then, is this code a correct answer:
> >>
> >>char name[100];
> >>cout<<"Your name?"<<endl;
> >>cin>>name;
> >>cout<<name<<endl;

If you meant it as listing of a program then it certainly is not.
I can tell without trying that it does not compile on any C++
or C compiler I know of.

> >>The point being, that the code uses C string "char name[]" and not C++
> >>std::string.
> >>C is a subset of C++, so isnt it logically speaking a C++ program?
> >
> > The belief that C is a proper subset of C++ is the source of many
> > misconceptions.
>
> Ok, I did not really mean 100% like that, but in this example it does not
> matter if its 100% or not.

Yes, since it was not valid program.

> > The fact that cin supports reading into a char array is what makes the
> > code legal C++. Whether using a std::string would make it more of a
> > C++ program is a philosophical discussion.
>
> Here I think I agree.
>
> But this might be a real "problem" in a school assignments, or in a
> programming job interview, is asked to code something.

Schools teach people the art of getting best grades out of
fellow person. That is important skill but persons differ so
we can not advice here without seeing particular individual.
Same skill matters in work interview as well, but the person
interviewing you is often smarter than the one in school so
be warned. ;)

On any case it has nothing to do with similarities or
differences between C and C++.

[Alf P. Steinbach]

The code is non-C by using iostreams.

It's not a good answer, on three counts:

* You risk a buffer overrun (storing data beyond the end of the array),
which is Undefined Behavior.
* A student might type in his or her full name, with a space or two, in
which case the above, using >>, will read only the first "word".
* After the above code there is at least a newline left in the input
buffer, which might cause havoc with a subsequent input operation.

To fix the buffer overrun use e.g. std::string. To fix the "word-by-word
input" problem as well as the problem of leaving text in the input
buffer, use std::getline instead of >>.

Cheers & hth.,

- Alf

[crea]

"Victor Bazarov" <v.ba...@comcast.invalid> wrote in message

news:l6iokg$550$1...@dont-email.me...

> On 11/20/2013 2:52 AM, crea wrote:
>> [..] In the example it was mixed though, so it
>> could be said its c++?
>
> Following the same logic, any program that can be successfully compiled
> with a C++ compiler, *is* a C++ program. Technically speaking.

Technically yes, but ideally we could maybe call a pure C-code (a code that
compiles on a C compiler) a C-code even if its compiled using a C++
compiler.

[crea]

"�� Tiib" <oot...@hot.ee> wrote in message
news:b1e33088-ae50-438d...@googlegroups.com...

>> But this might be a real "problem" in a school assignments, or in a
>> programming job interview, is asked to code something.
>
> Schools teach people the art of getting best grades out of
> fellow person. That is important skill but persons differ so
> we can not advice here without seeing particular individual.
> Same skill matters in work interview as well, but the person
> interviewing you is often smarter than the one in school so
> be warned. ;)
>
> On any case it has nothing to do with similarities or
> differences between C and C++.

I mean that in C++ job interview they might as to write a C++ code. One
might use partly C-style library functions, the other pure C++. But
according to definition they both are actually C++ codes.

Maybe the thing is that if there is a C++ (library) version of certain
code/function then that should be used instead of C version? So C library
calls should be avoided always in C++ code (if just possible and there is a
C++ counter part)?

[crea]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote in message
news:l6iqn2$jf3$1...@dont-email.me...

ok, true I was careless in making the C program. Here is the working
version:
**************
#include <stdio.h>

int main()
{
int bytes_read;
int nbytes = 100;
char *my_string;

puts ("Please enter a line of text.");

/* These 2 lines are the heart of the program. */
my_string = (char *) malloc (nbytes + 1);
bytes_read = getline (&my_string, &nbytes, stdin);

if (bytes_read == -1)
{
puts ("ERROR!");
}
else
{
puts ("You typed:");
puts (my_string);
}

return 0;
}*************

Now, this has no issues what you said if max name lenght is limited to, say,
30 or 99..

[crea]

"crea" <n...@com.notvalid> wrote in message
news:41Riu.58433$8G6....@fx22.am4...

hmmm, its clear that the code should be as good and fast as possible. So
most C++ versions are better than C versions, so C++ versions should be
used. But what if the performance is the same with C-version. Is it ok then
to us it? Say somekind of atoi()-function from C, rather than some kind of
C++ conversion function.

[Juha Nieminen]

crea <n...@com.notvalid> wrote:
> hmmm, its clear that the code should be as good and fast as possible. So
> most C++ versions are better than C versions, so C++ versions should be
> used. But what if the performance is the same with C-version. Is it ok then
> to us it? Say somekind of atoi()-function from C, rather than some kind of
> C++ conversion function.

I'm not exactly sure what you are talking about, but in many cases the
standard C functions tend to be faster than the equivalent C++ functions
(although there are some exceptions, most prominently qsort() vs.
std::sort(), and arguably some string manipulation functions.)

If you can (safely) use std::atoi(), then it's faster than the equivalent
code using std::stringstream.

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

[Juha Nieminen]

crea <n...@com.notvalid> wrote:
> int main()

I'm not very versed in C99, but at least in the older C you had to write
that as "int main(void)". (Has this changed in C99?)

> bytes_read = getline (&my_string, &nbytes, stdin);

I don't think that's standard C. getline() is a POSIX extension.

[crea]

"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:l6kloj$1j0s$1...@adenine.netfront.net...

> crea <n...@com.notvalid> wrote:
>> int main()
>
> I'm not very versed in C99, but at least in the older C you had to write
> that as "int main(void)". (Has this changed in C99?)

hmm, I never used that. Even when coding in 90 s, like VC++ 6

>
>> bytes_read = getline (&my_string, &nbytes, stdin);
>
> I don't think that's standard C. getline() is a POSIX extension.

This is not a point though in this debate as C++ and C can be mixed as the
question was that can I mix C with C++ and still call it C++ program.

[crea]

"Juha Nieminen" <nos...@thanks.invalid> wrote in message

news:l6klk0$1ir8$1...@adenine.netfront.net...

> crea <n...@com.notvalid> wrote:
>> hmmm, its clear that the code should be as good and fast as possible. So
>> most C++ versions are better than C versions, so C++ versions should be
>> used. But what if the performance is the same with C-version. Is it ok
>> then
>> to us it? Say somekind of atoi()-function from C, rather than some kind
>> of
>> C++ conversion function.
>
> I'm not exactly sure what you are talking about, but in many cases the
> standard C functions tend to be faster than the equivalent C++ functions
> (although there are some exceptions, most prominently qsort() vs.
> std::sort(), and arguably some string manipulation functions.)

Many other examples as well where C++ is faster. Like in some situations
where you check the type and do calculations according to that in C++ and C
does not do the same so its slower. Sometimes C uses void* types to do
calculations, when C++ knows the type and thus can use a special very fast
methods to proceed.

Also sometimes in vectors etc its faster to do a memcopy instead of copying
eatch element one by one like C functions are doing. So C++ is checking if
there is a faster method and proceeds according to that.

>
> If you can (safely) use std::atoi(), then it's faster than the equivalent
> code using std::stringstream.

I actually just did both of them, and yes seems like this is true.
stringstream method seemed to be much slower. Donno why....
There is no fast way of doing atoi in C++?

This is the problem: you never know which C function is faster that
corresponding C++ version. So you have to time it yourself or just know it.
But there are thousands of functions, so how can you remember how fast earch
of them are?

[crea]

"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:l6klk0$1ir8$1...@adenine.netfront.net...

> crea <n...@com.notvalid> wrote:
>> hmmm, its clear that the code should be as good and fast as possible. So
>> most C++ versions are better than C versions, so C++ versions should be
>> used. But what if the performance is the same with C-version. Is it ok
>> then
>> to us it? Say somekind of atoi()-function from C, rather than some kind
>> of
>> C++ conversion function.
>
> I'm not exactly sure what you are talking about, but in many cases the
> standard C functions tend to be faster than the equivalent C++ functions
> (although there are some exceptions, most prominently qsort() vs.
> std::sort(), and arguably some string manipulation functions.)

Many other examples as well where C++ is faster. Like in some situations
where you check the type and do calculations according to that in C++ and C
does not do the same so its slower. Sometimes C uses void* types to do
calculations, when C++ knows the type and thus can use a special very fast
methods to proceed.

Also sometimes in vectors etc its faster to do a memcopy instead of copying
eatch element one by one like C functions are doing. So C++ is checking if
there is a faster method and proceeds according to that.

>

> If you can (safely) use std::atoi(), then it's faster than the equivalent
> code using std::stringstream.

[Alf P. Steinbach]

On 21.11.2013 11:15, crea wrote:
>
> This is not a point though in this debate as C++ and C can be mixed as the
> question was that can I mix C with C++ and still call it C++ program.

Yes of course you can: you can't /not/ do that.

Consider that `int` comes from C, just to take one very obvious example.
So you can't even express the required C++ `main` function without some
bits of C sneaking in. Including the non-const'ness of the arguments of
that function, if you declare the arguments.

But whether you can get away with mostly C on an interview or exam, when
the task is to code up a C++ program, well that's another matter entirely...

[crea]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote in message

news:l6knej$3ki$1...@dont-email.me...

I guess mostly they do not like it. And surely they have a point. But
myself, I would not be so strict myself in my own coding that "everything
must be C++ if its possible" especially if the C version is faster or better
some other way. LIke somebody mentioned atoi is faster than strstream
version (and this is what i also noticed with the stream in my code).

But surely certain things are "the truth" always. Like always use
std::string instead of char[]. And always use vector instead of int[]. I did
this change in my coding years ago. No longer char[] s. Many reasons... one
being that if you add more code later, its easier to manage std::string.
Also its surely faster.

But again, if it was a very small program, and am 100% sure its not gonna
expand later, then why not use code like char[]- for strings if you feel so?
Does not matter...

[Öö Tiib]

On Thursday, 21 November 2013 10:22:17 UTC+2, crea wrote:
> "Öö Tiib" <oot...@hot.ee> wrote in message

> news:b1e33088-ae50-438d...@googlegroups.com...
> >> But this might be a real "problem" in a school assignments, or in a
> >> programming job interview, is asked to code something.
> >
> > Schools teach people the art of getting best grades out of
> > fellow person. That is important skill but persons differ so
> > we can not advice here without seeing particular individual.
> > Same skill matters in work interview as well, but the person
> > interviewing you is often smarter than the one in school so
> > be warned. ;)
> >
> > On any case it has nothing to do with similarities or
> > differences between C and C++.
>
> I mean that in C++ job interview they might as to write a C++ code. One
> might use partly C-style library functions, the other pure C++. But
> according to definition they both are actually C++ codes.

What interviewer more likely looks at is how you attack the problem
and safety and correctness of solution. If it compiles as C++ then
it is C++. Unfamiliar library or language is easy to learn for one
with programming skill.

>
> Maybe the thing is that if there is a C++ (library) version of certain
> code/function then that should be used instead of C version? So C library
> calls should be avoided always in C++ code (if just possible and there is a
> C++ counter part)?

Avoid mixing. Do not use <cstring> and <string> together or <cstdio>
and <iostream> together if possible.

[Alf P. Steinbach]

On 21.11.2013 12:42, 嘱 Tiib wrote:
>
> Avoid mixing. Do not use <cstring> and <string> together or <cstdio>
> and <iostream> together if possible.

I think you mean (or they say nowadays, ITYM) <string.h> and <string>
together, or <stdio.h> and <iostream> together.

Note, by the way, that in C++11 there's no longer even a formal reason
to <cstdio> instead of <stdio.h>, and there are good reasons not to.


Cheers,

- Alf (nitpicking and anti-pattern mode)

[Öö Tiib]

On Thursday, 21 November 2013 13:47:12 UTC+2, Alf P. Steinbach wrote:

> On 21.11.2013 12:42, �� Tiib wrote:
> >
> > Avoid mixing. Do not use <cstring> and <string> together or <cstdio>
> > and <iostream> together if possible.
>
> I think you mean (or they say nowadays, ITYM) <string.h> and <string>
> together, or <stdio.h> and <iostream> together.

I meant it is good to avoid usage of 'strlen()' and 'str.size()' in mix. Personally
I prefer latter since it performs better.

> Note, by the way, that in C++11 there's no longer even a formal reason
> to <cstdio> instead of <stdio.h>, and there are good reasons not to.

AFAIK the <csomething> headers include <something.h> and alias the
names in 'std' namespace. So people who want to have 'std::strlen' should
use <cstring>. Has something changed there? Personally I avoid it regardless
of namespace.

[Alf P. Steinbach]

On 21.11.2013 13:18, 嘱 Tiib wrote:
> On Thursday, 21 November 2013 13:47:12 UTC+2, Alf P. Steinbach wrote:

>> On 21.11.2013 12:42, 锟斤拷 Tiib wrote:
>>>
>> Note, by the way, that in C++11 there's no longer even a formal reason
>> to <cstdio> instead of <stdio.h>, and there are good reasons not to.
>
> AFAIK the <csomething> headers include <something.h> and alias the
> names in 'std' namespace. So people who want to have 'std::strlen' should
> use <cstring>. Has something changed there?

Yes.

In C++03 the headers were not allowed to do what you describe. E.g. with
an implementation conforming in this regard (which AFAIK no
implementation was, he he :), it was a feature much like "export")
<cstring> would introduce std::strlen but not ::strlen. For brevity I
give just the non-normative commentary from C++03 .5/3:

"Example: The header <cstdlib> provides its declarations and definitions
within the namespace std. The header <stdlib.h> makes these available
also in the global namespace, much as in the C Standard."

In C++11 they're finally allowed to pollute the global namespace, as you
describe above and capturing the actual practice, as described by the
corresponding C++11 5/3:

"Example: The header <cstdlib> assuredly provides its declarations and
definitions within the namespace std. It may also provide these names
within the global namespace. The header <stdlib.h> assuredly provides
the same declarations and definitions within the global namespace, much
as in the C Standard. It may also provide these names within the
namespace std"

And then there's not even a formal advantage of using e.g. <cstring>:
just problems, no advantage.

If someone absolutely want to write std::strlen then including <cstring>
is the way to do that, yes. However, plain <string.h> may also introduce
std::strlen, so that some code may compile on some implementation
without including what's formally needed for general portability --
which means added work when it's ported to a more strict implementation.
Worse, code that does use the global namespace strlen (no qualification,
which all C programmers and a great many C++ programmers are used to
write and so are likely to write) will /most likely/ compile, but again
may not compile with some more strict implementation, which again means
added work -- for no good reason.

In contrast, including <stdio.h> and writing just strlen has no
potential portability problem and minimizes the number of things to know
about (to wit, even you didn't recall exactly the detailed rules of
<cstring> etc). It also makes programmers more familiar with what the C
headers do place in the global namespace. Which, due to the pollution
that you get in practice, they do need to be familiar with.

[Drew Lawson]

In article <gXlju.77200$Xe4....@fx34.am4>

"crea" <n...@com.notvalid> writes:
>
>"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote in message
>news:l6knej$3ki$1...@dont-email.me...
>

>> But whether you can get away with mostly C on an interview or exam, when
>> the task is to code up a C++ program, well that's another matter
>> entirely...
>
>I guess mostly they do not like it. And surely they have a point. But
>myself, I would not be so strict myself in my own coding that "everything
>must be C++ if its possible" especially if the C version is faster or better
>some other way. LIke somebody mentioned atoi is faster than strstream
>version (and this is what i also noticed with the stream in my code).

What this comes down to, and many of the answers are brushing
against, is that you are not asking about the C++ language. You
are asking about (for lack of a better term) "C++ culture."

The problem there is that "C++ culture" is not a single thing.
Different projects, different groups, etc. have different preferences.

Last job, I worked with a guy who tried to put in every boost feature
that he could. Most of the rest of the team stuck with mostly
non-boost solutions. Both are valid ways, but this didn't make for
a good fit.

Without knowing the local culture, you can't predict the preferences.
What you *can* do is talk about what you are doing. When you put
in something that could go either way, talk around which you chose
-- "Foo items[2]; -- that could be a vector, but there are only two
that you toggle between . . . ."

Coding in an interview is not often about the final code. It is
about determining:
1) Does he understand the problem?
1a) If not, was his understanding reasonable?
2) Does the code solve the problem as he understood it?
3) Does his approach -- top-down, bottom-up, inside-out, etc.
-- seem good, or is it confused?
and so on.


I once had a code test for a C job. One of the problems was reversing
the order of the bits in the input. I wrote my solution, talking
it through while writing, finishing up with, "and [brief pause] it
is the same as the input." I had one of the operations (or one of
the loops, been a while) backwards. The important thing was that
I caught it and understood why it was wrong.

I got the job.

--
Drew Lawson While they all shake hands
and draw their lines in the sand
and forget about the mess they've made

[Drew Lawson]

In article <9blju.115250$qC.2...@fx07.am4>

"crea" <n...@com.notvalid> writes:
>
>"Juha Nieminen" <nos...@thanks.invalid> wrote in message
>news:l6klk0$1ir8$1...@adenine.netfront.net...

>> If you can (safely) use std::atoi(), then it's faster than the equivalent
>> code using std::stringstream.
>
>I actually just did both of them, and yes seems like this is true.
>stringstream method seemed to be much slower. Donno why....
>There is no fast way of doing atoi in C++?

stringstream is slower because it does more. It is a general tool.
atoi() is a very specific thing that only needs to check if it still
has digits. (Also, there is a reasonable chance that atoi() is
written in assembly.)

However, you seem to have too much focus on speed. Unless you are
doing something like real-time transaction processing, you are
unlikely to see the difference in speed.

>This is the problem: you never know which C function is faster that
>corresponding C++ version. So you have to time it yourself or just know it.
>But there are thousands of functions, so how can you remember how fast earch
>of them are?

Unless you have extreme requirements, just trust that standard
library calls (either C or C++) are fast enough. If you run into
things being too slow, it is much more likely that the problem is
in your application.

If you *do* have extreme requirements, you probably already have
enough experience to avoid time consuming operations in critical
places. (If not, you'll get experience quickly.)

--
| Stories of tortures used by debauchers
Drew Lawson | lurid, licentious and vile
| make me smile

[Victor Bazarov]

<shrug> Call it whatever you like.

A C++ program is one that compiles using a C++ compiler. A C program is
one that compiles using a C compiler. Can the same sequence of
characters be both? Yes. Is there any use of arguing that such a
sequence of characters (that is both a C and a C++ program) is *not* a
C++ program but somehow *only a C program*? I don't think so.

In *your* world, however, you may adopt any axioms you like (any axioms
that suit you) and say that "object that is both A and B we shall call B
and not A." It's your world and your prerogative.

[Paavo Helde]

"crea" <n...@com.notvalid> wrote in news:9blju.115250$qC.2...@fx07.am4:

>> Many other examples as well where C++ is faster. Like in some
> situations where you check the type and do calculations according to
> that in C++ and C does not do the same so its slower. Sometimes C uses
> void* types to do calculations, when C++ knows the type and thus can
> use a special very fast methods to proceed.

This is not related to types, but to templates and inlining instead. In
principle you could use void* in C++ too and do manual casting where
needed, if the thing gets inlined it's as fast as type-safe code
(static_cast<> is a null-op at run time). Such a void* approach has
sometimes been used in C++ to reduce the so-called "template bloat", but
nowadays compilers do this automatically.

> Also sometimes in vectors etc its faster to do a memcopy instead of
> copying eatch element one by one like C functions are doing. So C++ is
> checking if there is a faster method and proceeds according to that.

Does not follow, I'm sure C compilers recognize loops which can be
replaced with optimized memcpy, or vice versa.

>
>>
>> If you can (safely) use std::atoi(), then it's faster than the
>> equivalent code using std::stringstream.

Sure.

>
> I actually just did both of them, and yes seems like this is true.
> stringstream method seemed to be much slower. Donno why....
> There is no fast way of doing atoi in C++?

The "fast" is very relative. If you are parsing user-typed input or
otherwise a small number of numbers (like thousands), then stringstream
is most probably ok. Only if there are millions of numbers in tight
loops, then the parsing speed might become critical and one may need to
convolute the code by using atoi() (or probably the more manageable
variants strtol(), strtoul()).

There is also a handy boost::lexical_cast feature which is effectively
wrapping stringstream.

> This is the problem: you never know which C function is faster that
> corresponding C++ version. So you have to time it yourself or just
> know it. But there are thousands of functions, so how can you remember
> how fast earch of them are?

Experience helps a bit, but in reality you never know exactly how fast
something exactly is, as the hardware is constantly changing. The point
is to express your algorithm in the clearest and concise way you can
find, getting the algorithmic big-O complexities right and only worry if
something appears too slow in the end. And in that case one should start
with profiling an actual realistic usage case which is too slow, and
start with optimizing that.

Of course there are some rough guidelines like that dynamic memory
allocation and frequent virtual function calls are slow, dynamic_cast is
slower, and exception throwing is very slow. Arithmetics is fast and
memory access beyond cpu caches is slow. C++ streams use a lot of virtual
function calls and probably some dynamic memory allocation, so no wonder
they are slower than atoi() which has none of that. But this is still
only a constant factor like 2-3, which means the same algorithmic
complexity, so one cannot just say C++ streams are useless. They are just
designed for another task. And factors like 2-3 only come into play in
the code branches where the program spends a significant fraction of its
run time.

hth
Paavo

[Jorgen Grahn]

On Thu, 2013-11-21, crea wrote:
...

> I guess mostly they do not like it. And surely they have a point. But
> myself, I would not be so strict myself in my own coding that "everything
> must be C++ if its possible" especially if the C version is faster or better
> some other way. LIke somebody mentioned atoi is faster than strstream
> version (and this is what i also noticed with the stream in my code).

Prefer strtol() and related functions; unlike atoi() they can
detect parse errors.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[crea]

"Drew Lawson" <dr...@furrfu.invalid> wrote in message
news:l6l8ca$2u5l$2...@raid.furrfu.com...

> In article <gXlju.77200$Xe4....@fx34.am4>
> "crea" <n...@com.notvalid> writes:
>
> What this comes down to, and many of the answers are brushing
> against, is that you are not asking about the C++ language. You
> are asking about (for lack of a better term) "C++ culture."

Ye

>
> The problem there is that "C++ culture" is not a single thing.
> Different projects, different groups, etc. have different preferences.
>
> Last job, I worked with a guy who tried to put in every boost feature
> that he could.

:)

Most of the rest of the team stuck with mostly
> non-boost solutions. Both are valid ways, but this didn't make for
> a good fit.

Ye, I guess there should be some agreement how things are done and not
everybody doing their own way.
The culture in a software company where I was, was that everybody was really
just doing their own thing. Like is doing C++ projects and one person coding
using only C style but other using C++ and classes. There is gonna be
problems at some point when combining the codes.

>
> Without knowing the local culture, you can't predict the preferences.
> What you *can* do is talk about what you are doing. When you put
> in something that could go either way, talk around which you chose

> -- "Foo items[2]; -- that could be a vector, but there are only two
> that you toggle between . . . ."

Ye. Even here there could be an argument though to use vector instead. Both
could be ok...but ye, its a matter of discussion and people who understand
how to code correctly. People who do not understand correct way of coding
can confuse the group though. I dont think so much about how much everybody
can do how they like but rather how it blends with the whole group as its a
group efford anyway.

> I once had a code test for a C job. One of the problems was reversing
> the order of the bits in the input. I wrote my solution, talking
> it through while writing, finishing up with, "and [brief pause] it
> is the same as the input." I had one of the operations (or one of
> the loops, been a while) backwards. The important thing was that
> I caught it and understood why it was wrong.
>
> I got the job.

Ye, sure thats not a big issue.

[crea]

"Jorgen Grahn" <grahn...@snipabacken.se> wrote in message
news:slrnl8t5tu.h...@frailea.sa.invalid...

> On Thu, 2013-11-21, crea wrote:
> ...
>
>> I guess mostly they do not like it. And surely they have a point. But
>> myself, I would not be so strict myself in my own coding that "everything
>> must be C++ if its possible" especially if the C version is faster or
>> better
>> some other way. LIke somebody mentioned atoi is faster than strstream
>> version (and this is what i also noticed with the stream in my code).
>
> Prefer strtol() and related functions; unlike atoi() they can
> detect parse errors.
>

ok, but still point being that we would use C-function rather than C++ one.

[crea]

"Victor Bazarov" <v.ba...@comcast.invalid> wrote in message

news:l6lc71$231$1...@dont-email.me...

> On 11/21/2013 3:15 AM, crea wrote:
>> "Victor Bazarov" <v.ba...@comcast.invalid> wrote in message
>> news:l6iokg$550$1...@dont-email.me...
>>> On 11/20/2013 2:52 AM, crea wrote:
>>>> [..] In the example it was mixed though, so it
>>>> could be said its c++?
>>>
>>> Following the same logic, any program that can be successfully compiled
>>> with a C++ compiler, *is* a C++ program. Technically speaking.
>>
>> Technically yes, but ideally we could maybe call a pure C-code (a code
>> that
>> compiles on a C compiler) a C-code even if its compiled using a C++
>> compiler.
>
> <shrug> Call it whatever you like.

ye -ah, but... the problem comes when you try to ask somebody else to make a
"C++ code" and you expect them to understand it the same way as you
undertand. Then there could be confusion. Like Peter says: "Pls make a C++
code for this." Then John writes:

int coord[2];
...

Then there is an argument was this C or C++. Peter might say "no, I asked
you to make a *C++* program, not old C style. So why you put C arrays?" :)

If everybody thinks they are right, then might come collisions. So a general
definition of this would help here.

>
> A C++ program is one that compiles using a C++ compiler. A C program is
> one that compiles using a C compiler. Can the same sequence of characters
> be both? Yes. Is there any use of arguing that such a sequence of
> characters (that is both a C and a C++ program) is *not* a C++ program but
> somehow *only a C program*? I don't think so.
>

> In *your* world, however, you may adopt any axioms you like (any axioms
> that suit you) and say that "object that is both A and B we shall call B
> and not A." It's your world and your prerogative.

It depends... if this in maths, there are clear rules there. In this case
for example math definitions clearly say that object is both A and B.

In math it would be:
x=1 , y=1
Then if z = x then z is also: z=y. (and no mathematician would say that we
cannot say z is also y, because it is)
Math defines these things, so there is no question about it.

[crea]

"Drew Lawson" <dr...@furrfu.invalid> wrote in message

news:l6l9sb$2vpg$1...@raid.furrfu.com...

> In article <9blju.115250$qC.2...@fx07.am4>
> "crea" <n...@com.notvalid> writes:
>>
>>"Juha Nieminen" <nos...@thanks.invalid> wrote in message
>>news:l6klk0$1ir8$1...@adenine.netfront.net...
>
>>> If you can (safely) use std::atoi(), then it's faster than the
>>> equivalent
>>> code using std::stringstream.
>>
>>I actually just did both of them, and yes seems like this is true.
>>stringstream method seemed to be much slower. Donno why....
>>There is no fast way of doing atoi in C++?
>
> stringstream is slower because it does more. It is a general tool.
> atoi() is a very specific thing that only needs to check if it still
> has digits. (Also, there is a reasonable chance that atoi() is
> written in assembly.)
>
> However, you seem to have too much focus on speed. Unless you are
> doing something like real-time transaction processing, you are
> unlikely to see the difference in speed.

But there is a big difference just to wait for a loop of 1000000 item doing
slow stream version versus atoi doing it very fast. Its a mattare of waiting
like 10 second more eatch time you run the app. Even as a programmer I do
not want to wait 10 seconds more if I do not need to. But if its a matter of
waitin 0.1 seconds, then its ok.

>
>>This is the problem: you never know which C function is faster that
>>corresponding C++ version. So you have to time it yourself or just know
>>it.
>>But there are thousands of functions, so how can you remember how fast
>>earch
>>of them are?
>
> Unless you have extreme requirements, just trust that standard
> library calls (either C or C++) are fast enough. If you run into
> things being too slow, it is much more likely that the problem is
> in your application.

ye, i normally do. Although I was doing some binary calculations once using
std::bitset. And I was really assuming it must be fast as there is no reason
why not. But when I tested it against raw C bit functions, it seemed to be
significantly slower, at least what I was doing (using larger bitsets).
Donno... maybe I did something wrong, but seemed like even an obvious things
was not fast.

It was a big issues here, as there was very heavy bitset usage: infinite
loop using bitset all the time. So even a small slowness will matter.

>
> If you *do* have extreme requirements, you probably already have
> enough experience to avoid time consuming operations in critical
> places. (If not, you'll get experience quickly.)

ye I guess then better just time eatch method and see....

[crea]

"Paavo Helde" <myfir...@osa.pri.ee> wrote in message
news:XnsA280C1C5FA70my...@216.196.109.131...

> "crea" <n...@com.notvalid> wrote in news:9blju.115250$qC.2...@fx07.am4:
>
>>> Many other examples as well where C++ is faster. Like in some
>> situations where you check the type and do calculations according to
>> that in C++ and C does not do the same so its slower. Sometimes C uses
>> void* types to do calculations, when C++ knows the type and thus can
>> use a special very fast methods to proceed.
>
>
> This is not related to types, but to templates and inlining instead. In
> principle you could use void* in C++ too and do manual casting where
> needed, if the thing gets inlined it's as fast as type-safe code
> (static_cast<> is a null-op at run time). Such a void* approach has
> sometimes been used in C++ to reduce the so-called "template bloat", but
> nowadays compilers do this automatically.
>
>> Also sometimes in vectors etc its faster to do a memcopy instead of
>> copying eatch element one by one like C functions are doing. So C++ is
>> checking if there is a faster method and proceeds according to that.
>
> Does not follow, I'm sure C compilers recognize loops which can be
> replaced with optimized memcpy, or vice versa.

ok, but even then it would be trusting compilers and not language/code.
Thats different. Its different if its coded in the code or if we are hoping
the compiler will help here. If its in the code, then its guaranteed to work
as expected.

>
>>
>>>
>>> If you can (safely) use std::atoi(), then it's faster than the
>>> equivalent code using std::stringstream.
>
> Sure.
>
>>
>> I actually just did both of them, and yes seems like this is true.
>> stringstream method seemed to be much slower. Donno why....
>> There is no fast way of doing atoi in C++?
>
> The "fast" is very relative. If you are parsing user-typed input or
> otherwise a small number of numbers (like thousands), then stringstream
> is most probably ok. Only if there are millions of numbers in tight
> loops, then the parsing speed might become critical and one may need to
> convolute the code by using atoi() (or probably the more manageable
> variants strtol(), strtoul()).

The issue here was converting string to an integer.

>
> There is also a handy boost::lexical_cast feature which is effectively
> wrapping stringstream.

When i get time, I have to start looking this boost at some point...never
touched it :).
I would first though like to learn all the features in C++11 language, as
even understanding it can give major speed increments.

>
>> This is the problem: you never know which C function is faster that
>> corresponding C++ version. So you have to time it yourself or just
>> know it. But there are thousands of functions, so how can you remember
>> how fast earch of them are?
>
> Experience helps a bit, but in reality you never know exactly how fast
> something exactly is, as the hardware is constantly changing. The point
> is to express your algorithm in the clearest and concise way you can
> find, getting the algorithmic big-O complexities right and only worry if
> something appears too slow in the end. And in that case one should start
> with profiling an actual realistic usage case which is too slow, and
> start with optimizing that.

ye. In many programs (like graphical programs) I have done this normally
always happens though, that it is slow in something. So this happens often
that more speed is needed. Then needs to do as you said.

>
> Of course there are some rough guidelines like that dynamic memory
> allocation and frequent virtual function calls are slow, dynamic_cast is
> slower, and exception throwing is very slow.

I would like to have a book actually which in detail explains everything,
which one is slow and what is faster way to do it. I mean like a 1000 page
"optimization" book. But using easy language like you just did here. but
then examples maybe showing the point.

I recently noticed that ++i is faster than i++ (from the C++ book :) ), so
i changed my coding.. now I always use ++i if possible. Why not?

Maybe the language name should also be better as: ++C ... lol That would
illustrate that we need to use better options.

Arithmetics is fast and
> memory access beyond cpu caches is slow. C++ streams use a lot of virtual
> function calls and probably some dynamic memory allocation, so no wonder
> they are slower than atoi() which has none of that. But this is still
> only a constant factor like 2-3, which means the same algorithmic
> complexity, so one cannot just say C++ streams are useless. They are just
> designed for another task. And factors like 2-3 only come into play in
> the code branches where the program spends a significant fraction of its
> run time.

ye true, streams have their place, but not in heavy duty.

[Paavo Helde]

"crea" <n...@com.notvalid> wrote in news:ToEju.79788$v_6....@fx20.am4:

>
> "Paavo Helde" <myfir...@osa.pri.ee> wrote in message
> news:XnsA280C1C5FA70my...@216.196.109.131...
>> "crea" <n...@com.notvalid> wrote in
>> news:9blju.115250$qC.2...@fx07.am4:
>>

>>> I actually just did both of them, and yes seems like this is true.
>>> stringstream method seemed to be much slower. Donno why....
>>> There is no fast way of doing atoi in C++?
>>
>> The "fast" is very relative. If you are parsing user-typed input or
>> otherwise a small number of numbers (like thousands), then
>> stringstream is most probably ok. Only if there are millions of
>> numbers in tight loops, then the parsing speed might become critical
>> and one may need to convolute the code by using atoi() (or probably
>> the more manageable variants strtol(), strtoul()).
>
> The issue here was converting string to an integer.

Yes, that's what strtol() and cousins are doing. With atoi() one would
often have to scan the input twice, to validate it or to find the next
token start, strtol() is doing the same in one go.

Cheers
Paavo

[peter koch]

Den fredag den 22. november 2013 00.11.25 UTC+1 skrev Paavo Helde:
>
> There is also a handy boost::lexical_cast feature which is effectively
> wrapping stringstream.
>

That is only partially true. Some of the specialisations skip the iostream. So for string(or char*) => int conversions you would probably want to use boost if you want speed.

/Peter

[Öö Tiib]

On Friday, 22 November 2013 10:01:59 UTC+2, crea wrote:
> "Drew Lawson" <dr...@furrfu.invalid> wrote in message

> > However, you seem to have too much focus on speed. Unless you are
> > doing something like real-time transaction processing, you are
> > unlikely to see the difference in speed.
>
> But there is a big difference just to wait for a loop of 1000000 item doing
> slow stream version versus atoi doing it very fast. Its a mattare of waiting
> like 10 second more eatch time you run the app. Even as a programmer I do
> not want to wait 10 seconds more if I do not need to. But if its a matter of
> waitin 0.1 seconds, then its ok.

Focus on speed is correct C++ attitude but search for silver bullet is not
correct. Let me try to explain ...

When you are reading-writing tens or hundreds of items (typical case) then
you use the streams with some JSON or XML parser or the like. Speed of
implementing it matters and more than two hours is clearly wasteful.

When you are reading-writing billions of items then performance of product
matters more. You use or create special protocol (likely with compression)
and write and optimise special high speed parsers for the protocol. Weeks
of implementing can be good investment.

When it is unclear what case of the two above it is then you ask. If there are
billions of numbers as text then you also ask who The Idiot designed that
protocol. Do not worry, if the interviewer gets offended by that question
then you do not want to work in that company anyway.

...

> It was a big issues here, as there was very heavy bitset usage: infinite
> loop using bitset all the time. So even a small slowness will matter.

The requirements change and data initially assumed to be few hundred
bytes may grow to megabytes. Then you change the program. You do
not write programs onto rock. You commit code into revision control
system. You change code a lot. You draw it onto sand. Clarity and
maintainability of that "drawing" matters lot more than
micro-performance of the program.

[Juha Nieminen]

crea <n...@com.notvalid> wrote:
> ok, but still point being that we would use C-function rather than C++ one.

Calling it a "C-function" is a bit misleading.

Since said function is specified in the C++ standard, that makes it a
100% C++ standard function. Yes, it's the exact same function as
specified in the C standard (and many/most C++ compilers will even use
the exact same binary implementation when compiling in both modes),
but since it's a function defined in the C++ standard, that technically
speaking makes it also a C++ function.

There's nothing wrong in using a function defined in the standard.
If someone tells to you "you should be using the C++ version of that
function", you can simply answer them "but I *am* using the C++ version
of the function; it's right there, clearly defined in the C++ standard."

If you want to use std::atoi() or std::strtol(), go right ahead. There's
nothing wrong with them. As long as you know how to use them safely,
I see absolutely no problem.

[Juha Nieminen]

crea <n...@com.notvalid> wrote:
> There is no fast way of doing atoi in C++?

std::atoi() *is* C++. It's defined right there in the C++ standard.

(Just because the same function is also defined in the C standard doesn't
somehow make it "less C++". It's no different than eg. 'int' being somehow
"less C++" just because the C standard also defines it in the same way.)

> This is the problem: you never know which C function is faster that
> corresponding C++ version. So you have to time it yourself or just know it.
> But there are thousands of functions, so how can you remember how fast earch
> of them are?

Usually you can deduce which is faster by knowing what they do internally.
You know what they do internally with experience.

[Victor Bazarov]

On 11/22/2013 2:51 AM, crea wrote:
> "Victor Bazarov" <v.ba...@comcast.invalid> wrote in message

>> [..]

>> <shrug> Call it whatever you like.
>
> ye -ah, but... the problem comes when you try to ask somebody else to make a
> "C++ code" and you expect them to understand it the same way as you

> undertand. Then there could be confusion. [..]

In order for "them to understand it the same way as you", you and "they"
need to agree, make what's known as "a convention" (comes from the word
'conventio', meaning "in the same place"). Without it you cannot
communicate effectively.

Making a convention (coming to the same place) is a process. When
"they" don't complete the task (don't reach the goal you set for them),
it most likely means that you didn't specify the goal correctly. So,
you evaluate the result *together* and come up with a better
understanding of what the goals are, what is expected as the result. By
doing that you get closer to each other, come to the "same place" (or,
in modern business lingo, "get on the same page").

Good luck!

[Paavo Helde]

"crea" <n...@com.notvalid> wrote in news:o2Eju.131971$gs7....@fx16.am4:

> ye -ah, but... the problem comes when you try to ask somebody else to
> make a "C++ code" and you expect them to understand it the same way as
> you undertand. Then there could be confusion. Like Peter says: "Pls
> make a C++ code for this." Then John writes:
>
> int coord[2];
> ...
>
> Then there is an argument was this C or C++. Peter might say "no, I
> asked you to make a *C++* program, not old C style. So why you put C
> arrays?" :)

This is a terminology argument, not a technical one. int coord[2] can no
doubt appear in a valid C++ program. Now if Peter talked about well-
designed C++ program, or a well-designed C++11 program, the things might
become different. If Peter talked about performance-critical well-designed
C++ program, or performance-critical well-designed C++11 program, the
things might change again.

Cheers
Paavo

[Jouko Koski]

"Jorgen Grahn" wrote:
> Prefer strtol() and related functions; unlike atoi() they can
> detect parse errors.

C++11:
int stoi(const string& str, size_t *idx = 0, int base = 10);

--
Jouko

[Jorgen Grahn]

Good -- although I would have preferred a templated one which worked
on [begin, end) pairs. (Perhaps there is one; I am too lazy to check.)

[woodb...@gmail.com]

On Friday, November 22, 2013 4:31:56 AM UTC-6, Öö Tiib wrote:
>
>
> When you are reading-writing tens or hundreds of items (typical case) then
> you use the streams with some JSON or XML parser or the like. Speed of
> implementing it matters and more than two hours is clearly wasteful.
>

I think there are some games that fit your description,
but they use binary. They have some frequency with which
the tens/hundreds of items are sent and if game is popular,
the server has to support thousands of simultaneous users.



[ snip ]

>
>
> When it is unclear what case of the two above it is then you ask. If there are
> billions of numbers as text then you also ask who The Idiot designed that
> protocol.
>

It might be the user of the protocol has made a poor choice.


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

[Jorgen Grahn]

On Fri, 2013-11-22, �� Tiib wrote:
> On Friday, 22 November 2013 10:01:59 UTC+2, crea wrote:
>> "Drew Lawson" <dr...@furrfu.invalid> wrote in message
>> > However, you seem to have too much focus on speed. Unless you are
>> > doing something like real-time transaction processing, you are
>> > unlikely to see the difference in speed.
>>
>> But there is a big difference just to wait for a loop of 1000000 item doing
>> slow stream version versus atoi doing it very fast. Its a mattare of waiting
>> like 10 second more eatch time you run the app. Even as a programmer I do
>> not want to wait 10 seconds more if I do not need to. But if its a matter of
>> waitin 0.1 seconds, then its ok.
>
> Focus on speed is correct C++ attitude

Yes, up to a point.

> but search for silver bullet is not correct.
> Let me try to explain ...

Yes! The main problem with crea's postings in this thread is IMHO
he's searching for a common pattern or a single Golden Rule.

I see that as a beginner's mistake. I've certainly done a lot of it
myself over the years. The dogmas eventually get replaced with
experience: you still don't know what the /best/ way to do FOO is, but
you know one or two decent ways to do FOO.

> When you are reading-writing tens or hundreds of items (typical case) then
> you use the streams with some JSON or XML parser or the like. Speed of
> implementing it matters and more than two hours is clearly wasteful.

Minor complaint: depends on what area you work in. I tend to write my
text data formats from scratch, especially when I want them to be
conveniently editable or when I want them to double as a commandline
(i.e. people will sit and type interactively).

But what you say applies: it's not hard to write a parser, and it will
probably be fast enough no matter how you do it. I/O is usually the
bottleneck.

> When you are reading-writing billions of items then performance of product
> matters more. You use or create special protocol (likely with compression)
> and write and optimise special high speed parsers for the protocol. Weeks
> of implementing can be good investment.

...

> The requirements change and data initially assumed to be few hundred
> bytes may grow to megabytes. Then you change the program. You do
> not write programs onto rock. You commit code into revision control
> system. You change code a lot. You draw it onto sand. Clarity and
> maintainability of that "drawing" matters lot more than
> micro-performance of the program.

[crea]

"Juha Nieminen" <nos...@thanks.invalid> wrote in message

news:l6nc6k$161g$1...@adenine.netfront.net...

> crea <n...@com.notvalid> wrote:
>> ok, but still point being that we would use C-function rather than C++
>> one.
>
> Calling it a "C-function" is a bit misleading.
>
> Since said function is specified in the C++ standard, that makes it a
> 100% C++ standard function. Yes, it's the exact same function as
> specified in the C standard (and many/most C++ compilers will even use
> the exact same binary implementation when compiling in both modes),
> but since it's a function defined in the C++ standard, that technically
> speaking makes it also a C++ function.

ye agree. Although sometimes in school they might want to use some
class-system to do it more "elegantly".

[crea]

"Jouko Koski" <joukokos...@netti.fi> wrote in message
news:0YMju.11197$t02....@uutiset.elisa.fi...

oh, ok. Still solves all the problems.. :)

[crea]

"�� Tiib" <oot...@hot.ee> wrote in message
news:1635f2a7-4fca-41e7...@googlegroups.com...

>
> When it is unclear what case of the two above it is then you ask. If there
> are
> billions of numbers as text then you also ask who The Idiot designed that
> protocol. Do not worry, if the interviewer gets offended by that question
> then you do not want to work in that company anyway.

Ye, i kind of agree. Although it might still be good to get that job, even
if you need to please them?? :)
Maybe you could in that situation say what they want to hear. Maybe in real
work people are different...

[Öö Tiib]

On Friday, 22 November 2013 20:40:36 UTC+2, woodb...@gmail.com wrote:
> On Friday, November 22, 2013 4:31:56 AM UTC-6, Öö Tiib wrote:
> >
> >
> > When you are reading-writing tens or hundreds of items (typical case) then
> > you use the streams with some JSON or XML parser or the like. Speed of
> > implementing it matters and more than two hours is clearly wasteful.
>
> I think there are some games that fit your description,
> but they use binary. They have some frequency with which
> the tens/hundreds of items are sent and if game is popular,
> the server has to support thousands of simultaneous users.

Sure because it reduces throughput need to your server park
about 4 times. However you need scalable architecture of that
service lot more because what if there will be 100 000 users.
You need to add more servers.

> > When it is unclear what case of the two above it is then you ask.
> > If there are billions of numbers as text then you also ask who The
> > Idiot designed that protocol.
>
> It might be the user of the protocol has made a poor choice.

Yes, everybody make mistakes. The inability to recognize
and correct mistakes indicates idiocy.

[woodb...@gmail.com]

On Saturday, November 23, 2013 6:51:04 PM UTC-6, Öö Tiib wrote:
> On Friday, 22 November 2013 20:40:36 UTC+2, woodb...@gmail.com wrote:
>
> > I think there are some games that fit your description,
> > but they use binary. They have some frequency with which
> > the tens/hundreds of items are sent and if game is popular,
> > the server has to support thousands of simultaneous users.
>
> Sure because it reduces throughput need to your server park
> about 4 times. However you need scalable architecture of that
> service lot more because what if there will be 100 000 users.
> You need to add more servers.
>

I don't understand your point in your second sentence.
Are you saying binary isn't as scalable?

[Öö Tiib]

No. We have limited amount of effort we can invest into our doings.
We can chose where the effort gives best effects.

When game becomes popular then amount of simultaneous connections
grows. The players start to complain about annoying "lag" sooner or
later. The game providers react by adding more servers.

There is always some point where verbose protocol and scalable
architecture give better result than laconic protocol and
non-scalable architecture. Also it is usually simpler to replace
protocol than to fix wasteful architecture.

Therefore it is better to put more effort into scalability of the
very service itself than into smallness of messages of protocol
when designing such games.

[Öö Tiib]

On Saturday, 23 November 2013 11:42:17 UTC+2, Jorgen Grahn wrote:

> On Fri, 2013-11-22, �� Tiib wrote:
> > When you are reading-writing tens or hundreds of items (typical case) then
> > you use the streams with some JSON or XML parser or the like. Speed of
> > implementing it matters and more than two hours is clearly wasteful.
>
> Minor complaint: depends on what area you work in. I tend to write my
> text data formats from scratch, especially when I want them to be
> conveniently editable or when I want them to double as a commandline
> (i.e. people will sit and type interactively).

JSON is pretty conveniently editable. Just like with JSON or XML there
are some stock parsers for other text formats CSV, INI or command
line switches. I have worked in (bit too) several areas over the years.
I thought that command line UIs are now mostly used for (unit)
testing and scripting; typically they want some gesture-based graphical
UIs. What area it is that relies heavily on command line UIs?

[Ian Collins]

Jorgen Grahn wrote:
> On Fri, 2013-11-22, �� Tiib wrote:
>
>> When you are reading-writing tens or hundreds of items (typical case) then
>> you use the streams with some JSON or XML parser or the like. Speed of
>> implementing it matters and more than two hours is clearly wasteful.
>
> Minor complaint: depends on what area you work in. I tend to write my
> text data formats from scratch, especially when I want them to be
> conveniently editable or when I want them to double as a commandline
> (i.e. people will sit and type interactively).

JSON is a good fit then. My stock command line option parser accepts
both regular option switches or the options expressed as JSON (file name
or blob).

--
Ian Collins

[Jorgen Grahn]

On Sun, 2013-11-24, �� Tiib wrote:
> On Saturday, 23 November 2013 11:42:17 UTC+2, Jorgen Grahn wrote:

>> On Fri, 2013-11-22, �� Tiib wrote:
>> > When you are reading-writing tens or hundreds of items (typical case) then
>> > you use the streams with some JSON or XML parser or the like. Speed of
>> > implementing it matters and more than two hours is clearly wasteful.
>>
>> Minor complaint: depends on what area you work in. I tend to write my
>> text data formats from scratch, especially when I want them to be
>> conveniently editable or when I want them to double as a commandline
>> (i.e. people will sit and type interactively).
>
> JSON is pretty conveniently editable.

(Checks Wikipedia). Yes, it seems reasonably ok (much better than
XML, or ASN.1 BER, or ...) but I normally don't need the burden of a
language with structs. A series of "name=value" lines is almost always
enough. Or sometimes "command argument ...".

> Just like with JSON or XML there
> are some stock parsers for other text formats CSV, INI or command
> line switches. I have worked in (bit too) several areas over the years.
> I thought that command line UIs are now mostly used for (unit)
> testing and scripting; typically they want some gesture-based graphical
> UIs. What area it is that relies heavily on command line UIs?

Traditional Unix, from sysadmin tasks and data analysis to networking
protocols. I almost always want to be able to automate things, or
parse data with simple Perl-one liners, and/or feed it to gnuplot ...
I guess that falls under "scripting" above.

My views are similar to Eric Raymond's here:
http://www.catb.org/esr/writings/taoup/html/textualitychapter.html

[Alf P. Steinbach]

On 26.11.2013 19:55, Jorgen Grahn wrote:
> On Sun, 2013-11-24, �� Tiib wrote:
>>
>> JSON is pretty conveniently editable.
>
> (Checks Wikipedia). Yes, it seems reasonably ok (much better than
> XML, or ASN.1 BER, or ...) but I normally don't need the burden of a
> language with structs. A series of "name=value" lines is almost always
> enough. Or sometimes "command argument ...".

Well this is getting pretty off-topic, but as opposed to name=value
lines JSON can represent just about any hierarchical data. I.e. it's as
powerful as you get. And like name=value lines it's easy enough to write
and to check manually, so IMHO it's a good candidate for

... one logic to parse them all,

e.g. look at this example:
(http://stackoverflow.com/questions/12394472/serializing-and-deserializing-json-with-boost).

The promise of XML was once that we would be able to apply all the
existing SGML tools and machinery, which advantage would more than
compensate for the complexity. What? Haven't seen any of that? Well
neither have I. But then I haven't really delved into JSON either, so
maybe there's something smelly-for-poking-nose also in there somewhere?


Cheers,

- Alf (wondering, could it be "peeking nose", or is that just eyes?)

[J. Clarke]

In article <slrnl99rkk.h...@frailea.sa.invalid>,
grahn...@snipabacken.se says...

>
> On Sun, 2013-11-24, ￜￜ Tiib wrote:
> > On Saturday, 23 November 2013 11:42:17 UTC+2, Jorgen Grahn wrote:

> >> On Fri, 2013-11-22, ￜ?ￜ? Tiib wrote:
> >> > When you are reading-writing tens or hundreds of items (typical case) then
> >> > you use the streams with some JSON or XML parser or the like. Speed of
> >> > implementing it matters and more than two hours is clearly wasteful.
> >>
> >> Minor complaint: depends on what area you work in. I tend to write my
> >> text data formats from scratch, especially when I want them to be
> >> conveniently editable or when I want them to double as a commandline
> >> (i.e. people will sit and type interactively).
> >
> > JSON is pretty conveniently editable.
>
> (Checks Wikipedia). Yes, it seems reasonably ok (much better than
> XML, or ASN.1 BER, or ...) but I normally don't need the burden of a
> language with structs. A series of "name=value" lines is almost always
> enough. Or sometimes "command argument ...".
>
> > Just like with JSON or XML there
> > are some stock parsers for other text formats CSV, INI or command
> > line switches. I have worked in (bit too) several areas over the years.
> > I thought that command line UIs are now mostly used for (unit)
> > testing and scripting; typically they want some gesture-based graphical
> > UIs. What area it is that relies heavily on command line UIs?
>
> Traditional Unix, from sysadmin tasks and data analysis to networking
> protocols. I almost always want to be able to automate things, or
> parse data with simple Perl-one liners, and/or feed it to gnuplot ...
> I guess that falls under "scripting" above.

Just an aside, but Microsoft is also moving back in the direction of a
command line UI for server and network administration. The recommended
install for Server 2012 is "server core" which does not include the GUI
and is to be administered through the Powershell, and much of the
current go-around of MCSE training is how to run things using
Powershell.

[Ian Collins]

Alf P. Steinbach wrote:
> On 26.11.2013 19:55, Jorgen Grahn wrote:
>> On Sun, 2013-11-24, �� Tiib wrote:
>>>
>>> JSON is pretty conveniently editable.
>>
>> (Checks Wikipedia). Yes, it seems reasonably ok (much better than
>> XML, or ASN.1 BER, or ...) but I normally don't need the burden of a
>> language with structs. A series of "name=value" lines is almost always
>> enough. Or sometimes "command argument ...".
>
> Well this is getting pretty off-topic, but as opposed to name=value
> lines JSON can represent just about any hierarchical data. I.e. it's as
> powerful as you get. And like name=value lines it's easy enough to write
> and to check manually, so IMHO it's a good candidate for
>
> ... one logic to parse them all,

:)

The OS I spend most of my time developing for (SmartOS) uses JSON (and
node.js) extensively. It makes integration with web tools very easy.

> The promise of XML was once that we would be able to apply all the
> existing SGML tools and machinery, which advantage would more than
> compensate for the complexity. What? Haven't seen any of that? Well
> neither have I. But then I haven't really delved into JSON either, so
> maybe there's something smelly-for-poking-nose also in there somewhere?

I get the impression (from the number of tools written in it) Java
embraced XML more enthusiastically.

XML still has its place (where it began, in document markup). It
certainly makes working with (Open)Office documents a lot easier than
the older binary formats. My favorite XML editor is LibreOffice.

My rule of thumb is if it's going to published or used as project
documentation, use XML. If not, use JSON.

--
Ian Collins