C vs C++ or any C varient

D

Dynafrom

Gawd
Joined
May 28, 2006
Messages
628
I'm a computer science student and I'm trying to figure why on earth I'm learning C instead of C++ (which tends to be quite popular). Right now I'm taking a course on unix system programming and TBH unix looks like ass. I hate using the terminal, and I hate using emacs to write code. It seems outdated, am I wrong or does the industry use what I'm doing?

and can't unix compile and run C++? Isn't it just as portable?

oh yeah I'm on solaris
 
Its good to have a solid understanding of procedural software. Bitching about learning C before C++ is like bitching about practicing scuba diving in a pool or lake before going into a shipwreck.

And using a single terminal and unix is a bit "dated", there are big fancy IDE's available, but there is benefit to what they are having you do because it gives you a better understanding of whats going on. It's also good to have exposure to other systems, and if you use unix machines a lot you'll be amazed at the wealth of tools they come installed with.

Lastly, unix is an operating system. Unix cannot compile anything. Nor can windows. Whether you can build c++ programs depends on if there are compilers installed on the lab computers. With that said, the unix lab computers almost surely have a ton of compilers installed.
 
"Variant", just sayin'.

People "in the industry" might not use emacs, but there are many other character-mode editors that are popular. Certainly, everyone uses the terminal or a console window; I have about four dozen such windows open at the moment.

Unix systems have C++, yes.

Using C instead of C++ is orthogonal to using emacs and a terminal window. I can't guess what it is about the "looks" of Unix you specifically object to.
 
C++ is just C with a bunch of extensions.
The original C++ used a precompiler to convert all the code to C.
Some things are "easier" to do in C++, but all the same it is good to have a good understanding of C.
To really dig into C++ you have to get into all the "object" concepts which increases complexity exponentially.
 
I'm a big fan of teaching C prior to teaching C++. For most purposes one can consider C a subset of C++ (and I just sent mikeblas into an apoplectic fit). Pretty much all the stuff you're learning about with C will directly apply when you go to learn C++. To use an analogy, I'd liken it learning to float before learning to swim. Trying to swim without knowing how to float is just going to cause you pain and get you nowhere fast. I've watched people get introduced to programming with an OO-based course and they spend the entire semester floundering never really understanding either the OO nor the procedural concepts.

As for "the industry", it depends on what you do. Personally I work on embedded systems; terminal-access is kind of how that works. (I will note though that vi is far more supported than emacs on such systems though) If you're doing internal business apps for some corporation, then who knows, you may be doing all VB apps to interface with an access database or something equally silly and never need to worry about developing for a different target.

I will note though that I don't spend hours a day typing into a terminal window. I code in a IDE, even if I'm targeting some other platform. I'll just compile/test it remotely and depending on how much a pain deploying is (some secure OSes require a reboot) tweak code remotely and then bring fixes back to my IDE environment. I do admit being curious though why you haven't done the same given your dislike for emacs? Just code on your desktop and ftp to the school's server to compile/test. Or if you're doing nothing hardware/OS dependent, test on your end and then once it's working there do a final test or two on the school's Solaris system?
 
if STL were still around he'd have a field day with this thread.... anyway...
 
Whatsisname said:
Its good to have a solid understanding of procedural software. Bitching about learning C before C++ is like bitching about practicing scuba diving in a pool or lake before going into a shipwreck.

And using a single terminal and unix is a bit "dated", there are big fancy IDE's available, but there is benefit to what they are having you do because it gives you a better understanding of whats going on. It's also good to have exposure to other systems, and if you use unix machines a lot you'll be amazed at the wealth of tools they come installed with.

Lastly, unix is an operating system. Unix cannot compile anything. Nor can windows. Whether you can build c++ programs depends on if there are compilers installed on the lab computers. With that said, the unix lab computers almost surely have a ton of compilers installed.
Click to expand...

Yeah I didn't mean using the OS to compile software, I use the gcc compiler.
 
