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]

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?

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

The task says its less than 20 chars ...

 

[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?

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

The task says its less than 20 chars ...

 

[Jorgen Grahn]

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?

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

The task says its less than 20 chars ...

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

 

[Victor Bazarov]

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?

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

The task says its less than 20 chars ...

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

 

[Stefan Ram]

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.

 

[crea]

On 19/11/2013 21:44, crea 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?

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

The task says its less than 20 chars ...

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).
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]

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]

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...

 

[Victor Bazarov]

[..] 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.

V

 

[Victor Bazarov]

[..] 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.

V

 

[crea]

[..] 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]

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?

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.

 

[crea]

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]

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?

 

[Victor Bazarov]

[..] 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.

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.

V

 

[crea]

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]

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.

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]

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.


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.

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.

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.

 

[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