Why use C++?

[Miro]

I've made the title too provocative. What I mean is, why use C++ for
small ( > 1000 lines ) coding jobs?
It doesn't make much sense to me as...

C++ syntax requires a lot more typing, debugging and memory,
Compilation time can be irksome,
C++ is devoid of the plethora of features you find on Python, Ruby or
our dear Swiss Army Chainsaw.

Don't get me wrong, I don't dislike C++, nor am I trying to rile up
the great gurus among us, however, I fail to see a practical reason to
use this language much as I go about my hacking life.
I understand that it compiles directly into binary and can be from
there run without an interpreter, but that seems a small price to pay
for a five line ( in good practice ) hello world.

Miro

 

[Jens Thoms Toerring]

I've made the title too provocative. What I mean is, why use C++ for
small ( > 1000 lines ) coding jobs?

I guess you meant "< 1000 lines"...

It doesn't make much sense to me as...

C++ syntax requires a lot more typing, debugging and memory,

C++ syntax doesn't need memory, and debugging only required if
you made mistakes (which is not so much different from a script
written in an interpreted language, I think).

Compilation time can be irksome,
C++ is devoid of the plethora of features you find on Python, Ruby or
our dear Swiss Army Chainsaw.

Don't get me wrong, I don't dislike C++, nor am I trying to rile up
the great gurus among us, however, I fail to see a practical reason to
use this language much as I go about my hacking life.
I understand that it compiles directly into binary and can be from
there run without an interpreter, but that seems a small price to pay
for a five line ( in good practice ) hello world.

Well, you can have a "hello world" program in two-to-five lines
of C++, depending on the way you lay-out things;-) And if all
you do is writing "hello world" programs then it is rather ir-
relevant which language you use.

Otherwuse your question is comparing apples to bananas. In
many cases load and compilation/interpretation times aren't
of much concern. Then use the language you feel most at home
with to get the job done and which is most expressive (i.e.
that requires the least typing and gives you the least chance
of making mistakes - like I would not dream of writing a C++
program when I have to e.g. convert the format of a few data
file when it can be done in Perl or sed or something similar
I am familiar with in a one-liner).

On the other hand some programs that need to be run very often
can be a lot faster when written in a compiled language since
the overhead of starting the interpreter and having it inter-
pret the script tends to be a lot higher than starting a short
compiled program (even if the actual task requires only a rather
small number of lines of code). I often start by writing such
things in an interpreted language I know well enough but when
I find that they are becoming a bottleneck I rewrite them in
C or C++.

Then there are programs that require all the speed you can squeeze
out of your machine or that need all the memory available etc.
(and that is not necessarily directly related to number of lines
of code). Those are the ones I wouldn't consider writing in an
interpreted language (except perhaps for a proof-of-concept im-
plementation).

And, of course, there are also quite a number of cases where
the parts that really need to be fast and make the most effi-
cient use of memory can be written in a compiled language like
C++ and the other parts in an interpreted language. So there's
really no one-is-better-than-the-other but an (hopefully edu-
ctated) choice of what to use in a certain situation.

Regards, Jens

 

[SG]

I've made the title too provocative. What I mean is, why use C++ for
small ( > 1000 lines ) coding jobs?
It doesn't make much sense to me as...

C++ syntax requires a lot more typing, debugging and memory,
Compilation time can be irksome,
C++ is devoid of the plethora of features you find on Python, Ruby or
our dear Swiss Army Chainsaw.

Since I just recently wrote a small tool in C++ (around 300 lines of
code) that simply transforms one text-like file to another file, I'll
try to explain why I did this in C++:

- I know C++ well enough and appreciate the higher level
abstractions.
They make this sort of thing fairly easy to write. I don't think a
Python solution to this problem is significantly smaller in terms
of
source code size.
- I don't know any scripting language well enough to do the job,
although I was planning to get more accustomed to Python
eventually.
- I like static typing. I don't like assigning random sh*t to other
random sh*t and hoping that it all works out at runtime.
- C++ doesn't require you to install a VM or interpreter.

Cheers!
SG

 

[Krice]

I understand that it compiles directly into binary and can be from
there run without an interpreter, but that seems a small price

It's a big issue to me. Python is especially notorious for not
being backwards compatible so you need the specific version
installed to run a program. In the end you have loads of
python versions which take huge amount of disk space.

If there is a better language that compiles stand alone
programs and has better (easier) access to hardware like
file handling then please let me know.

 

[James Kanze]

On 6 Aug., 23:00, Miro wrote:

