[Arkham_c]

I've been refreshing my memory of C and learning the nuances of C++ so I can add it to my resume. I started with a simple "hello world" example like this:

Code:
#include <iostream.h>

int main()
{
    cout << "Hello, World!" << endl;
    return 0;
}

It works fine, but the executable that it creates is 656KB in size! That's crazy. The same program as C (essentially stdout/printf instead of iostream/cout) is 15KB.

What's the deal? Am I inadvertently linking in a library statically or something?

[00101001]

No, C++ is just bloated as hell.

Also, IMHO, cout is the worst POS ever. If you need to use C++, just stick w/ printf -- it's your friend

P.S. I hate C++.

A lot.

[holygoat]

Don't know, but take out that .h.

Bizarrely, it's 650 K on my machine too.

"-shared" doesn't work on OS X according to the man pages. "-shared-libgcc" doesn't change the size.

I built with this:

g++ -o test test.cc

[smeger]

I don't know why it's 650Kb, but it doesn't seem to grow too quickly after that. I've got a pure C++ (platform generic, heavy use of STL) program on my machine that's about 30K lines of code, and the binary is about 1.4MB. Not much bigger than 650Kb, and a much larger program. So that's good anyway...

00101001, I like iostreams. What don't you like about 'em? They seem an elegant solution while still allowing cross-platform compatibility.

[holygoat]

Not another language debate

Seriously, the only reason this binary is 650K is because it's statically linked.

I have a math-heavy C++ application on my server, 8K of code, and it compiles to a 27K binary on Linux. That's how it should be.

It's nothing to do with the difference between C and C++.

cout and iostreams in general are great. You can't define your own C format string - but you can define << for any class. That means you can print an object like this:

Code:
MyClass a;
cout << a << endl;

Pretty cool, huh?

printf is OK, but it's not as versatile.

[Turias]

NSLog is so much cooler.

[Arkham_c]

Originally posted by Turias:
NSLog is so much cooler.

Well, I'm learning C++ to better work on a 400,000+ line C++ tool running on huge UNIX boxes at work that process many 10+ GB files all day long (cellular call data records for 24 million customers). It's not really a choice of C++ or something else.

I personally like lots of languages, but C is not one of them. Although I did do C exclusively for about 2 years in my first job out of college, I haven't done much since. C++ seems better than C, if for no other reason than memory allocation and deallocation is cleaner. I also like the idea of -> which C lacks. Its Compared to java, C++ has pretty primitive object orientation, but it's not as bad as everyone in the java world makes it out to be.

[Arkham_c]

Originally posted by holygoat:
Seriously, the only reason this binary is 650K is because it's statically linked.

That was the real crux of my original question. How do I link to whatever library contains IOStreams dynamically? Is there a flag to g++ that I need to add (-shared, -dynamic, or something to that effect) that will result in a tiny binary?

[holygoat]

Originally posted by holygoat:
"-shared" doesn't work on OS X according to the man pages. "-shared-libgcc" doesn't change the size.

There may be some other approach I'm not aware of - try going through Xcode's settings?

[holygoat]

OK, doing some tests...
* -shared isn't relevant. I misread this.
* -nostdlib causes compile errors.
* -dynamic doesn't seem to make a difference.
* -fzero-link similarly.

Can't seem to do anything...

[davechen]