Khanmots said:
I'm a big fan of teaching C prior to teaching C++. For most purposes one can consider C a subset of C++ (and I just sent mikeblas into an apoplectic fit). Pretty much all the stuff you're learning about with C will directly apply when you go to learn C++. To use an analogy, I'd liken it learning to float before learning to swim. Trying to swim without knowing how to float is just going to cause you pain and get you nowhere fast. I've watched people get introduced to programming with an OO-based course and they spend the entire semester floundering never really understanding either the OO nor the procedural concepts.

As for "the industry", it depends on what you do. Personally I work on embedded systems; terminal-access is kind of how that works. (I will note though that vi is far more supported than emacs on such systems though) If you're doing internal business apps for some corporation, then who knows, you may be doing all VB apps to interface with an access database or something equally silly and never need to worry about developing for a different target.

I will note though that I don't spend hours a day typing into a terminal window. I code in a IDE, even if I'm targeting some other platform. I'll just compile/test it remotely and depending on how much a pain deploying is (some secure OSes require a reboot) tweak code remotely and then bring fixes back to my IDE environment. I do admit being curious though why you haven't done the same given your dislike for emacs? Just code on your desktop and ftp to the school's server to compile/test. Or if you're doing nothing hardware/OS dependent, test on your end and then once it's working there do a final test or two on the school's Solaris system?
Click to expand...


We use putty to connect to a hopper account to use unix. We have no fancy gui or anything. Just a terminal window that displays no color. Inputting code is asinine in this view since I have to personally do all the formatting without the help of using a mouse. :mad:
 
emacs will do much of that formatting for you. Check out the emacs manual or look for info online.

Dynafrom said:
We use putty to connect to a hopper account to use unix. We have no fancy gui or anything. Just a terminal window that displays no color. Inputting code is asinine in this view since I have to personally do all the formatting without the help of using a mouse. :mad:
Click to expand...
 
Dynafrom said:
We use putty to connect to a hopper account to use unix. We have no fancy gui or anything. Just a terminal window that displays no color. Inputting code is asinine in this view since I have to personally do all the formatting without the help of using a mouse. :mad:
Click to expand...

...you might be in the wrong field if this is a major problem for you.

Once you grasp the power of the Unix command line, it's hard to go back to a point and drool interface. You can create some pretty amazing 'programs' without actually 'programming' by stringing together a pipeline of standard Unix utilities.

