|
Are there reasons for beginner programmers to be taught C instead of C++?
I'm not even thinking about Object Oriented programming, but simple declarative programming.
I'm reading a lot of questions on CodeProject and on StackOverflow where people ask about issues with C language features that are so prone to errors and defect that it makes me cringe.
A lot of those issues could be handled by simple C++ features (memory management (new/delete, smart pointers), strings, collections, references, ... )
I know there are lot of legacy code out there and it should still be maintained, but old code "ways" should not be the emphasis of the education.
Watched code never compiles.
|
|
|
|
|
Imagine a c++ programmer armed with a few smart pointer classes from boost and the stl and no understanding of the underlying issues each is designed to address.
|
|
|
|
|
So a Java programmer? 
|
|
|
|
|
|
Well, I don't care (one example of many) how std::string internally manages the string, I just want to do std::string s("hello world");.
it is safe, it is efficient.
Watched code never compiles.
|
|
|
|
|
Until you want to pass it to an api that takes LPTSTR
|
|
|
|
|
A cringe-worthy proposition!
I'm quite pleased by the way the StringBuilder class works so nicely with interop.
|
|
|
|
|
Maximilien wrote: it is efficient.
std::string is not efficient if you're not using it properly and according how it manages string internally,
Maximilien wrote: it is safe
and std::shared_ptr is not safe if you're using it incorrectly (circular references).
So if you really want safe and efficient code you need to know how those high-level concept works on a low-level.
|
|
|
|
|
Well,
Maximilien wrote: std::string s("hello world");.
I'm using VC5. Never missed that Construct, and I don't see the efficiency improvement against what I would write:
'CString s("Hello World");
Bram van Kampen
|
|
|
|
|
_Josh_ wrote: Imagine a c++ programmer armed with a few smart pointer classes from boost and the stl and no understanding of the underlying issues each is designed to address.
Nevertheless, Stroustrup recommends learning high-level procedural C++ and then learning the low-level stuff, i.e., the exact opposite of what you say.
Kevin
|
|
|
|
|
Well I didn't really suggest an order, just that knowledge of both is required to make the most of c++. If people want an easier language there are plenty out there.
|
|
|
|
|
|
I think the surge of C questions is underqualified people being contracted or hired to build apps.
"I have a theory that the truth is never told during the nine-to-five hours. "
— Hunter S. Thompson
|
|
|
|
|
Not as a first language. Nor should an OOP-only language (VB, C#, etc.) be the first language. In my opinion BASIC and Pascal (and maybe Perl?) are still good first languages even though they won't apply very well to modern business. Professional developers still to be smacked with C.
|
|
|
|
|
Python's a good starting language, the syntax is simple and it's easy to read, plus it enforces code indentation practices.
|
|
|
|
|
I've seen a little bit of Python (in MIT's video series), but not used it so I didn't feel I could recommend it.
|
|
|
|
|
PIEBALDconsult wrote: Not as a first language
How about assembly?
|
|
|
|
|
No, but I had that before I learned C.
|
|
|
|
|
PIEBALDconsult wrote: No, but I had that before I learned C
I guess you learned a thing or two that you still find useful ...
|
|
|
|
|
It's interesting that you mention "assembly".
The very history of C as a programming language speaks loudly.
Long ago and long ago (as the Native Americans would say), Bell Laboratories purchased a DEC PDP-7 computer. That machine was quite primitive, more or less a "minimal" computer. It had either 4k or 8k memory of 18 bit words, 16 op-codes, no multiply or divide instructions, no index registers, and primitive indirect addressing. It did have a set of memory locations that were "auto-increment" that simulated very primitive index registers, but were not terribly useful over all.
The principle I/O were paper tape and a model 33 teletype. In fact, a bare-bones PDP-7 only had a teletype, in which case it would have been a model 35 ASR, which had paper tape read and write included. VERY slow!
Bell Labs wrote a language called BPL (for Bell Programming Language, I think) which they used as an alternative to the assembly language supplied by DEC. I've never seen any details on BPL. However, Bell Labs used BPL to write a FORTRAN compiler for the PDP-7, as odd at that might sound.
When DEC came out with the PDP-11, Bell Labs bought one and jumped on it like a duck on a June bug! They wrote a translator that converted the BPL translator (probably other programs as well) to run on the PDP-11. Using the translated BPL, they developed a new language, C.
From rags to riches in terms of machine language capability, the C designers included features in the language to utilize many of the newly available features of the PDP-11. In particular, the auto-increment/decrement and to-memory instruction modifiers were incorporated in the ++/--/+=/-= operators. The indirection modifiers gave rise to the pointer operators.
The above information I learned from a Bell Labs programmer/developer at at DECUS (Digital Equipment Computer User's Society) meeting. He was one of the original creators of C, but unfortunately I forget his name.
He told me that when they developed C, they had in mind a "portable assembler" that would allow them to port code to any architecture by merely writing a translator for C for that new machine. Good C programmers, he said, visualized assembly code as they wrote in C.
For anyone interested, here is a link to the PDP-11 "card":
[^]
Given the .NET availability these days, it makes a lot of sense to do MOST programming in a .NET style language, as the languages/compilers are tailored for cross-platform operation.
For most of us, performance penalties are minimal in light of the super-fast multi-core processors we now enjoy. Only a few developers who are involved with projects in which the "utmost farthing" of performance is demanded need to be concerned about the very low-level workings of a given processor. In this case, the original C, with a suitable translation to the target precessor, makes some sense.
For beginners, I believe that Small Basic offers a good compromise, as it introduces the use of "objects" despite not being able to create new classes. Its absence of complexity lets one teach about the principals of programming without becoming embroiled with side-bar issues that have little to do with learning what programming is all about. Beginners quickly learn the fundamentals, then are ready to move on. My choice is then C#, as it is a new generation language and can be taught in "layers" after a few "rules" are learned, and new "rules" can be added as needed.
One of my "heroes" once wrote:
"A computer is like an old-testament god, many rules and no mercy."
- Joseph Campbell
|
|
|
|
|
Hi Mr. Ranshaw,
very informative thanks.
"He told me that when they developed C, they had in mind a "portable assembler" that would allow them to port code to any architecture by merely writing a translator for C for that new machine. Good C programmers, he said, visualized assembly code as they wrote in C."
Yes, yes but they failed [well partially they succeeded] to achieve this nifty goal.
Get down get down get down get it on show love and give it up
What are you waiting on?
|
|
|
|
|
"... but they failed [well partially they succeeded] to achieve this nifty goal."
In what way did they fail to achieve that goal?
More of the history is that Bell Labs developed an operating system for the PDP-7 (for what there was none previously). After they got C running on the PDP-11, they used C to write a translator from BPL (ie, their compiler for the PDP-7). Using that BPL -> C translator, they ported their operating system onto the PDP-11. Of course they had to write assembly code to handle the various low-level drivers.
It was that port of their PDP-7 operating system that grew into UNIX(TM). By the way, "UNIX" means "UNIversal eXecutive" according to the Bell Labs guy I talked to. Also witness the various ports of UNIX to a plethora of platforms, all using (as far as I know) some manifestation of C. For example, LINUX and BSD.
|
|
|
|
|
>In what way did they fail to achieve that goal?
I meant the present time, you are into the genesis whereas I am a simple nowadays C user.
Assembly is the core, C mimicks it, for example recently (for reference Fastest strstr-like Function in C!? article)I defined a variable as a register and guess what despite the desperate need of this C has had other agenda - I mean C is good Assembly is best.
>By the way, "UNIX" means "UNIversal eXecutive"
It makes sense, it is strange how such basic/important names are unknown.
Get down get down get down get it on show love and give it up
What are you waiting on?
|
|
|
|
|
"I defined a variable as a register and guess what despite the desperate need of this C has had other agenda - I mean C is good Assembly is best."
Well, ideally C ought to be kept distinct from processor specific features. Unfortunately, as I mentioned in my first post, such have been part and parcel of the language since its original specification. Or soon after. In fact, I for one would love to see the ++x/--x et al removed from the language, as they ARE based on the capabilities of the PDP-11.
That aside, I have ported C to the 6502, 6800, and even the PDP-10 processors, retaining various portions of the language as were feasible on a particular CPU. They worked very well. Yes, I had to rely on assembly code for the "down and dirty" things.
But not all CPUs have addressable registers, which would make such a capability in C a tad awkward, to say the least. To quote the Bible (sort of): "Render unto the assembler that which is the assembler's."
|
|
|
|
|
Having "flying hours" in Assembly is a precious thing - it marks one's way of thinking for life with a strong base and steady sight on all kind of nasty problems.
I see your wish for an untainted language, however I am in despair dealing STILL with such basic things as basic memory management (hash, memmem, b-tree) functions. I firmly believe that building programs on rotten ground (slow basic functions) is out-of-style boring and artless dead-end. Call me out-of-date and delusional but I still have strong romantic affinity towards artistic approach in programming - I hate this doomed situation in which we all are trapped now - fast PCs and slow software not exploiting the might given by the technology - I am sure you feel that even better than me having dealt with assemblers. In a few words: it is a crime not to utilize fully the potential of a given processor - this shows sloppy attitude not only toward programming but also toward everything else.
I would like to hear from you how do you see one particular task properly get done:
How to rip (down to unique phrases of some order) the whole electronic English language with a C console program (or rather etude). I am talking about my pride-and-joy Leprechaun - the fastest written in C x-gram ripper on the Internet.
My point is that out there exist a lot of programming languages but when comes to the most basic things as helping people with natural languages sidekick/statistical/suggestion tools programmers are in debt to users.
Get down get down get down get it on show love and give it up
What are you waiting on?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
