C and C++

[Victor Bazarov]

Ok what is it that's so much easier in C++ than C? It's been so long
since I've looked at C++ I can't remember much about it. Instead of free()
you can use delete if I remember right. You need a whole extra header
fstream in order to save to files. Is it worth the overhead in the binaries?
iostream is a big library.

Pick up a decent C++ book and give it a good read. And stop trolling.

V

 

[Bill Cunningham]

Ok what is it that's so much easier in C++ than C? It's been so long
since I've looked at C++ I can't remember much about it. Instead of free()
you can use delete if I remember right. You need a whole extra header
fstream in order to save to files. Is it worth the overhead in the binaries?
iostream is a big library.

Bill

 

[Barry Schwarz]

Ok what is it that's so much easier in C++ than C? It's been so long

Given the problems you have demonstrated with C, it is unlikely that
C++ holds any advantage for you.

since I've looked at C++ I can't remember much about it. Instead of free()
you can use delete if I remember right. You need a whole extra header

You remember wrong.

fstream in order to save to files. Is it worth the overhead in the binaries?

Wrong again. Besides, headers don't result in any object code so why
is including one more a big deal?

iostream is a big library.

It doesn't matter how big the library is. The linker will bring in
only the functions required for your program

 

[Alf P. Steinbach]

Ok what is it that's so much easier in C++ than C? It's been so long
since I've looked at C++ I can't remember much about it.

Recall that C++ was originally "C with classes".

So that's the basic thing that originally was added to C to create C++.
Essentially it's about having /language support/, with strict type
checking, of what you have to do manually in C. For example:

* C++ supports derived classes. In C you have to cast to/from a
conceptual "base class member" placed first in the struct.

* C++ supports the o.m() notation for member functions. In C you have to
write m( &o ), and (modulo some "generics" support introduced in C11)
you have to invent different names for m overloads.

* C++ supports virtual member functions in a type safe way. Doing this
manually in C is a nightmare, even with supporting macros, and involves
a lot of very unsafe casting. Essentially, C++ has a /type safe implicit
downcast/, but you don't see it until you try to do the same in C, at
which point most programmers choose to trade away some efficiency in
order to simplify the programming, which IMHO trades away the whole
point of using C in the first place.

I suspect the third point was why Bjarne found it worthwhile to create a
language extension, which turned into a whole new language with support
for far more than that. Including, as you did recall, more easily
customizable allocation machinery. Which is in support of the strong
typing, namely an all-or-nothing guarantee for allocation +
initialization, sort of like a database transaction but transparently.