Since I just recently wrote a small tool in C++ (around 300 lines of
code) that simply transforms one text-like file to another file, I'll
try to explain why I did this in C++:

- I know C++ well enough and appreciate the higher level
abstractions.
They make this sort of thing fairly easy to write. I don't think a
Python solution to this problem is significantly smaller in terms
of
source code size.

I've yet to see anything that wouldn't be shorter in Python than
in C++. More significantly, it's generally easier to develop
iteratively in an interpreted language, simply because the
turn-around time is much, much shorter. And the "bad"
techniques, like just typing in code without having done any
design, don't really make such a difference in very small
programs. Historically, I've used AWK for anything up to about
500 lines; I've recently shifted to Python (mainly because
Python will be installed on all development machines, where as
there are only three or four of us who have AWK on our Windows
machines).

- I don't know any scripting language well enough to do the job,
although I was planning to get more accustomed to Python
eventually.
- I like static typing. I don't like assigning random sh*t to other
random sh*t and hoping that it all works out at runtime.

It's not a question of "liking": static typing saves you from
all kinds of problems once the program gets a bit bigger.

- C++ doesn't require you to install a VM or interpreter.

But it does require you to install a compiler on the machine you
develope on. (Until about two years ago, I worked
exclusively in Unix environments. A shell was always present,
with awk, sed, and the like. Which meant that scripts could be
used portably, without installing anything special.)

 

[Nick Keighley]

I've yet to see anything that wouldn't be shorter in Python than
in C++.

me too.

 More significantly, it's generally easier to develop
iteratively in an interpreted language, simply because the
turn-around time is much, much shorter.

I know this is like a cliche in software development; but is it
*actually* true. A 300 line program is going to take no time at all to
compile and running a Python interpreter up doesn't take no time at
all. Yes Basic beat COBOL hands down but I no longer have to be nice
to the key punch girls to get faster turn-around!

I've used Python and I lie it but I'm not convinced that interpreters
are that much quicker to develop with no matter how often they tell me
so. And C++ comes with a debugger...

 And the "bad"
techniques, like just typing in code without having done any
design, don't really make such a difference in very small
programs.

I still sort of desing I just don't write it down.

 Historically, I've used AWK for anything up to about
500 lines; I've recently shifted to Python (mainly because
Python will be installed on all development machines, where as
there are only three or four of us who have AWK on our Windows
machines).


It's not a question of "liking": static typing saves you from
all kinds of problems once the program gets a bit bigger.

not entirely convinced. I suppose with dynamic typing you have to make
sure all the code has executed so thre isn't some time bomb hiding in
your code. But your C++ code should have pretty thourogh test coverage
anyway.

 

[Nick Keighley]

It's a big issue to me. Python is especially notorious for not
being backwards compatible so you need the specific version
installed to run a program. In the end you have loads of
python versions which take huge amount of disk space.

If there is a better language that compiles stand alone
programs and has better (easier) access to hardware like
file handling then please let me know.

Chicken Scheme
(not a serious suggestion but it /does/ have both a compiler and an
interpreter and there are libraries to handle directories)

 

[Michael DOUBEZ]

It's a big issue to me. Python is especially notorious for not
being backwards compatible

Is it ? Except from the leap between 2.x to 3.x, I have not noticed
much compatibility issues provided you have the last version.

so you need the specific version
installed to run a program.

I think SG refers to py2exe which produces executable files (for MS)
that do not require python to be installed. I have made a few and,
although it produces BIG exe, it works quite well.

In the end you have loads of
python versions which take huge amount of disk space.

If there is a better language that compiles stand alone
programs and has better (easier) access to hardware like
file handling then please let me know.

The D programming language has a decent standard library regarding
this.
http://www.d-programming-language.org/phobos/std_file.html

 

[Dombo]

Op 23-Aug-11 10:47, Nick Keighley schreef:

me too.



I know this is like a cliche in software development; but is it
*actually* true. A 300 line program is going to take no time at all to
compile and running a Python interpreter up doesn't take no time at
all. Yes Basic beat COBOL hands down but I no longer have to be nice
to the key punch girls to get faster turn-around!

I've used Python and I lie it but I'm not convinced that interpreters
are that much quicker to develop with no matter how often they tell me
so.

My experience is that for little quick-and-dirty applications (for my
own use) Python is definitely quicker, even though I'm much more fluent
in C++ than Python. It is not only the language but also the quite
extensive library that comes with Python that makes me more productive.

And C++ comes with a debugger...

As does Python. In fact one can argue whether C++ 'comes' with a
debugger. There is nothing in the standard that mandates that.

I still sort of desing I just don't write it down.


