Ah, but there's a difference between "I've learned all the C++ there is to learn" and "Okay, enough is enough". Most of us don't want to learn everything C++ has to offer because we simply won't use it. In cases like that it's practical to determine the point at which you can stop an intensive focus because any more would be wasted effort. Such effort would be better spent learning something we actually intend to use.

Personally, I find that learning doesn't really stop, it just becomes more passive (as long as you do continue to use C++ of course). I suspect the poster who said "I'm still learning C++ after 10 years" only spent 1 or 2 years of that time actually intensively studying the language, as so much else comes down to raw experience.
Somehow, it is almost impossible to stop learning - Kinda like playing the guitar - You begin with playing tunes which other people have written... then you move on to writing your own songs.

03-01-2006

Ancient Dragon

Quote:

Originally Posted by Prelude

>What C can do that C++ can't?
Work on some embedded systems that can't handle C++.

that only means the target compiler cannot compile c++ code, a c++ compiler has not been written for that os. It doesn't mean the os can't run a program written in c++. Once compiled down to executable machine code there is no difference at all. The program written in c++ will probably be larger than the program written in c, but the os will not be able to tell the difference when the compiled program is run.

And the ability to run on any given operating system is not a function (or feature) of any programming language. There is nothing at all in either the C or C++ ansi standards that say the language cannot be run on embedded systems. Some embedded systerms do not even have a C compiler, let alone a c++ compiler, while other embedded systems have both C and C++ compilers, as well as support java, basic and other computer languages.

03-01-2006

Daved

>> Where can I see those instances? What are they? I only want to know.

One example is a string. With C++ you have greater overhead and less consistency with your strings. If you want to minimize the size of memory used for a bunch of strings in your app, with C you can identify the exact amount of memory that will be used and be confident that it will be consistent when you move the code to other platforms. That is not the case when you program with C++.

03-02-2006

Wraithan

Quote:

Originally Posted by SlyMaelstrom

Get very comfortable with C++ to the point that you feel you could get an entry level job with your knowledge in it, then you could break into learning other languages such as Java, PHP, Delphi/Object Pascal and older languages such as C.

This is basically what I did, I learned to program in C++, and now can do alright in it. Got myself a job programming, after 3 months of working there I have yet to write a single line of C++, but all the programming I had done with C++ made it so I could pick up Perl in 2ish days, PHP in like a week, and now I am learning java. I was biased to a single langauge when I started my job. Now I don't even think to hard about it. It just seems natural what langauge to use for different jobs because they are all better than another langauge at something.

I have started to pick up a little C in my spare time, haven't really programmed in it, just used some embeded in some Perl. I can't see a good reason unless it is job specific to go out and learn C, after programming for a while, you will be able to read just about any langauge see what it is doing, and if needed add onto it. That is how I started to learn java, has worked alright for me so far.

EDIT: Removed the discaimer thing I had in my post, doesn't have much to do with the OP.

03-02-2006

Prelude

>Nothing other than that?
You were expecting more? No offense, but people who aren't proficient with both C and C++ tend to have trouble seeing why C is still needed when C++ can pretty much do everything that C can and makes many things easier. Unfortunately, it's also impossible to explain the distinction. :o

>I find that learning doesn't really stop
If you use C++, you can't keep from learning things here and there. What I'm talking about is actively teaching yourself rather than simply picking things up through writing code and talking to other programmers.

03-02-2006

ChaosEngine

Quote:

Originally Posted by Wraithan

**DISCLAIMER** I do not condone the use of java for anything but web applications, I am opposed to it and .NET(and any other language that requires a RTE and is not an interpreted language) for regular applications.

any particular reason for this bias?

so you don't approve of C++ then? Many C++ implementations put the standard library (the non-templated part) in a seperate "C run time" dll (ala msvcrt.dll) and it's certainly not interpreted.

but your sentence doesn't even make sense. You say you are opposed to java and .net and languages that require RTEs that are not interpreted. Both Java and .Net are intrepeted languages! Sure they compile to bytecode, but that's still interpreted.

03-02-2006

SlyMaelstrom

Besides, most employers will take a guy that knows C++ and Java over a guy who knows C++ and hates Java, anyday. Assuming of course they're equal in every other fasion.

03-02-2006

Prelude

>most employers will take a guy that knows C++ and Java over a guy who knows C++ and hates Java
Only a fool forms an opinion about something he doesn't fully understand. Be wary of assuming that those of us who hate Java aren't proficient with it. ;)

03-02-2006

SlyMaelstrom

Right, well I guess that's true.

03-02-2006

Wraithan

RTEs, from every implementation of them, all they have done is help for RAD and slow down the end resulting program, especially during start up. What I should have said instead of interpreted is a scripting language. I have never found or seen a good impletmentation of RTEs in a product that was distributed. For internet applications I can see it being alright, you don't have the RTE to load because it is already loaded, and generally the servers have the power that the difference is minimal in effeciency.

If you can give a couple good examples of where RTEs are better than than none RTE alternatives other than RAD, I would like to see it.

03-02-2006

Rashakil Fol

Emacs

03-02-2006

ChaosEngine

Quote:

Originally Posted by Wraithan

If you can give a couple good examples of where RTEs are better than than none RTE alternatives other than RAD, I would like to see it.

you're really not gonna like this, but for all but the most performance intensive applications (or conversely the least powerful embedded platforms), efficency doesn't really matter. Well, it matters, but it's not as important as stability, readability, flexibiltity and time to market.

A languages power is more important then its speed.

have a read of paul graham (one of the people to pioneer e-comerce). There's a good lesson in that article (it turns into a bit of a LISP love letter, but the point is still valid).