However, the all-or-nothing guarantee for allocation + initialization
requires exceptions and so it wasn't added until around 1990 somewhere
(1989? I can't recall).

In short, at the start it was virtual member functions, with that
ordinarily-not-very-apparent implicit type safe downcasting.

Instead of free() you can use delete if I remember right.

There's a customizable more type safe memory allocation machinery, yes.

And this machinery ties in with the all-or-nothing guarantee for
allocation + initialization.

And that guarantee ties in with and requires exceptions.

Exceptions are another thing that that you really don't want to do
manually in C. But then the difficulty of doing it in C means that most
"pure C" programmers are unfamiliar with it and therefore utterly fail
to see the utility. Like, why on Earth would we want that complication?

Well, they /simplify/ things directly, when you have language support,
and they make possible the allocation + initialization all-or-nothing
guarantee, which is of immense practical value. They do have a steep
cost, though, namely that the supporting internal machinery must be
dynamically initialized, which can be difficult to arrange in e.g.
driver software. Also, difficult for embedded programming.

As I recall Bjarne postponed adding exceptions until Andrew Koenig and
he arrived at some satisfactory ideas about it. At that time exception
handling had been added in a number of languages (notably Ada, but
academics will no doubt prefer to mention e.g. Common Lisp), so it did
not require genius to see its utility, merely familiarity with the
programming world outside the C sphere. E.g. I remember writing an
enthusiastic article about Ada exception handling in the middle 80s. But
I think it did require folks like Bjarne and Andrew in order to see how
to integrate that concept with C, and how it could offer new and very
useful guarantees, thereby greatly simplifying the programming.

You need a whole extra header
fstream in order to save to files. Is it worth the overhead in the binaries?
iostream is a big library.

It depends.

For small toy programs, yes, why not.

One notch up in size you (or I) start considering alternatives.

Even more up in size, hey, that added size overhead is now insignificant.

But the main reason that I'd like to avoid iostreams as much as possible
is that they generally cause needlessly verbose, complex and brittle
client code, with usually pretty inefficient i/o, all in order to get a
little type safety that by no means is very complete. It sort of reminds
me of Benjamin Franklin. Readers can probably guess why.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

Given the problems you have demonstrated with C, it is unlikely that
C++ holds any advantage for you.

Regardless of the merit or lack thereof of the above evaluation of the
OP, very few clc++ readers will benefit from that statement.

The statement is also quite offensive.

I know, we're not yet at the point again where out-of-the-blue
needlessly offensive statements are not ordinary in clc++, and perhaps
we'll never get there again, but it's a good ideal to aim for.

You remember wrong.

That depends on the interpretation. I see your interpretation (replace
free() with delete and don't correspondingly replace malloc with new) as
adversarial. I would say that Bill does remember correctly -- then
choosing a more natural interpretation where the statement makes sense.

Wrong again.

I'm sorry, but that statement does not make sense to me.

Besides, headers don't result in any object code

Sorry, that's incorrect.

It also misrepresents the OP, who has not claimed anything in that
direction.

so why is including one more a big deal?

Including headers add to build time.

It doesn't matter how big the library is.

Oh, it does. In particular for its complexity, which affects both the
effort needed to learn how to use it, and the effort needed to test and
correct client code. In other words, there's a fairly direct connection
between library size and financial cost (in man-hours) of using it.

The linker will bring in
only the functions required for your program

If one is lucky.

iostreams, which the OP is discussing, is well known for adding a fair
amount of baggage.


- Alf

 

[Ian Collins]

Regardless of the merit or lack thereof of the above evaluation of the
OP, very few clc++ readers will benefit from that statement.

The statement is also quite offensive.

"Bill" is well known on c.l.c, renowned for asking almost the same
question many times over many years. Anyone familiar with that group
would agree with Barry.

 

[Stuart]

On 01.11.2013 04:59, Barry Schwarz wrote:
[snip]

Regardless of the merit or lack thereof of the above evaluation of the
OP, very few clc++ readers will benefit from that statement.

Probably true. If Barry had written "The problems you have shown to us
in previous posts indicate that C++ is in fact not better suited for
your specific problem space than C.", it would have been much more
clearer to the "average" clc++ reader.

The statement is also quite offensive.

Also probably true, but IMHO your statement can also be considered
offensive. My formulation would have been "I think that your statement
is offensive".

I know, we're not yet at the point again where out-of-the-blue
needlessly offensive statements are not ordinary in clc++, and
perhaps we'll never get there again, but it's a good ideal to aim
for.

+1.

Regards,
Stuart

 

[Paul ( The Troll )]

Ok what is it that's so much easier in C++ than C?

C++ References are very good.

It's been so long

since I've looked at C++ I can't remember much about it. Instead of free()

you can use delete if I remember right. You need a whole extra header

fstream in order to save to files. Is it worth the overhead in the binaries?

iostream is a big library.

The IO lib you use,if any, will depend on your target platform. You may just call the system IO routines directly. Bear in mind you can always call printf in C++ if you choose to.

 

[woodbrian77]

If one is lucky.

I think Mr. Kanze and others have talked about giving functions
their own source/implementation files in order to minimize the
size of executables. I sometimes split a function off into a
separate file like that.


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

 

[osmium]

On Thu, 31 Oct 2013 19:09:13 -0500 in comp.lang.c++, "Bill


There are may possible answers to that, but I'll pick just one. It's
easier in C++ to organize your code so that parts that should have
nothing to do with each other don't, in fact, depend on each other.

http://www.smileyvault.com/albums/userpics/10172/aug08_031.gif

 

[Paul ( The Troll )]

One shouldn't use printf in a C++ program. printf is not type safe.



/Leigh

Neither is the output device.

 

[osmium]

http://www.smileyvault.com/albums/userpics/10172/aug08_031.gif

You are wooshed? For a explanation at longer length, see Alf's post
in this thread. Suffice it to say that if you try to start out by
debating free vs. delete or printf vs. iostreams, as did the OP, the
real point will inevitably whoosh by you. To get the full benefit
of c++ you need to think in terms of program design first.[/QUOTE]

Yeah, I was whooshed. I kind of know C++ and I couldn't do much to drill
down from what you said to some real substance..

I think Bill could do much better by typing "what are the advantages of
object oriented programming languages" into google. Without the quotes.

Someone said the thing that would benefit Bill most was references, I agree
with that reading of the situation, I came up with that same notion,
independently but did not post it. I also agree with whoever said Bill's
post was very troll like. .

 

[Jorgen Grahn]

http://warp.povusers.org/programming/cplusplus_superior_to_c.html

I promised myself not to contribute to this thread, but ...
I agree with more or less all of that. Read it first, and then
I'm willing to discuss any remaining unclear points.

/Jorgen

PS. The text would be more powerful if the author's name (Mr Nieminen,
I suppose) was there.

 

[woodbrian77]

I promised myself not to contribute to this thread, but ...
I agree with more or less all of that. Read it first, and then
I'm willing to discuss any remaining unclear points.

You say it would be more powerful if the author's name were
there. I think it would be better with fewer adjectives and
adverbs.

"You can completely safely have such a struct"

I'd write it as

You can safely have such a struct


There's an "exels" in the conclusion that looks misspelled.

 

[osmium]

On Sat, 2 Nov 2013 16:38:12 -0600 in comp.lang.c++, "osmium"


But references, by themselves, buy you very little more than you get
with good old c pointers. When you combine the simplified syntax of
references with c++ overloaded functions and templates then they
start to get powerful. Most c++ "features" are like that: they work
together.

I agree with that. Apparently you do not know that Bill has been posting to
c.l.c for eight years or so and has been making little progress. He claims
to be on medication for a problem of some sort which impacts his mind.

There is even the possibility that he is a *very good* troll.

Bill would be even more whooshed by your initial post than I was, references
would have been a nice addition to C, going beyond that gets complicated..

 

[Barry Schwarz]

Regardless of the merit or lack thereof of the above evaluation of the
OP, very few clc++ readers will benefit from that statement.

Since the OP was asking advice for himself, any benefit to other
readers is secondary.

The statement is also quite offensive.

What part did you find offensive?

Was it the statement of fact that Bill has a long history of
posts documenting his difficulty in mastering basic C concepts? Since
he has explicitly addressed this problem numerous times in his own
posts, this is neither a surprise nor an insult.

Perhaps it was the assertion that moving on to a more
advanced/complex language without understanding the basics will not
prove fruitful? You can take offense at that if you want but learning
to walk before attempting to run is still sound advice. There is a
reason algebra is a prerequisite for trigonometry and calculus.

I know, we're not yet at the point again where out-of-the-blue
needlessly offensive statements are not ordinary in clc++, and perhaps
we'll never get there again, but it's a good ideal to aim for.

Calling him a troll would have been offensive. Suggesting he is not
yet ready to move up is just an honest evaluation. In my opinion,
misleading him to think otherwise would be even more offensive.

That depends on the interpretation. I see your interpretation (replace
free() with delete and don't correspondingly replace malloc with new) as
adversarial. I would say that Bill does remember correctly -- then
choosing a more natural interpretation where the statement makes sense.

I am wiling to concede that your interpretation is more natural for
you. But many of us have seen him get fixated on a quote out of
context with no appreciation of the nuances or ramifications. This is
not adversarial; it is simply an attempt to prevent a mistaken idea
from gathering too much steam.

I'm sorry, but that statement does not make sense to me.

C++ can save files without including fstream.

Sorry, that's incorrect.

Enlighten me please. Which standard headers result in code being
generated?

It also misrepresents the OP, who has not claimed anything in that
direction.

He said including the header fstream adds overhead to a program. If
it does, I'd like to learn how.

Including headers add to build time.



Oh, it does. In particular for its complexity, which affects both the
effort needed to learn how to use it, and the effort needed to test and
correct client code. In other words, there's a fairly direct connection
between library size and financial cost (in man-hours) of using it.



If one is lucky.

iostreams, which the OP is discussing, is well known for adding a fair
amount of baggage.

I thought he was discussing files but OK.

 

[Alf P. Steinbach]

Enlighten me please. Which standard headers result in code being
generated?

First though, readers may note that Barry's first statement above is a
misrepresentation of the OP, in order to attack him, and that the second
statement is a slight misrepresentation of my response.

Now, technically even a C header can contain definitions. But in C++
this is supported by the language, and therefore generally in C++ it
causes no problem except header size bloat and some machine code bloat.

Depending on the compiler the machine code bloat can be optimized away.
Indeed, the bloat caused by templated code is largely a thing of the
past, with nobody teaching the workarounds anymore. But, for example,
the language guarantees that the iostream objects are initialized at or
prior to inclusion of <iostream>, which brings in the whole machinery,
and a compiler has to be pretty darn smart to optimize that away.

#include <stdio.h>
#ifdef IOSTREAM
#   include <iostream>
#endif
#ifdef FSTREAM
#   include <fstream>
#endif

auto main() -> int
{ printf( "Blah blah\n" ); }

[example]
[D:\dev\test]

rem create a batch file to report file size cleanly
[D:\dev\test]
type con >size.bat

@for %%f in (%*) do @echo %%~zf bytes
^Z

[D:\dev\test]

rem test with MinGW g++ compiler.
[D:\dev\test]
g++ foo.cpp -O2 && size a.exe

54539 bytes

[D:\dev\test]

g++ foo.cpp -O2 -D IOSTREAM && size a.exe

55768 bytes

[D:\dev\test]

rem test with visual c++ compiler
[D:\dev\test]
cl foo.cpp -O2 /Feb && size b.exe

foo.cpp
57344 bytes

[D:\dev\test]

cl foo.cpp -O2 /Feb -D IOSTREAM && size b.exe

foo.cpp
77312 bytes

[D:\dev\test]

_

[/example]


Cheers & hth.,

- Alf

 

[Bill Cunningham]

On Thu, 31 Oct 2013 19:09:13 -0500 in comp.lang.c++, "Bill


There are may possible answers to that, but I'll pick just one. It's
easier in C++ to organize your code so that parts that should have
nothing to do with each other don't, in fact, depend on each other.

But you have structs and struct members in C what's so great about C++
classes ? What would make C++ a good add on to C?

Bill

 

[Bill Cunningham]

http://warp.povusers.org/programming/cplusplus_superior_to_c.html

Thanks for the link.

Bill

 

[Bill Cunningham]

I agree with that. Apparently you do not know that Bill has been
posting to c.l.c for eight years or so and has been making little
progress. He claims to be on medication for a problem of some sort
which impacts his mind.
There is even the possibility that he is a *very good* troll.

Bill would be even more whooshed by your initial post than I was,
references would have been a nice addition to C, going beyond that
gets complicated..

I'll bite. You know as well as I do that with the advent of google that
*any* usenet post is a troll. *All* questions can be asked of google and
*any* response answers all possible questions.
I'm going to butt out now.