not entirely convinced. I suppose with dynamic typing you have to make
sure all the code has executed so thre isn't some time bomb hiding in
your code. But your C++ code should have pretty thourogh test coverage
anyway.

Especially with dynamically typed languages it is not just about code
coverage, but about covering every possible execution flow which is much
harder to achieve. Simply having all lines of a function executed once
means just about nothing in a dynamically type language, you must have
executed all lines of the function with every combination of types of
variables the function might use to catch errors that a C++ compiler
would have caught during compile time.

The fact that with Python users must install Python first is a reason
for me not to use Python. The other one is that it is dynamically typed,
which is a good thing if you just want to throw things together quickly,
but a bad thing if you want things to be reliable. Once a Python script
gets beyond a couple of hundreds of lines, the lack of static typing
starts to bite.

 

[James Kanze]

[...]

And the "bad"
techniques, like just typing in code without having done any
design, don't really make such a difference in very small
programs.

I still sort of desing I just don't write it down.

You don't "know" something until you've written it down. It's
too easy to cut corners otherwise.

[...]

not entirely convinced. I suppose with dynamic typing you have to make
sure all the code has executed so thre isn't some time bomb hiding in
your code. But your C++ code should have pretty thourogh test coverage
anyway.

Static typing results in a compile time error on the exact line
where the error occurs. Dynamic typing requires running the
program. On large programs, that takes more time, and the
resulting error message is generally less precise (although I'll
admit that Python can give fairly good error messages in this
case). There's an old saying that every step you go through
until the error appears multiplies the cost by 10; an error
caught by the compiler is 10 times cheaper to fix than one
caught in unit tests (or 100, if you count linking as a separate
step). The factor has obviously been pulled out of thin air,
but there is something to the general principle: an error found
by the compiler is cheaper to fix than one found in code review,
or one found in unit tests.

Note that on very large projects, a type error in the interface
between subsystems may not show up until integration, and
resolving errors which first appear in integration can be very
expensive.

Most of my experience has been on large projects, in large
teams, and on systems which were more or less critical. All of
which argues in favor of very strict static typing. (IMHO, C++
isn't strict enough.) On the other hand, in all of these
projects, there's been a lot of support code---code and
documentation generators, verification programs, test suite
generators, etc.---and these have largely been written in the
Bourne shell, with intensive use of AWK.

 

[Noah Roberts]

Don't get me wrong, I don't dislike C++, nor am I trying to rile up
the great gurus among us, however, I fail to see a practical reason to
use this language much as I go about my hacking life.

Hackers should stay away from C++. They'll just hurt themselves. Let
the developers, engineers, and other adults do the C++. Stick to Perl
or something where what you're making isn't expected to be readable by
anyone anyway, including yourself in 3 days.

 

[Duga Chernobyl]

Hackers should stay away from C++. They'll just hurt themselves. Let
the developers, engineers, and other adults do the C++. Stick to Perl
or something where what you're making isn't expected to be readable by
anyone anyway, including yourself in 3 days.

For hackers is pure assembler ;-)

Anyway: c is structural, c++ is object oriented. You choose want you want.
C is not worse than c++. In c you can do as much as in c++. It is only
different way of thinking and programming. C - callbacks, C++
constructor/destructors ;-)

Assembler is procedural ;-) (but some compilers f.e. nasm supports
structures)

 

[Nobody]

What I noticed is that programming in Perl allows me to express
algorithms in a most pure and simple manner. You would think that a
language like C++ would be best for that kind of job. But it turns out
a good high-level scripting language with excelent support for basic
data structures is better.

The main advantage of such languages over C++ is garbage collection.

If you try to write "naive" code using complex data structures in C++, you
would end up either performing many deep copies or leaking memory.

 

[James Kanze]

Dnia 27-08-2011 o 21:38:55 Noah Roberts <[email protected]>
napisał(a):
[...]
Anyway: c is structural,

C is procedural (according to the usual definition).

c++ is object oriented.

C++ is a multipardigm language. It, too, is basically
procedural, but it has additional features to support OO or
generic programming.

Both C and C++ do allow a limited amount of functional
programming (e.g. using ?: and recursion), but extended
functional programming seems unnatural in either.

You choose want you want.
C is not worse than c++. In c you can do as much as in c++. It is only
different way of thinking and programming. C - callbacks, C++
constructor/destructors ;-)

The most important difference remains the existance of
public/private in C++. As a C programmer, you define a struct,
and a number of functions which manipulate the struct, and you
cross your fingers that no one accesses the members of the
struct other than through your functions. In C++, the compiler
enforces this---you don't have to cross your fingers.

 