If you do a "strip a.out", (or whatever the executable's name is), you can cut the file size almost in half. strip removes all the debugging information.

[Chuckit]

Originally posted by Arkham_c:
I also like the idea of -> which C lacks.

Er...what? C has the -> operator.

[spiky_dog]

Originally posted by holygoat:
Not another language debate

Seriously, the only reason this binary is 650K is because it's statically linked.

I have a math-heavy C++ application on my server, 8K of code, and it compiles to a 27K binary on Linux. That's how it should be.

It's nothing to do with the difference between C and C++.

cout and iostreams in general are great. You can't define your own C format string - but you can define << for any class. That means you can print an object like this:

Code:
MyClass a;
cout << a << endl;

Pretty cool, huh?

printf is OK, but it's not as versatile.

admittedly c++ is bloated, but you're right, having virtual functions (or as in this case) overloading operators is fun stuff.

[holygoat]

Originally posted by davechen:
If you do a "strip a.out", (or whatever the executable's name is), you can cut the file size almost in half. strip removes all the debugging information.

Handy, but it doesn't account for the app being 600K too big... that must be down to statically-link libraries.

I'm puzzled... I've only ever had to explicitly statically-link before, not "opt out"!

[Mskr]

The reason that you're statically linking is that there is, by default AFAICT, no libstdc++.dylib in Mac OS X, so at least on my Panther (10.3.2) machine, all my binaries would be statically linked. Now, this might be because you would want C++ binaries to run on any version of Mac OS X, and we've switched compilers a couple of times. I'm not sure why entirely you would have to have statically linked C++ binaries, but I wonder if this isn't it.

[00101001]

Originally posted by smeger:
00101001, I like iostreams. What don't you like about 'em? They seem an elegant solution while still allowing cross-platform compatibility.

IOStreams's cross platform-ness is arguable. cin in particular. Try using getline on a Sun and a windows box without resorting to some obscure method calls to make it work sensibly.

But that's not my point. In fact, I don't really have a point. But I will continue blabbering.

C++, the good:
- [this space left blank, intentionally]

C++, the bad:
- the complexity (you find me a compiler that completely implements the C++ standard)
- templates (oh god the bloat!)
- speed/code size (C++ is a tad slower than C, and compilers generate MUCH larger code)

C++, the good and bad, depends, really,
- sorta compatible with C
- operator overloading (makes sense if I define a Vector class... I can add 2 vectors with just a '+'... cool! Does NOT make sense if I have an I/O class. WTF do << and >> have to do with IO? That does not make sense. It does not make sense.

But some people will say, "Oh, but C++ is object-oriented!! OO is gooood! C sucks!"

Firstly, it is the worst possible form of OO built on top of C. You want a good one? Objective-C is beautiful. Secondly, this OO crap is bull. I can program OO in C, and I can do procedural in C++ without breaking a sweat. What!?! How?!? Blasphemy!! No, really. What many people do not understand is that object-oriented programming is A FRAME OF MIND, NOT A SYNTAX!

Instead of:
mythingy->BeAwesome(i, j, k);
in C, this would become:
BeAwesome(mythingy, i, j, k);

mythingy represents a hunk-o-memory (my object), and I have functions (BeAwesome(...)) that work on that object (and all derivations of that object). Sounds object-oriented to me.

That's the longest post I've ever written.

Before I go:
- you can add your own custom types to printf
- scanf is better than cin
- printf is better than cout (do this in cout:
printf("%.3f\n", myfloat); // haha, it'll be 4 times as long)
- On a scale of 1-to-10, I think C++ sucks a lot.

[itai195]

Heh, 00101001 is fighting the good fight, but just slightly OT

I haven't yet used an OOP language that I didn't prefer over C++. All OOP can be implemented on top of procedural languages, for example OOP in Lisp is built on top of the procedure language and, for example, inheritance can be implemented pretty simply just using hashtables.

[smeger]

00101001, I somewhat agree with you, so I'm not going to argue too hard. I especially agree with your comments regarding procedural vs. object oriented programming. CoreFoundation is a nice example of object-oriented programming using a procedural language.

The only real dispute I have is that when you need the stuff that C++ provides, and you don't want to work too hard for it, and you want your code to be cross-platform, then C++ is very nice. Case: Templates. Ugly syntax, figuring out what your compile-time error is sucks, but when you need to whip out a quick dynamic container, vector<int> is a hell of a lot nicer than rolling your own in C. Maybe it's time for me to learn Python...

I'm certainly not arguing that C++ is God's gift to programmers. But I don't think it's as bad as you make it out to be, especially for a lazy programmer like me.

[00101001]

Yep yep, I give you that. Convenience is sorta nice... but if you sit down one day and create a whole bunch of data structures in C, you can reuse them to your hearts content. And chances are, it'll be more efficient than STL.

But until that day... keep on programming in whatever you feel most comfortable with.

P.S. C++ still makes me cry

And no, I can't help with the code size problem

[Chuckit]

Originally posted by 00101001:
templates (oh god the bloat!)

I don't see how templates necessarily cause all that much more bloat than the C practice of providing a thousand similar functions with a different letter appended to their names to indicate their types (e.g. round, roundf, lround, lroundf, llround, llroundf, abs, fabs, cabs).

What many people do not understand is that object-oriented programming is A FRAME OF MIND, NOT A SYNTAX!

Instead of:
mythingy->BeAwesome(i, j, k);
in C, this would become:
BeAwesome(mythingy, i, j, k);

mythingy represents a hunk-o-memory (my object), and I have functions (BeAwesome(...)) that work on that object (and all derivations of that object). Sounds object-oriented to me.

How does one subclass mythingy? As we see with CoreFoundation, while you can use some object-oriented methodology with C, the language itself is still a lot further from supporting OOP than C++ is.

- you can add your own custom types to printf

Really? How do you do this? I've never even seen this hinted at.

- printf is better than cout (do this in cout:
printf("%.3f\n", myfloat); // haha, it'll be 4 times as long)

By that logic, the C standard library beats the pants off of Cocoa, since standard library functions typically look like "rndnum" whereas Cocoa methods are usually more like "roundNumberInDirection:withBehavior:toPrecisi on:" -- eight times as long!

That said, I'm not crazy about C++. It's a pretty crude form of OOP. I just think you're a little aggressive with your criticism.

[holygoat]

Originally posted by 00101001:
Yep yep, I give you that. Convenience is sorta nice... but if you sit down one day and create a whole bunch of data structures in C, you can reuse them to your hearts content. And chances are, it'll be more efficient than STL.

But until that day... keep on programming in whatever you feel most comfortable with.

P.S. C++ still makes me cry

And no, I can't help with the code size problem

Actually, the STL is the best part of C++ - guaranteed algorithmic complexities for operations, containers/algorithms interoperability, and generic containers. It's also very performant - 99% of programmers couldn't write a better list container, and it certainly wouldn't be as flexible, well-tested, or analysed. And "one day" is an enormous understatement! A well-tested, high-performance, portable linked list library would take more than a day, let alone the others in the STL (deque, stack, vector, map, set...)

People often say "why use C++? Just write your own linked list code!". The reason being that the time I spend not implementing and testing my own hash_map etc. is time I can spend on the problem at hand. This is the argument for all HLLs (not that C++ is very HL) - saving programmer effort.

Again, it's another layer of useful abstractions. Templates, syntax for OO, streams, containers, etc. all simplify the translation of concepts into code, and reduce programmer effort. From that point of view, C++ is a clear win.

Not to say it's a good language - that's backwards compatibility for you. But it's not as bad as people make it out to be.

Everything has its place.

[00101001]

Originally posted by Chuckit:
How does one subclass mythingy? As we see with CoreFoundation, while you can use some object-oriented methodology with C, the language itself is still a lot further from supporting OOP than C++ is.

In a nutshell, it would require some thought on the part of the programmer with regards to data layout and whatnot, it's cumbersome, but possible. However, if I want OO I'll use ObjC

Really? How do you do this? I've never even seen this hinted at.

Check this out:
http://www.gnu.org/software/libc/man...ng-Printf.html

Good stuff, eh? Dirty practical joke would be to register for a bunch of the "standard" formatters like d, f, and s, and replace them with something that spits out random bits. (Only makes sense for a group project, obviously).

By that logic, the C standard library beats the pants off of Cocoa, since standard library functions typically look like "rndnum" whereas Cocoa methods are usually more like "roundNumberInDirection:withBehavior:toPrecisi on:" -- eight times as long!

Not quite my point... by length, I referred not only to physical typing, but compiled code size as well. Doing something like cout << setprecision(8) << a << setprecision(3) << b << setprecision(4) << c << endl;
though contrived, illustrates my point.

That said, I'm not crazy about C++. It's a pretty crude form of OOP. I just think you're a little aggressive with your criticism.

Yep, sorry if I insulted anyone. Didn't mean to, C++ is a tool just like all the other languages... just happens to be one that I dislike. As a C programmer, I guess I look at myself like a ninja, preferring the sword to the gun. Lighter, sleeker, and deadlier . Hell, nobody should listen to me, I *enjoy* dropping down into assembly for some stuff.

[BLAZE_MkIV]

It was always my impression that streams were primarily for data and communication purposes and that cin and cout were just a convienence that they provided and not really intended for hard core data formating, isn't that what a GUI is for?

[holygoat]

Originally posted by BLAZE_MkIV:
It was always my impression that streams were primarily for data and communication purposes and that cin and cout were just a convienence that they provided and not really intended for hard core data formating, isn't that what a GUI is for?

No, a GUI is a certain kind of interface. I refer you to The Art of Unix Programming for a discussion of the benefits of textual interfaces to programs, better than I could explain here.

cin and cout aren't conveniences - they are the C++ way of doing input and output.
Also, anyone who's ever tried to wait for a user character input in multi-platform C code will know that it's not possible. cin allows you to do it with ease.

Streams are useful for all sorts of things. cin, cout, and cerr are the standard CLI routes (which are accessible in C). The pleasure of C++ over C here is I can use << against any stream, whereas I have to mess about with printf, fprintf, and format codes to do the same in C. To programmatically redirect stdout to a file in C means changing the file pointer for stdout, which is no fun. In C++, keep a stream object and work with that - a bit easier, a better abstraction.

They're no worse for data formatting than C's printf.

[holygoat]

Just thought I'd point out, in case it looks like I really like C++ - I'd rather be programming in Lisp. Or Python. Perhaps even Java, though not really

Ah, it's not so bad! There are worse languages, to be fair.

[BLAZE_MkIV]

Maybe I should have been a little more explicit.

I meant that the streams were intended to handle raw data, implicit types and classes. The formating functions were added in because they are obviously nessicary.

They weren't really intended to make the data look pretty. Sure they can do it, I find the mechanism clumsy. If you want to make the data pretty for the user you put it in a GUI with a table or a graph.


BTW you can wait for user input with the C scanf or getc. It will return eof if there is no i/o, then you clear the error and repoll.

[holygoat]

Originally posted by BLAZE_MkIV:
Maybe I should have been a little more explicit.

I meant that the streams were intended to handle raw data, implicit types and classes. The formating functions were added in because they are obviously nessicary.

They weren't really intended to make the data look pretty. Sure they can do it, I find the mechanism clumsy. If you want to make the data pretty for the user you put it in a GUI with a table or a graph.


BTW you can wait for user input with the C scanf or getc. It will return eof if there is no i/o, then you clear the error and repoll.

I think the generalisation of iostreams to console in/out was deliberate - it's a boon for all concerned. Yes, the formatting functions appear to be a hack, but I can't think of any neater way to do it while still dealing with streams. Think of it as sending a command to the stream object, like talking to the secretary who's taking your dictation!

My point about the C waiting for input is that getch only works in Windows, scanf is messy and prone to buffer overflows, and it just ain't as easy or reliable.

Your last point about prettifying applies to any language, including C. Indeed, you're saying that float formatting parameters in printf are useless, because people should use a GUI. iostreams and printf map to each other; it's just that iostreams are more general, elegant, and reliable. What you do with them is up to you.

There are many situations where textual input/output is desirable/preferable.

[BLAZE_MkIV]

No, the printf function format string with its specifiers make it obvious that it was intended to let you get it to look exaclty like you wanted. Expecially when it predates the gui.

[holygoat]

Originally posted by BLAZE_MkIV:
No, the printf function format string with its specifiers make it obvious that it was intended to let you get it to look exaclty like you wanted. Expecially when it predates the gui.

But you can do exactly the same thing with iostreams, so it's a moot point.
You should also note that the C++ standard says nothing about a GUI interface, so it's as applicable as to C.
I can't be bothered to check if this is in C, but you can also specify number of columns and justification, simply through setw(). Handy.

"iostreams with their stream manipulation functions make it obvious that they were intended to let you get it to look exactly like you wanted. Especially when the standard supports CLI interaction."

I don't see how

Code:
cin >> myFloat;
cout << "It's " << scientific << myFloat << endl;

is worse than the equivalent in C.

[Arkham_c]

Back to the original issue, I built the same code in XCode as I posted in the original post. The file that was produced is 12KB. That seems reasonable to me, but how was XCode able to link in libstdc++.a dynamically when we were not able to do so on the command line?

[holygoat]

Originally posted by Arkham_c:
Back to the original issue, I built the same code in XCode as I posted in the original post. The file that was produced is 12KB. That seems reasonable to me, but how was XCode able to link in libstdc++.a dynamically when we were not able to do so on the command line?

I have no f'ing idea.
I feel vindicated:

Originally posted by holygoat:
There may be some other approach I'm not aware of - try going through Xcode's settings?

Didn't help matters though!

[itai195]

Take a look at xcode's build log and see if you can tell what it's doing.

[Arkham_c]

Originally posted by itai195:
Take a look at xcode's build log and see if you can tell what it's doing.

Apparently the ZeroLink stuff added to XCode has something to do with it.


CompileC build/quickApp.build/quickApp.build/Objects-normal/ppc/main.o main.cpp normal ppc c++ com.apple.compilers.gcc.3_3
mkdir -p /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc
cd /Users/dshaw/quickApp
/usr/bin/distcc /usr/bin/gcc-3.3 -x c++ -arch ppc -pipe -Wno-trigraphs -fasm-blocks -fpascal-strings -g -O0 -mtune=G4 -Wno-four-char-constants -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -O0 -fmessage-length=0 -ffix-and-continue -fzero-link -fpch-preprocess -F/Users/dshaw/quickApp/build -I/Users/dshaw/quickApp/build/include -I/Users/dshaw/quickApp/build/quickApp.build/quickApp.build/DerivedSources -Wp,-header-mapfile,/Users/dshaw/quickApp/build/quickApp.build/quickApp.build/quickApp.hmap -c /Users/dshaw/quickApp/main.cpp -o /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/main.o

Building ZeroLink libstdc++ into /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/libstdc++_ZeroLink.dylib
cd /Users/dshaw/quickApp
/usr/bin/gcc-3.3 -prebind -dynamiclib -all_load -lstdc++_ZeroLink -twolevel_namespace -nostdlib -lgcc -lSystem -o /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/libstdc++_ZeroLink.dylib

Building ZeroLink launcher /Users/dshaw/quickApp/build/quickApp
cd /Users/dshaw/quickApp
/usr/bin/ld -o /Users/dshaw/quickApp/build/quickApp -lcrt1.o /System/Library/PrivateFrameworks/ZeroLink.framework/Resources/libZeroLinkAppStub.a -all_load -lSystem -L/Users/dshaw/quickApp/build -F/Users/dshaw/quickApp/build /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/libstdc++_ZeroLink.dylib -stack_size 100000 -stack_addr c0000000 -framework ZeroLink -F/System/Library/PrivateFrameworks/ -x -unexported_symbols_list /System/Library/PrivateFrameworks/ZeroLink.framework/Versions/A/Resources/ZeroLinkAppStub.nexp -sectcreate __TEXT __zerolink /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/quickApp.zerolink

Bundlizing /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/main.ob /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/main.o

Bundlizing /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/libstdc++.ab /usr/lib/libstdc++.a

[holygoat]

Originally posted by Arkham_c:
Apparently the ZeroLink stuff added to XCode has something to do with it.

Canny. I tried doing -fzero-link, but it didn't help. Perhaps you have to link against different libraries. Ah well

[itai195]

Originally posted by Arkham_c:
Apparently the ZeroLink stuff added to XCode has something to do with it.

Hm, try doing a deployment build and see what that spits out.

[Arkham_c]

Originally posted by itai195:
Hm, try doing a deployment build and see what that spits out.

Oh well. When i do a deployment build it goes back to 656KB.

For those who are interested, here is the compile line for the deployment build.


CompileC build/quickApp.build/quickApp.build/Objects-normal/ppc/main.o main.cpp normal ppc c++ com.apple.compilers.gcc.3_3
mkdir -p /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc
cd /Users/dshaw/quickApp
/usr/bin/distcc /usr/bin/gcc-3.3 -x c++ -arch ppc -pipe -Wno-trigraphs -fasm-blocks -fpascal-strings -Os -mtune=G4 -Wno-four-char-constants -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -fmessage-length=0 -fpch-preprocess -F/Users/dshaw/quickApp/build -I/Users/dshaw/quickApp/build/include -I/Users/dshaw/quickApp/build/quickApp.build/quickApp.build/DerivedSources -Wp,-header-mapfile,/Users/dshaw/quickApp/build/quickApp.build/quickApp.build/quickApp.hmap -c /Users/dshaw/quickApp/main.cpp -o /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/ppc/main.o

Ld /Users/dshaw/quickApp/build/quickApp
cd /Users/dshaw/quickApp
/usr/bin/g++-3.3 -o /Users/dshaw/quickApp/build/quickApp -L/Users/dshaw/quickApp/build -F/Users/dshaw/quickApp/build -filelist /Users/dshaw/quickApp/build/quickApp.build/quickApp.build/Objects-normal/quickApp.LinkFileList -lstdc++ -arch ppc -prebind