C/C++ vs. Java vs. C#

[Wowbagger]

Here is a thread for discussing the merits of various computer languages. I am starting this as an attempt to continue a discussion I was having with a fellow TAM member, that was cut off much too soon. I hope she joins us, but if not, at least I should have someone else to argue with, about these things.

Here are my thoughts, to start with:

C++ was basically the C language, with object-oriented stuff shoe-horned into it. And, as a relatively low-level language, it is still useful for developing applications where performance matters most. As a side effect of its age, though, almost all other modern language features have to continue getting shoe-horned into it, rendering it rather unwieldy to write for. Especially when they are all added in rather inconsistent ways. Writing COM components is like pulling teeth, and managed classes are sometimes even worse.

Java was a substantial improvement over C/C++ in that regard: Everything was implemented consistently (for the most part), and modern features were included from the ground up. It used syntax and semantics very similar to C++, so that older programmers could get into it, right away. However, it has a history of being a performance sloth, and it originally missed out on a few important, classic features, (such as structs). Though, much of that changed over the years (some of it inspired by C#, when it was released). One of its huge selling points is the compile-once, run anywhere attitude, which I can appreciate.

C# (pronounced C-Sharp) is an elegant language contender. Like Java, it has all of the important modern features of computer languages built into it, from the ground up. But, since it is newer than Java, it was able to be constructed with a bit more hindsight. The .NET Framework provides a one-stop-shop for almost all of your standard API needs. And, for what it's worth: its IDE (Visual Studio) is the best, most productive one in the world, as far as I can tell. It's a bummer that it is only officially supported for Windows, though.

I happen to use C# the most (when I am not stuck with VB). But, perhaps that is mostly due to historic accident. I have always been a Microsoft-platform developer, in my professional career, and I suppose there is little chance of that changing, any time soon.

What do you think?

[Denver]

Sort of a side note: sometimes the available IDE also should be part of the equation when comparing languages. While a language itself may be more burdensome than another when actually trying to implement and maintain a system, IDE features can make up for that, and even give it an advantage over another choice.

But, a little more on target to the OP, I also tend not to give the resource-hog criteria quite the weight I did at the beginning. All things being equal, I'd rather use a language that was, for instance, more CPU intensive now, if it means easier portability and maintenance over time. Plus, depending what I mean by 'over time', the program may automatically get faster as the cpu is upgraded, whereas complex code will not get simpler over time. But ok, that may be more of a coding issue than a language one.

So anyways... I need to go back and read the OP.

[tomwaits]

We used a book in my high school programming class called "C++ for You++".

[tuoni]

In my view, the language you choose for a program is heavily influenced by what you're developing it to do. Most of my day-to-day stuff tends to be done in C#, but if I'm writing a website I'd actually use PHP rather than C# (with an ASP.NET front-end) unless that's what's required of me by whichever client is paying me for my code.

I must admit, I don't really give much weight to the resource intensiveness of a language since nowadays computers are (by and large) powerful enough to mostly mitigate that problem. Add to that decent garbage collection in the newer languages and I think nowadays the language one uses is (in most cases) a moot point. I would, obviously, have a completely different viewpoint if I was programming for different devices or for different situations.

[roger]

Well, I mostly adore C++, for the reasons others criticize it. Bjarne's book on how and why he designed C++ the way he did is very instructive for those who disparage the language. Much like in the OP, people complain that it contains a hodge podge of features. Rather than a hodge podge, he built the language over a number of years, adding features that were needed, and not adding, or removing, features that didn't add a lot. His guiding principle through all of this was empericism. Study what features use and how they use it, and then support that usage. The language, for example, is OO neutral. You can use OO if you want, and not use it if you don't. You can write functional programming (such as STL), or not. You can write very close to the metal, or you can write at a very high abstraction level. Sure, it has warts due to his desire to remain compatible with C, but all in all it works. The result is definitely a "professional" language - you need to study and work hard to become conversant in it, you need to use modern tools (a strong IDE, debugger, and runtime memory and resource leak detector. But given that, you can be amazingly productive in it. I recall a few guys at my place of work who for some reason decided they were going to rewrite an application I did using more "modern" tools. They spent the next several months fighting these tools because the high level of abstraction and reliance on prewritten APIs meant you had to do things 'their way'. One guy would spend hours on the phone to Microsoft support. He found quite a few bugs in their code in the process. But mostly he fought the tools we was working with, while extolling their virtues, and talking about how much more flexible the code would end up being. Meanwhile I turned the app into a production system, quickly added features when asked, etc. All that other work got scrapped. Dumb. I still don't understand why my boss allowed that - the guy that was hired and made the argument to do it had a high opinion of his own skills, and I think he managed to paint me as a reactionary or something, while promising a magic bullet.

If someone was only interested in programming casually, I'd definitely point them to another language. Super heavy COM work might point to using another language for the main work, sticking to C++ for some heavy duty processing.

People complain about things like pointers in C++, but then it turns out they are using them wrong. Things like pointers to functions are very useful when you are writing things like state machines and event driven models. In the normal course of things, references are far safer and easier to use and keep track of. I don't tend to use pointers often, but when I use them, I really need them. I remember fighting Ada to do some things that would be easy,and perfectly safe, to do with pointers in C or C++. It takes understanding of a feature, and when to use it. I do a lot of hardware level things, so I'm likely to be writing near pure C for device drivers, using pointers and such to handle events, state machines, etc. Then I'll be using OO to help me with interface design, and then functional programming to do STL-type algorithms to manipulate the data coming from the devices. I can do all that easily with one language, and am not forced into an OO straightjacket when it is not the right tool for the job. Do you need to be on the top of your game to write like that? Sure. But being at the top of your game means being at the top of the salary range for your career - not a bad thing, IMO, though it does make it harder to apply for a new job when they hear what you make and seem dubious that you are worth it. I do worry one day I'll end up being a 'COBOL programmer' - maintaining hopelessly outdated legacy systems, but for now I'm trying to stick with C++ for my career.

[dasmiller]

I've spent a lot of time in both C++ and C# (and a few other languages along the way), and I've read an awful lot of the language wars on Java vs. C#.

With some effort, I'm resisting the urge to write pages and pages about the pros & cons of, say, Java's enums and C#'s Properties.

So I'll generally concur with the OP. C++ is nearly self-encrypting and encourages a lot of (IMO) bad practices. ETA: Gonna guess that Roger (post #5) has a different perspective on that.

C# and Java are extremely similar; I prefer C#.

My recommendations: Use C++ if someone makes you use C++.

Use C# if you're targeting Windows ONLY

Use Java if any other OS may get involved.

------------------------
All of that is for 'typical' medium-to-large programming projects. For low-level stuff (like drivers), use C. Bear in mind that I've never written a driver, so don't take me too seriously here. And there are programmers who I respect a lot who say that everything should be done in Lisp. I haven't spent enough time in Lisp to have a real opinion.

For smaller, quicker, less formal things, Python or Ruby.
For smaller, quicker, less formal networky things, Tcl.

Now, many kids today seem to think that, for example, C++ and Java are completely different languages. That's because they haven't seen any really different languages. Sort of like French seems really different from Spanish if all you know are French and Spanish, but learn a little Russian or Swahili, and suddenly French and Spanish look very similar. With that perspective, I'd recommend that any budding programmer should spend some time fooling around with Lisp and Forth just so they see how different things really are. And code up some routines in x86 assembly- it will give you some insights into how the computer really works.

[roger]

Originally Posted by dasmiller

So I'll generally concur with the OP. C++ is nearly self-encrypting and encourages a lot of (IMO) bad practices. ETA: Gonna guess that Roger (post #5) has a different perspective on that.

Well, I wouldn't say "encourages". I definitely would say "allows". Should a irresponsible person drive a 550HP, 9" raised rock crawler on the street? Probably not. They'd tip it over in a serious corner, it makes it easy to pull shenanigans in a parking lot (who hasn't seen some idiot driving their truck over a table sized rock or something to park someplace stupid and illegal), drag race at lights, etc. In the hands of somebody who knows what the tool is for, it's perfect for it's job, and nothing else works as well. "But it's so easy to drive to fast for a corner, and the CG is so high it'll tip over!" bewails the reader. Um, ya. It's a tool for going over a house size boulder at 2mph, and perhaps drive carefully at the speed limit on public roads. Not for beginners.

If you are writing a typical GUI application that takes some user input, stores it somewhere, processes it a bit, and displays the result, there's no real need for C++ these days. OTOH, if you are trying to do something serious (control a tank or airplane, write an OpenGL or DirectX application), fold proteins, write ocean current models, etc., Skinny help you if you try to do this in JAVA or .NET. Use the right tool for the job. My job requires a swiss army knife, your's needs a folding knife, doc's needs a scapel.

[Nick Bogaerts]

Originally Posted by Wowbagger

What do you think?

That of the four languages you mention, I only like C. C++ (and likewise Objective-C) has two orthogonal feature sets layered on top of one another, procedural and OO, which haven't been integrated together very well. C++ has the misfortune of neither being the simple, clear system-level programming language that C is, or possessing any of the advanced abstractions high level languages provide. Linus Torvalds summarized it quite well after a rather (in)famous rant against C++:

Quote:

And if you want a fancier language, C++ is absolutely the worst one to choose. If you want real high-level, pick one that has true high-level features like garbage collection or a good system integration, rather than something that lacks both the sparseness and straightforwardness of C, and doesn't even have the high-level bindings to important concepts.

http://thread.gmane.org/gmane.comp.v...trol.git/57960

Nonetheless, I think there are places where C++ is the correct choice, but it's much smaller than what it is used for, and it's not somewhere I feel particularly comfortable.

Regarding Java / C#, my dislike comes mostly from a personal bias against static typing in high-level languages. Of the two, Java has a much nicer ecosystem surrounding it, the VB/C# CLI is not a particularly judicious idea, making the languages effectively interchangeable, rather than capitalising on any strength either could have on it's own, especially compared to the way Java bytecode enables both Groovy and Clojure, two quite interesting languages so far as I can tell. Groovy I've now used on one project, with another coming up, and it's been a pleasant experience. Clojure I'm still merely toying with.

Also, the part of .NET I'm familiar with (ASP.NET) is simply ghastly. I don't know if it's true for the rest of it, but I don't have much motivation to find out.

[Wowbagger]

Originally Posted by Nick Bogaerts

Also, the part of .NET I'm familiar with (ASP.NET) is simply ghastly. I don't know if it's true for the rest of it, but I don't have much motivation to find out.

Today, I am inclined to think that ASP.NET 1.1 was rather ghastly. Have you seen the newer versions? They are substantially less ghastly, since the advent of partial classes, Master pages, generics, improved @page properties, and other things.

[Christian Klippel]

Every language has it's application. However, personally i think that if you want to write fast applications that run cross-platform, you are best served with C++.

C/C++ is a well standardized and widely used language set. As others have said, C can get as close to the bare metal as is possible using a high-level language. Some say that C is a high-level assembler. You can inline assembly code if you really need the last percent of speed available. You can do nice OO programming with C++, and you can nicely glue all that together.

Yes, C++ may have some shortcomings, but with stuff like the Boost libraries and the QT toolkit you can do a hell lot of things very nicely.

Java is nice, sure. But it also is a resource-hog, and most of the time rather slow. Yes, you can compile Java code into a pure binary nowdays, and many Java-VM's can use a JIT compiler to speed up as it executes. But compiling the code takes away the benefit of Java's "run everywhere directly" approach. I mean, if you are going to compile Java, why not compile C++?

JIT compilers are nice but can introduce nasty bugs. In any case, as soon as you need something with a GUI, Java is virtually a no-go. The AWT/Swing framework may or may not work the same on different machines, it may not even be the same between different Java VM's. I have seen nasty stuff with that, like buttons/sliders working fine in one VM, but were unusable in another. Or font's, or, or, or. Also, AWT/Swing is horribly slow, because it is completely unaccelerated. Everything is done pixel-by-pixel, and in Java code for most of the stuff. Maybe that changes somedays, maybe it already started to change, dunno. Haven't used it for quite some while now.

Can't say much about C#, since i never used it. However, i'm skeptical about it. You are definitely going to depend on the good will of Microsoft. There are "free" implementations like Mono, but there is always the patent threat which may void it one day. Microsoft may decide to take royalities from programmers that commercially distribute applications written in C#, simply for using their framework/libraries. Don't get me wrong, i'm not about to bash Microsoft, i'm just sceptical because of their behavior in the past.

Greetings,

Chris

[Z]

10 REM FORUM POST
20 OPEN THREAD "http://forums.randi.org/showthread.php?t=148152" /NP
30 PRINT "I had a huge gap in my computer interactions. I grew up programming in BASIC, with some work in CoBOL, and a little exposure to FORTRAN.

Then, I went into the military and had little time to learn much of what was going on in the computer world.

I came out, and suddenly it's Java and C++ and LISP... I'm way behind. Took the Visual Basic class at college - it's like programming for people who don't know how to program. I mean, you get in to some of the basics of a program, like For...Next loops and such, but so much of it is written for you, behind the scenes... and I'm totally lost now. I can still whip up a good program in BASIC, but I don't know now what you do to translate that into a good common language.

I've looked into the simple route - __program language of choice__ for Dummies (hey, it worked great for HTML and Flash), but there are so many language and language variants out there, that I honestly don't know where to start.

I'll be lurking on this thread to get a good idea where to start - so far, it seems like the three top contenders are C++, C#, and Java. I'm primarily interested in Windows program writing, because that's what I'm using myself... so please, carry on with the debate."
35 CLOSE THREAD
40 END

[dasmiller]

Originally Posted by roger

Well, I wouldn't say "encourages". I definitely would say "allows". Should a irresponsible person drive a 550HP, 9" raised rock crawler on the street? Probably not. They'd tip it over in a serious corner, it makes it easy to pull shenanigans in a parking lot (who hasn't seen some idiot driving their truck over a table sized rock or something to park someplace stupid and illegal), drag race at lights, etc. In the hands of somebody who knows what the tool is for, it's perfect for it's job, and nothing else works as well. "But it's so easy to drive to fast for a corner, and the CG is so high it'll tip over!" bewails the reader. Um, ya. It's a tool for going over a house size boulder at 2mph, and perhaps drive carefully at the speed limit on public roads. Not for beginners.

I have some sympathy for that line of thought, but it seems to me that C/C++ include features that you should never use. That, in turn, means that things that should be compile errors become hard-to-track bugs. For example, on one occasion, I spent hours time tracking down a bug that stemmed from the fact that the function declaration in the header file used different variable names than the function's implmentation (x, y vs. y, x - d'oh!). But that's a "feature?"

Originally Posted by roger

If you are writing a typical GUI application that takes some user input, stores it somewhere, processes it a bit, and displays the result, there's no real need for C++ these days. OTOH, if you are trying to do something serious (control a tank or airplane, write an OpenGL or DirectX application), fold proteins, write ocean current models, etc.,.Skinny help you if you try to do this in JAVA or .NET.

I'm curious on that last one. I've done DirectX programming in C#, and I'm not clear on why it would be significantly easier (or harder, for that matter) in C++.

Originally Posted by roger

Use the right tool for the job. My job requires a swiss army knife, your's needs a folding knife, doc's needs a scapel.

No argument there.

[dasmiller]

Originally Posted by Christian Klippel

Can't say much about C#, since i never used it. However, i'm skeptical about it. You are definitely going to depend on the good will of Microsoft. There are "free" implementations like Mono, but there is always the patent threat which may void it one day. Microsoft may decide to take royalities from programmers that commercially distribute applications written in C#, simply for using their framework/libraries. Don't get me wrong, i'm not about to bash Microsoft, i'm just sceptical because of their behavior in the past.

C# is my language-of-choice for a lot of things, but I definitely share your misgivings.

[dasmiller]

Originally Posted by Z

I'll be lurking on this thread to get a good idea where to start - so far, it seems like the three top contenders are C++, C#, and Java. I'm primarily interested in Windows program writing, because that's what I'm using myself... so please, carry on with the debate."

If you're just doing Windows, the Microsoft Express editions of C++ and C# have good IDEs without any fiddling around to get the various pieces assembled and playing nicely; I haven't had that experience with Java yet. And if you're used to the VB IDE, the C++ and C# IDEs should look very familiar.

[Z]

Originally Posted by dasmiller

If you're just doing Windows, the Microsoft Express editions of C++ and C# have good IDEs without any fiddling around to get the various pieces assembled and playing nicely; I haven't had that experience with Java yet. And if you're used to the VB IDE, the C++ and C# IDEs should look very familiar.

That's fairly encouraging.

I guess one of my problems with computing today - much like my problem with website building - is that so much of it is done for me that I feel like I really don't know what I'm doing, exactly. I know it's much more complex than it was in the days when you POKE'd and PEEK'd your memory addresses, and that it's probably a lot nicer to have all those DATA elements pre-done for you... but it's still weird to me to just slap the elements together, write a few pieces of code to tie it all up, and claim I programmed it.

I'll still open NotePad and write web pages by hand sometimes, and then go in to Expressions Web or Dreamweaver and tweak them up a bit; but I'm so far behind the curve on programming I can't really do that with programs any more. I'm re-learning How It's Done Today, but what I really need is some way to fill in the gap from writing graphics programs on Apple II GS and video games on C-128s to the stuff done today...

OTOH, it's easy to make applications in just a few minutes. One thing I can't figure out - what are the usual methods for randomization? I remember in BASIC we had a way to do it that looked something like:

A = INT(RND(1)*100)+1

that would produce a random integer from 1 to 100 - how on earth do we do that now?

Well... back to lurk for me.

[Christian Klippel]

Hello dasmiller,

Originally Posted by dasmiller

For example, on one occasion, I spent hours time tracking down a bug that stemmed from the fact that the function declaration in the header file used different variable names than the function's implmentation (x, y vs. y, x - d'oh!). But that's a "feature?"

may i ask you what compiler you used? Because i never ever had that problem. What matters in the declaration is that the type(s) of the argument(s) match the implementation. The names are completely irrelevant usually. I know that _some_ compilers can generate, if instructed to do so, empty implementations of a function if there is no implementation given in the source, but only the declaration.

If you really had that bug because of only the names, i would tend to say that this is a severe bug in the compiler instead.

On a sidenote, you don't need to give any variable names in the declaration at all. Something like "int myfunc(int, int);" should be enough.

Greetings,

Chris

[laca]

Originally Posted by roger

Well, I mostly adore C++, for the reasons others criticize it. Bjarne's book on how and why he designed C++ the way he did is very instructive for those who disparage the language. Much like in the OP, people complain that it contains a hodge podge of features. Rather than a hodge podge, he built the language over a number of years, adding features that were needed, and not adding, or removing, features that didn't add a lot. His guiding principle through all of this was empericism. Study what features use and how they use it, and then support that usage. The language, for example, is OO neutral. You can use OO if you want, and not use it if you don't. You can write functional programming (such as STL), or not. You can write very close to the metal, or you can write at a very high abstraction level. Sure, it has warts due to his desire to remain compatible with C, but all in all it works. The result is definitely a "professional" language - you need to study and work hard to become conversant in it, you need to use modern tools (a strong IDE, debugger, and runtime memory and resource leak detector. But given that, you can be amazingly productive in it. I recall a few guys at my place of work who for some reason decided they were going to rewrite an application I did using more "modern" tools. They spent the next several months fighting these tools because the high level of abstraction and reliance on prewritten APIs meant you had to do things 'their way'. One guy would spend hours on the phone to Microsoft support. He found quite a few bugs in their code in the process. But mostly he fought the tools we was working with, while extolling their virtues, and talking about how much more flexible the code would end up being. Meanwhile I turned the app into a production system, quickly added features when asked, etc. All that other work got scrapped. Dumb. I still don't understand why my boss allowed that - the guy that was hired and made the argument to do it had a high opinion of his own skills, and I think he managed to paint me as a reactionary or something, while promising a magic bullet.

If someone was only interested in programming casually, I'd definitely point them to another language. Super heavy COM work might point to using another language for the main work, sticking to C++ for some heavy duty processing.

People complain about things like pointers in C++, but then it turns out they are using them wrong. Things like pointers to functions are very useful when you are writing things like state machines and event driven models. In the normal course of things, references are far safer and easier to use and keep track of. I don't tend to use pointers often, but when I use them, I really need them. I remember fighting Ada to do some things that would be easy,and perfectly safe, to do with pointers in C or C++. It takes understanding of a feature, and when to use it. I do a lot of hardware level things, so I'm likely to be writing near pure C for device drivers, using pointers and such to handle events, state machines, etc. Then I'll be using OO to help me with interface design, and then functional programming to do STL-type algorithms to manipulate the data coming from the devices. I can do all that easily with one language, and am not forced into an OO straightjacket when it is not the right tool for the job. Do you need to be on the top of your game to write like that? Sure. But being at the top of your game means being at the top of the salary range for your career - not a bad thing, IMO, though it does make it harder to apply for a new job when they hear what you make and seem dubious that you are worth it. I do worry one day I'll end up being a 'COBOL programmer' - maintaining hopelessly outdated legacy systems, but for now I'm trying to stick with C++ for my career.

QFT. Exactly my toughts on this. Of course, much more eloquently than I could ever put it. Thank you, roger.

I love C/C++ because it does what I tell it to do, however braindead it may be (and it usually isn't ). Doesn't get in the middle. Of course, it is also very hard to beat performance-wise in most applications.

[dasmiller]

Originally Posted by Z

That's fairly encouraging.

I guess one of my problems with computing today - much like my problem with website building - is that so much of it is done for me that I feel like I really don't know what I'm doing, exactly. I know it's much more complex than it was in the days when you POKE'd and PEEK'd your memory addresses, and that it's probably a lot nicer to have all those DATA elements pre-done for you... but it's still weird to me to just slap the elements together, write a few pieces of code to tie it all up, and claim I programmed it.

Ahhh - I remember turning down the volume with POKE 53281, 64 (or was it 53280? one was pitch, the other was volume).

(some snipping)

Originally Posted by Z

OTOH, it's easy to make applications in just a few minutes. One thing I can't figure out - what are the usual methods for randomization? I remember in BASIC we had a way to do it that looked something like:

A = INT(RND(1)*100)+1

that would produce a random integer from 1 to 100 - how on earth do we do that now?

Well... back to lurk for me.

C# and Java each have a Random class for just that sort of thing. C++ has rand, which (IIRC) works something like that RND function you mentioned.

[Christian Klippel]

Hello Z,

Originally Posted by Z

One thing I can't figure out - what are the usual methods for randomization? I remember in BASIC we had a way to do it that looked something like:

A = INT(RND(1)*100)+1

that would produce a random integer from 1 to 100 - how on earth do we do that now?

Well... back to lurk for me.

in plain C that would be

A = (rand() % 100) + 1;

to get a value between 1 and 100 (both inclusive). I think your example has a bug, it would give you numbers from 1 to 101 (101 in the case that RND(1) returns 1).

However, in C you also need to seed the random number generator using something like:

srand(time(NULL));

Instead of time(NULL) you can use a fixed value instead, if you need reproducible streams of random numbers upon each startup.

Greetings,

Chris

Edit: in case you wonder, % is the modulo operator. It gives you the remainder of a division. So, 136 % 100 = 36, 593 % 100 = 93, etc...

[roger]

Originally Posted by dasmiller

I'm curious on that last one. I've done DirectX programming in C#, and I'm not clear on why it would be significantly easier (or harder, for that matter) in C++.

Okay, I'm probably wrong on that. I wrote a OpenGL program in straight C++, and then my boss wanted to see if we could switch to a commercial product that used Java, all kinds of third party libraries, all on top of OpenGL. As you might imagine, they had huge performance issues - I'd pop up and start running in a second or two, they'd take a minute to two minutes. And they were hamstrung, having no way to tune all the compenents they were using. But that is more an issue of using third party libraries, not the language. I stand corrected.

[laca]

Originally Posted by Christian Klippel

Hello Z,



in plain C that would be

A = (rand() % 100) + 1;

Yes, that would get a random number between 1 and 100 inclusive. What it won't do is give equal probability to each.

[roger]

Originally Posted by Christian Klippel

Hello dasmiller,



may i ask you what compiler you used? Because i never ever had that problem. What matters in the declaration is that the type(s) of the argument(s) match the implementation. The names are completely irrelevant usually. I know that _some_ compilers can generate, if instructed to do so, empty implementations of a function if there is no implementation given in the source, but only the declaration.s

i think what he was saying was along the lines of:

int secondsfromminutes(int minutes, int seconds);

int secondsfromminutes(int seconds, int minutes)
{
   return (minutes*60) + seconds ;
}

The declaration and implementation assume a different order of variables.

it's an unfortunate side effect of c compatibility. There are plenty more 'gotchas' in there. OTOH, I can't really recall getting caught by many gotchas. Typical industrial strength programming practices (asserts, unit testings, stepping through all new code you write, etc) pretty much catch that stuff. But yes, it's a weakness of the language.

[Z]

Originally Posted by Christian Klippel

Hello Z,



in plain C that would be

A = (rand() % 100) + 1;

to get a value between 1 and 100 (both inclusive). I think your example has a bug, it would give you numbers from 1 to 101 (101 in the case that RND(1) returns 1).

In BASIC - at least the versions I used - the INT(RND) function returned a number from 0.00 to 0.99. Multiplying by 100 gives 0 to 99; hence, you had to add the +1 at the end.

Quote:

However, in C you also need to seed the random number generator using something like:

srand(time(NULL));

Instead of time(NULL) you can use a fixed value instead, if you need reproducible streams of random numbers upon each startup.

Why did we have to start seeding random number generators, anyway? I don't recall, but I thought at least the Commodore took a random seed of the internal clock... I've never quite understood why we have more complex methods now than we did back in the '70s. Like declaring variables in the first place - Oh, I can see it's useful when you specifically want certain variable types, but we just went ahead back in the day and used whatever variables we wanted without declaring them.

And we walked uphill both ways, through ten miles of snow, sleet, and blistering desert heat to get to the computer store...

Quote:

Edit: in case you wonder, % is the modulo operator. It gives you the remainder of a division. So, 136 % 100 = 36, 593 % 100 = 93, etc...

Fascinating.

[Molinaro]

Originally Posted by Z

OTOH, it's easy to make applications in just a few minutes. One thing I can't figure out - what are the usual methods for randomization? I remember in BASIC we had a way to do it that looked something like:

A = INT(RND(1)*100)+1

that would produce a random integer from 1 to 100 - how on earth do we do that now?

Well... back to lurk for me.

In C#

private int RandomNumber(int min, int max) {
   Random random = new Random();
   return random.Next(min, max); 
}

With that function declared, you would get a random number in a desired range via:

aParticularRandomNumber = RandomNumber(1, 100)

[dahduh]

Originally Posted by roger

Well, I mostly adore C++, for the reasons others criticize it. Bjarne's book on how and why he designed C++ the way he did is very instructive for those who disparage the language...

I think Roger nails it. I programmed C++ for many years and used both Stroustrup's book and annotated reference extensively. Then I took a close look at Java and C#, and that's when I realized what a fantastic job Stroustrup did designing the language. Some of the things in C++ look weird or obscure when you first encounter them, but they are the product of years and years of careful thought, and their virtues are glaringly obvious when you look at another language.

Example: why doesn't C++ have garbage collection? For a couple of very good reasons. Firstly, you don't need it! If you adhere to the creation-is-resource-acquisition and destruction-is-resource-release paradigm, and you use stack-based constructors for resource management, you just can't go wrong. Secondly, with garbage collection you can't control exactly when a resource gets released. Thirdly, garbage collection is just very, very inefficient. Fourthly, garbage collection is complicated by mutual references. And so on. Java and C# designers just didn't think through all the implications, and consequently it is difficult to write inherently efficient and well managed code in either of those languages.

Originally Posted by dasmiller

C++ is nearly self-encrypting and encourages a lot of (IMO) bad practices. ETA: Gonna guess that Roger (post #5) has a different perspective on that.

My experience was that bad C++ code was the product of bad programming, not bad language design. C++ is admittedly a very difficult language to master, but well worth the effort. One of the most powerful features of the language is the STL (standard template library), and if you use and extend its patterns you will never see a pointer or even see 'new' and 'delete'. With correct factorization of responsibilities it is possible to write very hierarchical code in which complexity at any given level is close to zero.

Originally Posted by Nick Bogaerts

That of the four languages you mention, I only like C. C++ (and likewise Objective-C) has two orthogonal feature sets layered on top of one another, procedural and OO, which haven't been integrated together very well. C++ has the misfortune of neither being the simple, clear system-level programming language that C is, or possessing any of the advanced abstractions high level languages provide.

I couldn't disagree more. As pointed out by Roger, the ability to span from low-level to very abstract is C++'s great strength. For example, C# is wonderful if you are creating a GUI. But try to manage data efficiently and you are screwed. .NET did introduce templates in version 3 (a belated recognition of a serious omission), but by comparison to the STL its containers suck.

Regarding Torvalds' dislike of C++, I think he just never read Stroustrup's annotated reference early enough. A lot of the C code written for Linux reads like C++ with a 'this' pointer explicitly coded by hand, and the absence of stack-based destructors makes exception handling a huge pain. It's a great pity C++ was not adopted whole-heartedly, but at the time he was developing Linux C++ was still teething so it was perhaps a justifiable call.

So in answer to the OP, if you are creating a serious application use C++, but make sure all of your programmers are well trained and have read Stroustrup's annotated reference. If you are slapping together a lightweight GUI app with low maintenance requirements I suppose C# is ok, but only because it is so easy to interface to .Net and COM. Java is good for keeping you awake. But at the end of the day, its the quality of the programmer that's most important.

[Molinaro]

Originally Posted by roger

i think what he was saying was along the lines of:

int secondsfromminutes(int minutes, int seconds);

int secondsfromminutes(int seconds, int minutes)
{
   return (minutes*60) + seconds ;
}

The declaration and implementation assume a different order of variables.

And what he is saying is that there's no reason to code it as above. Instead you should code:

int secondsfromminutes(int , int);

int secondsfromminutes(int seconds, int minutes)
{
   return (minutes*60) + seconds ;
}

[Z]

Originally Posted by Molinaro

In C#..

private int RandomNumber(int min, int max) {
Random random = new Random();
return random.Next(min, max);
}

With that function declared, you would get a random number in a desired range via:

aParticularRandomNumber = RandomNumber(1, 100)

... wow.

The technology has advanced, and computers can do more than ever before... but to get a random number, we have to type all that rather than the old way... Shouldn't it get easier, rather than harder?

Of course, I'm still having trouble wrapping my head around using variable names that are actually names (makes debugging a HELL of a lot easier though) rather than just single or double characters....

[Molinaro]

Originally Posted by dahduh

My experience was that bad C++ code was the product of bad programming, not bad language design.

That's been my experience. Bad programmers do bad things wherever the language allows. Good programmers don't.

I don't mean to be flippant or shrug off any responsibility the language design bears towards ensuring good code, however I do feel most of the blame lies with the programmer when things go bad.

[aggle-rithm]

When you're doing bit-fiddling with binary files, it's got to be C++. Using a language that hides pointers in that situation is like threading a needle wearing boxing gloves.

[jsiv]

Originally Posted by roger

Okay, I'm probably wrong on that. I wrote a OpenGL program in straight C++, and then my boss wanted to see if we could switch to a commercial product that used Java, all kinds of third party libraries, all on top of OpenGL. As you might imagine, they had huge performance issues - I'd pop up and start running in a second or two, they'd take a minute to two minutes. And they were hamstrung, having no way to tune all the compenents they were using. But that is more an issue of using third party libraries, not the language. I stand corrected.

You're not really wrong. There are performance issues, not necessarily to the extent you're describing, but it can still be as much as 20%.

In fact, Microsoft discontinued the .NET classes for Direct3D years ago because the people who care about direct access to D3D tend to also care about performance and can't live with the .NET limitations, while the rest didn't really need it anyway and can just settle for the more abstract interfaces like WPF or XNA.

Originally Posted by Z

The technology has advanced, and computers can do more than ever before... but to get a random number, we have to type all that rather than the old way... Shouldn't it get easier, rather than harder?

Well, the auto-completion features of Visual Studio are excellent (and context-sensitive), so you don't actually have to type that much.

Originally Posted by aggle-rithm

When you're doing bit-fiddling with binary files, it's got to be C++. Using a language that hides pointers in that situation is like threading a needle wearing boxing gloves.

If you want to do that kind of stuff though, you still have the option of separating that component out into native code and simply calling it from your .NET/Java application. That's done all the time.

[dasmiller]

Originally Posted by Christian Klippel

Hello dasmiller,

may i ask you what compiler you used? Because i never ever had that problem. What matters in the declaration is that the type(s) of the argument(s) match the implementation. The names are completely irrelevant usually. I know that _some_ compilers can generate, if instructed to do so, empty implementations of a function if there is no implementation given in the source, but only the declaration.

If you really had that bug because of only the names, i would tend to say that this is a severe bug in the compiler instead.

Oh, I think the compiler was working just fine. The types were the same, but by allowing different param names in the header vs. the body, the function looked different to the outside world.

It was many years ago - Visual Studio 1.5 or so. The problem, as I recall, was something like:

buggyfunction.h
function ArcTan2(double x, double y): double

buggyfunction.cpp
function ArcTan2(double y, double x): double
{
// a bunch of code here
}

So the bug was that the routines that called ArcTan2 weren't getting the answer that they expected.

Yes, my bad for switching the names - but if I'm trying to write code that's easy to maintain, why would I ever want the declaration names to be different from the implementation names? I'm intending that as a rhetorical question, but there may be a real answer.

Anyway, since then, I really try to work the parameter order into the function name if I have multiple params with the same type. In a case like that, I'd call it "ArcTan2YX" or some such, although I'm guessing that the standard C++ libraries have a 2-argument arctangent function and of course I'd use that rather than rolling my own.

Originally Posted by Christian Klippel

On a sidenote, you don't need to give any variable names in the declaration at all. Something like "int myfunc(int, int);" should be enough.

When there's only one argument, and it's obvious what the argument should represent (say, Sqrt, for example) then the name isn't terribly important. But if it's possible to guess wrong about what the arguments are, or what order they go in, then there should be names there to help the poor sot who's trying to maintain the code 5 years later. Sure, that's what comments are for, but in my (limited) experience, the guys (it's always the guys . . . ) who take a lot of hard-to-maintain shortcuts are also the ones with really thin comments.

And then they get grumpy when you complain the lack of comments, and they'll give you helpful comments like:

function InitializeThing(double, pointer, double, int, pointer, int, double): void; // initializes a Thing.

Okay, I'm digressing a bit.

YMMV. A lot of people with far more coding experience than I have weighed in on both sides of these things.

[Richard Masters]

Originally Posted by Wowbagger

...
I happen to use C# the most (when I am not stuck with VB). But, perhaps that is mostly due to historic accident. I have always been a Microsoft-platform developer, in my professional career, and I suppose there is little chance of that changing, any time soon.

What do you think?

I hope it stays that way. I like C#, though C and C++ are important for some high-performance applications. You can use pointers in C#, however.

[Molinaro]

Originally Posted by aggle-rithm

When you're doing bit-fiddling with binary files, it's got to be C++. Using a language that hides pointers in that situation is like threading a needle wearing boxing gloves.

That reminds me of a project I did as an assignment in University. I decided to make a compression algorithm of my own.

My goal was to make it compress well, with no concern for the time it takes to compress.

So, I scanned the file tabulating the frequency of all single byte characters.

The compressed file would then be built as follows:

1) Header: 3 byte string "KEN", since I called it kenpression, and my name is Ken.

2) Table: 256 bytes, of values 0-255, each occuring once, ordered from that tabulated as highest frequency, to lowest frequency in the file to compress.

3) Compressed data, with each piece being a variable length piece of data. The first 3 bits defines the length, and the subsequent bits being the data.

Data Length      Number of Codes                Codes
0                       1                  000
1                       2                  0010 and 0011
2                       4                  01000, 01001, 01010 and 01011
.
.

When I tested it, it seemed to compress most everything down to about 60% of it's original size. This was a short 3 day assignment, and I didn't do any testing on pathological data, or include any pre-compression with a RLE algorithm or anything like that.

My point being, I can't imagine how you would pack those variable bit length pieces of data, and extract them out to 8 bit bytes later, without a language like C/C++ to work with.

[dahduh]

Originally Posted by Molinaro

In C#

private int RandomNumber(int min, int max) {
   Random random = new Random();
   return random.Next(min, max); 
}

This is how you would print 100 random numbers in C++

Quote:

generate_n(ostream_iterator<double>(cout, "\n"), 100, rand);

[roger]

Originally Posted by Molinaro

And what he is saying is that there's no reason to code it as above. Instead you should code:

int secondsfromminutes(int , int);

int secondsfromminutes(int seconds, int minutes)
{
   return (minutes*60) + seconds ;
}

That changes nothing. If the caller thinks the order is minutes/seconds, and the implementer thinks the order is seconds/minutes, you still have the same problem.

I also very,very strongly disagree with the 'should' in your post. I think that is a terrible practice. For several reasons. With which I will now bore you with

Declarations are often all you get to see with commercial code where source code is not provided. Declarations should be extremely readable. To me, readable means sufficient, but no more than necessary comments.

How many times have you bought some commercial library, opened up the .h file, and seen:

int function1 (int, float, int);
int function2 (int, int, int);
int function3(int, ....)

(assume 'function' is replaced with a meaningful name)

How on earth do you use these functions? Who can tell? No comments, no variable names, etc. On the other hand:

Seconds TimeSinceMidnight (int hour, int minutes, int seconds)

is much more readable, and doesn't require much in the way of comments or printed documentation.

Of course I'd suggest using classes rather than built in types. Built in types are likely to cause problems - it's not robust programming by any means. In that case we'd have

Seconds TimeSinceMidnight (HMS thetime);

where HMS is a hours/minutes/seconds class. This example would perhaps be more obvious with dates, where europeans and americans order month and day differently.

I've seen so much code where programmers just write a minimal declaration, then put a very descriptive paragraph long comment in front of the implementation. This is horrible practice, IMO. First, we should be striving for reusable code. I don't mean code that you can plug into another application, I mean realizing that code will be used, and maintained, for decases. Each time you force a programmer to open a .cpp file to figure out how something works, you are increasing complexity. It takes longer to find the function and readability suffers. A robust class often has several related methods. Take the HMS class I alluded to earlier. you can imagine it probably has several functions to extract various values from it (hours, minutes), several other functions to assign values to it, and then more functions to manipulate it (add, subtract, etc). page, page, page, through the cpp file to figure that out, or just look at a concise header file and you'll understand 90% of the class and how to use it. For example (I'm typing this ad hoc, there will be mistakes:

// ~10 lines of instructions for class usage goes here
class HMS
{
private:
    HMS ();
public:
   // assignment functions
   friend HMS AssignHMS (int hours, int minutes, int seconds);
   friend HMS Seconds (int seconds);
   ... and a few more


   // arithmetic operators
   HMS operator+ (const HMS& time);
   ... etc
};

You can look at that, and pretty much figure out how to use it, all without opening a cpp file. Studies show that if you have to look at more than one screenful of code to understand something, comprehension falls rapidly, and errors multiply.

This is why I hate languages like Java - declaration and implementation all mixed together in one file. Page, page, page, just to try to discover what the class does. Not to mention this style hamstrings serious efforts at making compiling faster. When you have a million lines, compilation time maters.

Plus, the cpp files are where the programming goes on. You should only be looking at that to fix a bug. If you have to read the cpp file just to figure out what a function does, the programmer failed, seriously failed, at commenting or documenting the code. Your refusal to write 5 minutes of comments just cost each programmer 10 minutes (minimum) digging through your code. Ever tried to figure out a modestly sized program (say, 10000 lines) with bad comments, where you have to read code to figure things out? That's several days of work, easy. So, comments and variable naming in headers to explain what is done, and then commments in the cpp file to explain how and why. If you sell your code, and retain your IP, you pretty much have to do it this way anyway; why not remain consistant when the result is so readable and useful anyway?

Anyway, the way C++ does things is well thought out, but it does require discipline and knowledge. Stroustrup expected code to be written as I did it above. Fail to do that and you'll run into the issue complained about. An unfortunate side effect of the C legacy. IIRC, Ada forced the names to be the same - no bugs that way.

Incidentally, I really enjoyed how Ada had you call functions - it made code more readable. I can't remember my Ada anymore, but in C it would look like:

HANDLE CreateButton (int color, int width, int height);

HANDLE h = CreateButton  (color => red, width=>50, height=>20);

edit: my perception comes from writing industrial strength code where lives are at stake. First cancer research, then aircraft flight computers, then flight planners and 3D black box playback software, and now autonomous weapons systems. You don't make mistakes in this kind of code, and you write defensively and robustly, fully expecting the code to be around for decades. I still use every day code I wrote 15 years ago, in completely different applications. (things like great circle math, speed/distance/time calculations, that kind of jazz). Once you get used to programming that way, you program everything that way, even through away GUI applications. With some obvious exceptions, what works for difficult problems works for easy ones, for the same reasons. I'll admit I'll through the occasional int around in some quick and dirty stuff I write, but a lot of that is forced anyway when you work with the Windows API, where WORD and stuff is the order of the day. Anything not GUI tends to eschew built in types.

[Wowbagger]

Originally Posted by Molinaro

In C#

private int RandomNumber(int min, int max) {
   Random random = new Random();
   return random.Next(min, max); 
}

With that function declared, you would get a random number in a desired range via:

aParticularRandomNumber = RandomNumber(1, 100)

Just one correction needed, (which is something that always bugged me): The first parameter of the Next function is inclusive, and the second one is exclusive. That means your example will only give you a random number from 1 to 99.

You can correct for that, by pre-incrementing the second parameter:

private int RandomNumber(int min, int max) {
   Random random = new Random();
   return random.Next(min, ++max); 
}

(Note: the ++ in front of the max.)

You can also enhance the randomness by initializing the random object with clock ticks, like this:

Random random = new Random((int)DateTime.Now.Ticks & int.MaxValue);

[Nick Bogaerts]

Originally Posted by Wowbagger

Today, I am inclined to think that ASP.NET 1.1 was rather ghastly. Have you seen the newer versions? They are substantially less ghastly, since the advent of partial classes, Master pages, generics, improved @page properties, and other things.

Yes, I'm talking 2.0 and/or 3.5 here. It's not that there's anything glaringly and obviously wrong with the overall design, it's just that as soon as I get into the details I always get caught out by some random and unexplainable misfeature.

For instance, try adding optgroup tags to asp DropDownList and tell me how you get on. Or adding classes to radio buttons and/o checkboxes without having it wrapped in a span you never asked for or wanted, with the class stuck to the span. Or having an asp: RadioButtonList not generate a table element that's going to make any screen reader choke. Or making an asp:LinkButton work without Javascript. Or, for complete hilarity, put asp:RadioButtons inside a Repeater, and try to make them all part of the same group.

Unfortunately, web accessibility is my bread and butter, and as a framework, the sheer amount of things which simply don't work make ASP.NET so completely unreliable it's a struggle every day just to make websites comply with the Disability Discrimination Act to the client's satisfaction. It has neither the power and control-freakery that I get from using naked Perl or PHP, nor the convenience of using a modern web app framework such as Ruby On Rails.

[dasmiller]

Originally Posted by dahduh

Example: why doesn't C++ have garbage collection? For a couple of very good reasons. Firstly, you don't need it! If you adhere to the creation-is-resource-acquisition and destruction-is-resource-release paradigm, and you use stack-based constructors for resource management, you just can't go wrong. Secondly, with garbage collection you can't control exactly when a resource gets released. Thirdly, garbage collection is just very, very inefficient. Fourthly, garbage collection is complicated by mutual references. And so on. Java and C# designers just didn't think through all the implications, and consequently it is difficult to write inherently efficient and well managed code in either of those languages.

Garbage collection is a trade-off. If your app is constantly creating & destroying thousands of little objects, then C#'s garbage collection could certainly cause problems. If you've got a more stable population of objects, then garbage collection can help you avoid some messy bugs. True, if you'd coded it up properly, the bugs wouldn't be there in the first place, but the garbage collector is less likely to make those sorts of mistakes than I am.

So I'd argue that garbage collection doesn't make it more difficult to have well-managed code (mutual references can be a real headache with non-garbage-collected languages, too). But I certainly agree on the efficiency part.

As for whether the C# and Java designers didn't think through the implications of garbage collection, C# was architected by Anders Hejlsberg, and he was very familiar with the Java practice when he started on C#.

Originally Posted by dahduh

My experience was that bad C++ code was the product of bad programming, not bad language design.

Well, certainly, bad code is a result of bad programming, and no language is so good that it will keep a bad programmer from making bad code. But there's something to be said for a language that nudges a bad programmer to do things less badly, or tolerates some poor code. And even good programmers have bad days.

Originally Posted by dahduh

But at the end of the day, its the quality of the programmer that's most important.

Absolutely. A great programmer with a mediocre language & environment is much more productive than an average programmer with a great language & environment.

And enormously more productive than a huge team of average programmers with a few mediocre team leads working to a schedule developed by a marketing group.

[Christian Klippel]

Originally Posted by Z

In BASIC - at least the versions I used - the INT(RND) function returned a number from 0.00 to 0.99. Multiplying by 100 gives 0 to 99; hence, you had to add the +1 at the end.

Ahh, didn't know that. My Basic experience is obviously older than the data retention time of my brain

Originally Posted by Z

Why did we have to start seeding random number generators, anyway?

Well, "back then" we didn't care much about encryption, key-exchange, challenge-response methods, and the like. Also, we did not do much video or image editing on computers anyway.

Imagine you want to contact another machine somewhat securely. So you use an encrypted channel. You also use random numbers in the encryption algorithm. Now, both sides have to start at the same place in the random sequence to make it work. So, you seed the RNG first.

Another example: Imagine you want to render noise or something else depending on random numbers into video footage. You have 10 machines that can render different parts of the frame each, all at the same time. Here, again, you want to have all machines have the same random number sequence, so you seed it.

Greetings,

Chris

[dasmiller]

Originally Posted by Z

Why did we have to start seeding random number generators, anyway?

I've found it very useful when testing/debugging. Suppose you're testing a game, and it crashes after a minute or two. There may have been thousands of random number calls that got it to that point, and if you run the code again, it's unlikely to ever get to exactly the same condition.

But suppose that you had seeded the random number generator with, say, 14. Now, if you run the code again and seed with 14 again, it will go through exactly the same sequence of random numbers and go to exactly the same point that crashed before.

ETA: what Chris Klippel said.