Similarly, Emacs is an -amazingly- powerful editor (I prefer Vim but that's a different argument). If you haven't learned how to get it doing syntax highlighting & automatic indentation, I suggest you do some googling and learn about modes. If you haven't actually done it yet, set aside an hour or so to go through the built in tutorial (the opening screen when you first start up emacs will tell you how to enter it).

Odds are, if you get a CS degree you'll become a computer programmer. You'll spend the next 20+ years of your life entering text. Learning to efficiently use a powerful text editor will make your life significantly better. The mouse thing? That's crap. Get it out of your head yesterday - every time you take your hands off the keyboard to do something with a mouse, that's lost time. Serious editors are serious tools - learn them & respect them. Within 6mo you'll find yourself laughing at anyone who wants to use notepad or pico/nano.
 
Dynafrom said:
We use putty to connect to a hopper account to use unix. We have no fancy gui or anything. Just a terminal window that displays no color. Inputting code is asinine in this view since I have to personally do all the formatting without the help of using a mouse. :mad:
Click to expand...

And what keeps you from working offline in your fancy gui and uploading your files to test?

Or... putty supports color, get your configuration right and use an appropriate editor and you'll have your syntax highlighting and indentation. Then it's just learning the commands to efficiently navigate in your editor of choice.

Or even grab a copy of xming and see if your server supports that, then you'd have access to *nux GUI IDEs
 
ameoba said:
...you might be in the wrong field if this is a major problem for you.

Once you grasp the power of the Unix command line, it's hard to go back to a point and drool interface. You can create some pretty amazing 'programs' without actually 'programming' by stringing together a pipeline of standard Unix utilities.

Similarly, Emacs is an -amazingly- powerful editor (I prefer Vim but that's a different argument). If you haven't learned how to get it doing syntax highlighting & automatic indentation, I suggest you do some googling and learn about modes. If you haven't actually done it yet, set aside an hour or so to go through the built in tutorial (the opening screen when you first start up emacs will tell you how to enter it).

Odds are, if you get a CS degree you'll become a computer programmer. You'll spend the next 20+ years of your life entering text. Learning to efficiently use a powerful text editor will make your life significantly better. The mouse thing? That's crap. Get it out of your head yesterday - every time you take your hands off the keyboard to do something with a mouse, that's lost time. Serious editors are serious tools - learn them & respect them. Within 6mo you'll find yourself laughing at anyone who wants to use notepad or pico/nano.
Click to expand...

I fully agree here. Emacs is my preferred editor after having used it for about 2 years. There's just something about not having to touch the mouse while writing code that is very liberating for me. Additionally, the terminal is a very powerful tool when you combine it with a half decent shell and a bunch of utilities like gawk, grep, sed, etc.

Would also like to point out that I pretty much had the same questions as the OP with respect to using the terminal and an editor like emacs, but having learned how powerful the terminal really is (and also how powerful emacs is), it's hard to imagine programming without either.
 
Last edited:
I know how you feel. Coming from Eclipse, programming C/C++ under unix or linux can be cumbersome. But you'll get used to it, once you seen enough "stack overflow" error. Of course there are tools like emac, vim, ctags... that can make your life easier, but you might need someone to teach you how to use them.

If you're using Windows, I strongly suggest you to download the latest version of Visual C++ Express. It's free. It has features like breakpoint debug, autocompletion, colored syntax, false syntax detection and will compile C codes the same way as GCC. It will make your programming experience much more enjoyable. But the compiled executable wont work in unix, so you should use it only for prototype or testing.

As for the question: why I am learning C instead of C++? To answer this question you have to understand what C++ is. C++ is made up of four sub-languages:

1. C: Very deep down C++ is based on C. Which means basic constructs like types, variables, array, functions, if- else, loops, pointers are the same in C++ as they are in C.

2. Object Oriented Programming: C++ contains OOP ideas like class, polymorphism, inheritence, encapsulation just like any other high level programming langauge.

3. Template: Generic programming or meta programming

4. STL: a set of library that'll make your life easier. It contains goodies like containers (string, vector etc), algorithms and iterators.

As you can see C is a part of C++. Which means everything you learn in C will carry you on to become a potent C++ programmmer. And most university lecturer knows this, that's why they rather you learn C in an introductory CS course. But I suspect they will use C++ as examples in other courses like OOP, or data structure.
 
I admit my University's CS major and I'd assume many others seem to be too rigidly focused in actual computer science and offer very little for real world software design stuff that most graduates will be dealing with
however I do not regret any off that stuff, not even the hours spent trying to get my makefile to work correctly or dealing with VHDHELL
 
Calling the STL a "sub-language" is a mic-characterization.
 
When I started my CS degree we were taught C++, as opposed to C. At this point though I basically feel like if you know one, the other is just as easy to pick up. Once you're finished...it won't really matter which one you learned imho.

As others have suggested it's in your best interests to get used to the unix command line, chances are you're going to see it again...especially in this field. We used putty as well, and I primarily used nano or vim for everything then compiled with g++. Some of my class mates chose to use an IDE such as visual studio and then just transfer it over...so that is an option but i'd still recommend doing it what may *initially* seem like the hard way. It will pay off in the end.
 
Gotta learn how to walk before you can run. Nothing wrong with using nix for learning.
 
C++ is essentially an object oriented wrapper around C, like Objective-C. You do get the name C++ is a pun? Pretty much anything you learn in C applies to C++.
 
jimmyb said:
That seems like a pretty bad mis-characterization as well.
Click to expand...

That C++ is an object oriented extenstion of C? I'm sure that people much better in the language than me will argue it but in practical terms that's what it is.
 
You said it was a wrapper around C, which it isn't. "Extension" is less objectionable.
 
early C++ compilers would use an intermediate step to convert to C first. Nowadays I doubt it matters much. The compilers for both C & C++ probably convert to a pseudo code and then perform optimizations on it then turn that into assembly code. The C compiler might actually be the C++ compiler but with a lot of the restriction flags turned off.
 
jiminator said:
early C++ compilers would use an intermediate step to convert to C first. Nowadays I doubt it matters much. The compilers for both C & C++ probably convert to a pseudo code and then perform optimizations on it then turn that into assembly code. The C compiler might actually be the C++ compiler but with a lot of the restriction flags turned off.
Click to expand...

Yeah, that's how VC++ handles it. Bottom line though C++ is source code compatible with C, that was one of the design goals.
 
C or C++ w/ emacs and terminal are good places to start. They are the building blocks, and to know how to do everything manually gives you a good understanding of what is done automatically. Basically once you know how to do it, everything else will seem very simple.

It's like in math when they teach you the formula to find a limit before they teach you the chain rule. You have to understand where it's coming from first.
 
Dynafrom said:
If I recall correctly doesn't C++ at compile time runs the code in C, thus creating overhead? Or is this old news?
Click to expand...
You don't recall correctly. It isn't news because it isn't true. Even if it was true, it couldn't be true: you can't run code in C at run-time, since C isn't machine language.

jiminator said:
early C++ compilers would use an intermediate step to convert to C first. Nowadays I doubt it matters much. The compilers for both C & C++ probably convert to a pseudo code and then perform optimizations on it then turn that into assembly code. The C compiler might actually be the C++ compiler but with a lot of the restriction flags turned off.
Click to expand...
You're thinking of Cfront. Yes, this is the way it worked in the pre-history of C++. Cfront read C++ source code and emitted C code that implemented the semantic C++ program in C. Then, a C compiler compiled that code for the target platform. Cfront was a translator or a pre-processor; it wasn't a compiler. None of this happened at run-time, though some C++ constructs did (and still do) require run-time activity.

There are no "restriction flags". C and C++ require different front ends -- they can share code, but the languages are different enough that they can't be completely the same.

heatlesssun said:
Yeah, that's how VC++ handles it. Bottom line though C++ is source code compatible with C, that was one of the design goals.
Click to expand...
No, that's not how VC++ handles it. There are no "restriction flags". The front ends for the c++ and C compilers are different. Here's where I have Visual C++ installed:

Code: 
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin>dir c*.*
 Volume in drive C is Apex
 Volume Serial Number is 3A63-7C22

 Directory of C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin

12/01/2006  23:24           630,784 c1.dll
12/01/2006  23:06           778,240 c1ast.dll
12/01/2006  23:24         2,285,568 c1xx.dll
12/01/2006  23:06         2,498,560 c1xxast.dll
12/01/2006  23:10         2,265,088 c2.dll
12/02/2006  06:20           117,504 cl.exe
09/22/2005  23:52               268 cl.exe.config
12/02/2006  06:17           142,096 clstencil.exe
12/02/2006  06:20            33,032 cvtres.exe
               9 File(s)      8,751,140 bytes
               0 Dir(s)  98,040,213,504 bytes free

CL.EXE is the compiler driver. C1.DLL is the C-language front end. C1XX is the C-language back-end. If you compile code as C, you run C1.DLL over it. If you compile code as C++, you run C1XX.DLL over it. The front ends emit intermediate language, or IL.

IL is consumed by the back end, implemented in C2.DLL. C2.DLL ends up emitting the byte code that becomes the OBJ file, which is consumed by the linker.
 
heatlesssun said:
That C++ is an object oriented extenstion of C? I'm sure that people much better in the language than me will argue it but in practical terms that's what it is.
Click to expand...
Not really. C++ is multi-paradigm. OO is just one of its supported paradigms. Objective-C is much more akin to "an object oriented extension of C" given that it's a strict superset of C, yet that description doesn't do it justice either (in my opinion).
 
mikeblas said:
There are no "restriction flags". C and C++ require different front ends -- they can share code, but the languages are different enough that they can't be completely the same.
Click to expand...

I've not written C/C++ code for almost 7 years so this isn't my element and I'm claiming no expertise since I've been out of it for so long but this was how I saw it:

Because C is effectively a subset of C++, Visual Studio manages C programs as C++ projects. Therefore, writing a C program for use in Visual Studio mainly involves the programmer excluding C++-specific language features from his code, yet still using the C++ project options in the GUI.
Click to expand...

http://www.ehow.com/how_5019908_use-visual-studio-write-programs.html

And I thought there was away to set up compiler flags to restrict C++ features to enforce C source compatibility.
 
phide said:
Not really. C++ is multi-paradigm. OO is just one of its supported paradigms. Objective-C is much more akin to "an object oriented extension of C" given that it's a strict superset of C, yet that description doesn't do it justice either (in my opinion).
Click to expand...

What you say is true. Both C++ and Objective-C are 25+ years old and and being an old fart I was around when this stuff first came out and the main point when these languages came out was object orientation, indeed C++ started out called "C with classes". Remember Smalltalk? Nothing but object orientation and a big influence on Objective-C like a lot of Xerox inspired stuff from Apple in the 80's. But Smalltalk influenced many languages including C++.

Obviously since then the languages have evolved to address other concerns as you point out but they were born out of the drive for object orientation and that remains at their core today.
 
Dynafrom said:
I'm a computer science student and I'm trying to figure why on earth I'm learning C instead of C++ (which tends to be quite popular).
Click to expand...

You learn C because it's a small language that is ubiquitous, provides the syntactical base for many later languages, and because c-statements are (relatively) closely connected to machine code, which makes it easier to explain what happens under the hood.

Right now I'm taking a course on unix system programming and TBH unix looks like ass. I hate using the terminal, and I hate using emacs to write code.
Click to expand...

If you truly hate it then I'd say you're in the wrong major, unless you're heavily into the math-side. For all intents, UNIX systems programming _is_ c.

It seems outdated, am I wrong or does the industry use what I'm doing?
Click to expand...

Yes, yes and yes. Yes it LOOKS outdated to you, that's because you're a neophyte, and yes, me and many other programmers work mainly from the command line using EMACS or vim and all the goodies provided by a modern UNIXy shell environment.

and can't unix compile and run C++? Isn't it just as portable?
Click to expand...

Of course it can.

I don't see what C++ would buy you in this course, and besides, it's not like you learn one language and that's it. Learn C. Then Learn C++.
And Scheme.
And Python.
And Javascript.
And Java.
And perl.
And PHP.
And Ruby.
And Prolog.
And Erlang.
....
 
heatlesssun said:
I've not written C/C++ code for almost 7 years so this isn't my element and I'm claiming no expertise since I've been out of it for so long but this was how I saw it:
Click to expand...
Unfortunately, that's wrong. There's no "C++" or "C" project in Visual C++. You might find such names in the Wizard, but each project just collects source files and includes some rules for showing them to the compiler. The compiler accepts a source file and tries to guess if it is C or C++ by its file extension. You can override that guess with a command line option.

That option doesn't "restrict features"; it changes the language used to parse the file.
 
mikeblas said:
Unfortunately, that's wrong. There's no "C++" or "C" project in Visual C++.
Click to expand...

Huh?

Visual%20Studio%202010%20C%2B%2B%20Project.jpg


Visual%20Studio%202010%20C%2B%2B%20Project-01.jpg


Found this, I need to take a look and see if this actually works: http://learningpcs.blogspot.com/2010/01/visual-studio-compiling-in-c.html
 
Last edited:
I think he's saying there's no langugage differentiation (amongst project types) between C or C++.
 
You must log in or register to reply here.
Back
Top