[James Kanze]

The main advantage of such languages over C++ is garbage collection.

When appropriate, you can use garbage collection with C++.
(I've done so---it works quite well.) The main difference
between C++ and such languages is that C++ is value oriented;
most "objects" are copiable and assignable; will be local
variables; and don't need garbage collection.

If you try to write "naive" code using complex data structures
in C++, you would end up either performing many deep copies or
leaking memory.

You do end up with more deep copies. It's inherent in the
semantics. On the other hand, you don't get the sometimes
propagation of local changes. (For an example, see
java.awt.Dimension.) But at least in the code I've seen,
leaking memory generally hasn't been a problem; the real problem
which garbage collection solves (or rather, can solve, in C++)
is dangling references.

 

[Noah Roberts]

The most important difference remains the existance of
public/private in C++.  As a C programmer, you define a struct,
and a number of functions which manipulate the struct, and you
cross your fingers that no one accesses the members of the
struct other than through your functions.  In C++, the compiler
enforces this---you don't have to cross your fingers.

Actually, encapsulation is one of the easiest C++ features to
implement in C. You just declare a typedef to a non-defined struct,
which only has full definition inside of the c file that implements
its behavior. IE:

header.h:

typedef struct my_object MyObject;

MyObject* createMyObject();
void freeMyObject(MyObject* obj);

etc...

cfile.c

struct my_object
{
private members...
};

.... etc...

One can declare another struct of the same general shape and get
access to its insides, but you can do that to C++ too.

 

[Juha Nieminen]

Actually, encapsulation is one of the easiest C++ features to
implement in C. You just declare a typedef to a non-defined struct,
which only has full definition inside of the c file that implements
its behavior.

At the cost of increased memory usage and decreased performance.
(Allocating objects individually on the heap is significantly heavier
than allocating them on the stack. This heavyness is "inherited" by
any other type or data container that wants to use it.)

I always find it amusing when (some) C hackers believe the urban
legend that C++ is slower than C, yet time and again they demonstrate
how C results in the more inefficient code for the same functionality.

 

[Nick Keighley]

Op 23-Aug-11 10:47, Nick Keighley schreef:

I know this is like a cliche in software development; but is it
*actually* true. A 300 line program is going to take no time at all to
compile and running a Python interpreter up doesn't take no time at
all. Yes Basic beat COBOL hands down but I no longer have to be nice
to the key punch girls to get faster turn-around!

I've used Python and I [like] it but I'm not convinced that interpreters
are that much quicker to develop with no matter how often they tell me
so.

My experience is that for little quick-and-dirty applications (for my
own use) Python is definitely quicker, even though I'm much more fluent
in C++ than Python. It is not only the language but also the quite
extensive library that comes with Python that makes me more productive.

did you read what I wrote? I don't doubt python is quicker for many
q&d applications, particularly because of its extensive library. /But/
I'm not convinced that the INTERPRETATION makes the difference. I was
commenting on this "...it's generally easier to develop iteratively in
an interpreted language, simply because the turn-around time is much,
much shorter". Because I think this is accepted uncritically.

<snip>

[for using C++ over python]
another myth that's repeated more often than it's evidenced.

Especially with dynamically typed languages it is not just about code
coverage, but about covering every possible execution flow which is much
harder to achieve. Simply having all lines of a function executed once
means just about nothing in a dynamically type language, you must have
executed all lines of the function with every combination of types of
variables the function might use to catch errors that a C++ compiler
would have caught during compile time.

the Static Dynamic Wars make the War of The Ring look like tiddly
winks match.

The fact that with Python users must install Python first is a reason
for me not to use Python. The other one is that it is dynamically typed,
which is a good thing if you just want to throw things together quickly,
but a bad thing if you want things to be reliable. Once a Python script
gets beyond a couple of hundreds of lines, the lack of static typing
starts to bite.

INYHO

 

[Nick Keighley]

I still sort of [design] I just don't write it down.

You don't "know" something until you've written it down.  It's
too easy to cut corners otherwise.

The Source Code IS The Design!

http://www.developerdotstar.com/mag/articles/reeves_design.html

I was really talking about 300 line filters. I do think about their
structure but I don't draw a UML diagram or anything.

<snip>

 

[Nick Keighley]

For hackers is pure assembler ;-)

Anyway: c is structural, c++ is object oriented. You choose want you want..  
C is not worse than c++. In c you can do as much as in c++.

this is trivially true for any Turing Complete langauge. Since I can
write a C++ compiler in C any C++ can be written in C. So what?