[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
On Saturday 19 January 2002 7:35 pm, you wrote:
Why C/C++? You only "really" learn these things by using them in anger, and they aren't terribly good programming languages in many ways. Or perhaps I should moderate that to they are built for speed, in much the same way taking the hand brake, and seat belts of a car will make it go slightly faster ;)I've never quite understood how C is a bad language. If it's due to the lack of memory managent, I've always considered that a Good Thing. The
If only because C++ helped me write smaller, faster code. A lesson obviously
missed from the Microsoft version.
I still enjoy reducing the size of programs and scripts, from C to PHP. It's
one of the strengths of Open Source - if you need a really small kernel etc,
just lop out bits from the source that aren't needed for this specific use.
Having said that, I just tried to compile this code using gcc:
#include <iostream.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
cout << "Hello, World!" << endl;
return EXIT_SUCCESS;
}
Now when compiled from within an IDE like KDevelop, it's fine, so obviously
I'm missing some gcc commands because I get
/tmp/ccoRIYCB.o: In function `main':
/tmp/ccoRIYCB.o(.text+0xa): undefined reference to `endl(ostream &)'
/tmp/ccoRIYCB.o(.text+0x17): undefined reference to `cout'
/tmp/ccoRIYCB.o(.text+0x1c): undefined reference to `ostream::operator<<(char
const *)'
/tmp/ccoRIYCB.o(.text+0x27): undefined reference to
`ostream::operator<<(ostream &(*)(ostream &))'
collect2: ld returned 1 exit status
I'm asking for a simple-ish reason. KDevelop, with debugging switched off,
writes this code as a 31kb executable (hw) with an rpm file coming out at
12kb.
31kb seems a lot for such a simple console program. Is KDevelop bloating the
program? Can a command line gcc hack reduce the filesize? After all, program
functionality doesn't come much smaller than the above.
language assumes the programmer knows what he's doing. This, to me, sounds like a reasonable assumption to make. Regards,
I still remember programming for a pure DOS environment (i.e. prior to MS-DOS 6) and getting a program to compile to within 64kb. An artificial and frustrating limitation, but a useful challenge nonetheless. Does anyone use assembly code still? (!!) Would assembly code written for the PC function independent of the OS? Are INT's handled the same way (after all, we're talking hardware controllers here, not OS, aren't we? Or does this only work in real (DOS) mode and not in a 32bit environment?) (Can you tell I didn't do a computer related degree!!) Coming back to what Simon said about C++ and buffer overflows, it does take a LOT of time to bug proof a small program and it becomes impossible on larger applications. I wrote a simple DOS program (text viewer) that had to cope with running on a 8086 laptop (640k RAM, 4Mb hard disc, CGA graphics, etc.etc.) and I was able to strip out bugs quite easily. After all, when the program has to be that small (and efficient) to run at all, there isn't much room for bugs to be introduced. The final program was a client of a database front-end that used Paradox and the problems with that mounted and mounted and mounted until the larger database app was teetering over the abyss. Power comes at a price, PHP can be more secure than Perl simply because it isn't possible to do in PHP some of the things you can do in Perl. Java applets were created to follow the same principle - an applet cannot be compiled to do things a Java app can do, so by definition, an applet has increased security compared to an app. (Note: not less bugs, just less opportunity for bugs and security problems like overflows.) -- Neil Williams ============= http://www.codehelp.co.uk neil@xxxxxxxxxxxxxx linux@xxxxxxxxxxxxxx neil@xxxxxxxxxxxx -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.