Unlike in Java and Python, 'finally' is not present in C++. You have to simulate it with objects that own resources, so that their destructors perform the cleanup.
Of course, us C++ programmers phrase that a bit differently:
"Unlike C++, Java and Python do not have RAII.
You have to manually maintain 'finally' blocks everywhere where you may
need to perform cleanup".
I'm all for getting rid of threads, but what are you going to replace them with? Traditional functional languages may be the most obvious solution, but they're also among the most impractical of solutions. Is there anything else out there that can replace threading needs, without throwing out the book on programming? It seems like what we need hasn't been invented yet.
Depends on what your "threading needs" are.
The Unix select(2) call takes care of one common use case,
and has existed for 25 years.
In fact, I challenge Darl to find one book talking about programming UNIX in general written in last 10 years for a dozen dedicated to Linux programming. There are just too many platform-specific libraries and tools (such as Qt, gcc, python) needed to create any useful application.
What do you mean?
None of those are Linux-specific.
You are just as likely to need them on Solaris, HP-UX, *BSD,...
Also, readers of UNIX programming books would do best to practice their skills on a Mac or a Sun workstation, as neither Linux nor SCO are certified against current UNIX standard and entitled to claim that they are selling UNIX.
And now you are surely joking.
Unix programming has nothing to do with the UNIX brand. Never has, never will.
If you say "I learned UNIX programming on a Mac because I needed
to learn programming a real, branded UNIX", real programmers will treat you as a kook.
(Of course it is very useful for a Unix programmer to be familiar with various Unixes,
on various computer architectures.)
here on amazon. 1,648 results for linux programming.
Sure, but I bet the majority of them cover what we used to call Unix programming.
I cannot think of any programming language or interface (except the kernel) which is Linux-specific.
If there is one, it's surely because it sucks so badly that noone has bothered to
port it to *BSD and Solaris.
I remember back in the mid-1980s, when my dad worked in a small hardware shop.
The owner was into computers, so he sent his 2--3 employees on a computer course.
These days, they teach MS Word, MS Excel and MS Internet Explorer on that
kind of courses -- but back in the 1980s, they taught you to program in BASIC.
So my dad came home in the evening and said:
"It was stupid. Bengt made the computer write 'Bengt, Bengt, Bengt' over and over again".
And that's how I still feel about this classic BASIC program.
I'm not sure C is up to the multithreading/ multiprocessor support that is going to be required as processors keep shifting from single core to multicore architectures...I know it can be done, but C is hard to program for a single core...Multicore support may take it over the edge.
That is assuming that you buy into the current SMP hype, which seems
to assume that a majority (or even a largish minority) of programs will be CPU-bound,
and impractical to break into cooperating processes a la popen("gzip -dc foo.gz", "r").
I do not see that happening.
Heck, people argue against using C because CPUs are so fast
that you cannot tell the difference between a program written in optimized C
and one that is orders of magnitude slower and written in Java or Python.
And they are often right!
The amateur who says "vertical space matters" to developers, never ran a comparison diff on his code.
Side by side, my friend. Side by side.
Oh, I run diff -y once a week or so.
But I scroll around in source code hourly.
Vertical space does matter a whole lot more.
When I code, I always keep emacs on the left half of my screen,
and a terminal window (for running make, unit test etc) son the right half.
In the terminal, I run screen(1) so I can have easy access to
man pages and so on.
I'm not sure what I'd do with widescreen. I suspect I would end up with an
unused vertical area, slightly too narrow for a third 80xX terminal...
SunOS and subsequently Solaris, as inherited in OpenSolaris, the subject of this article, are AT&T UNIX System V derivatives, not from the Berkely Software Distribution (BSD) of UNIX.
SunOS was BSD. Solaris is AT&T.
See Wikipedia or something for the details of Sun's confusing naming and numbering scheme.
also choose bash/tsh based on your audience, if its a mac crowd tsh is going to be more useful but if its a linux crowd stick with bash
Do you mean tcsh?
I sincerely hope noone writes shell scripts in csh or tcsh these days.
I still kind of like tcsh as an interactive shell, but it's a dead end for scripting.
Also, I like bash scripting, but you should primarily teach the POSIX shell subset.
Even Linux distributions try to avoid bashisms in their scripts.
I think a Lib. Arts degree has great merit, but the submitter has a much better chance of getting a good education at a highly-rated technical school. You learn a lot just by being around other people who know more than you do.
Except people skills.
I find this idea very odd -- that you do not learn to work with people
by working with people, but by taking courses on history and literature.
Most nice people I know have no formal higher education.
I always use -W -Wall -pedantic -std=c89 plus any glibc #defines to enable
POSIX/BSD/whatever functions I need.
Seeing people respect and use the gcc warning flags makes me happy,
but I don't know why you chose to leave out -pedantic
and (more importantly!) the option to select which bloody language you are feeding the compiler.
But if you don't understand, why a warning is generated ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow.
I think I understand what you mean: that it's wrong to write
int foo=0; if you never intend to use the fact that foo starts out as zero.
If so, I agree. That's just a way of making your bugs harder to find, and your code harder to read
by obscuring its purpose.
But in general, initializing variables is a good idea.
In C99 and C++, I usually have something suitable to initialize them with, because I am allowed
to declare them where I have the need for them, rather than at the top of the block.
Richard Stevens was definitely "the man" when it came to writing books like this; I'd recommend them to anyone. Anyone who attempts to cover the same ground (even years later) has a tough act to follow.
IIRC, someone came with a revised APUE two years ago or so.
But yeah -- there are a few interesting questions.
What does this book offer which isn't in
Advanced Programming in the UNIX Environment, the man pages and the relevant standards?
Is the reviewer familiar with Stevens' work?
And why is the reviewed book Linux-specific,
when all good code is portable across all modern Unixes?
(The Perl/Python programmer in me also wonders why you have to code in C
to be a systems programmer.)
Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? It seems like those traits would make it more secure, but take much longer to make...
How does slow to write and obscure translate to "more secure"?
It doesn't.
To me, "slow to write" translates to "programmer gets bored and sloppy".
And if you are bored, it's not hard to write crappy, uninspired code even in a
bondage & discipline language.
I think that all Bjorne has really done to the C language is cause more and more fragmentation, forking and division... He created fragmentation with C++, and he again created more fragmentation with "C++0x". This guy should be banned from creating languages. Instead of making new languages, why not improve on the C language standard? He doesn't want to do that, he wants to make a name for himself by creating all these different languages... I don't think what he has done has done anything to better the world of computer science.
You are posting gibberish, or trolling.
Either that, or Stroustrup has been dating your sister, or kicked your dog.
All Bjarne (sic!) has done to the C language is
basing one (1) language on it.
That was 25 years ago so K&R have probably forgiven him by now.
Does anyone still USE C++ any more? Seems the only ones around where I work who even know C++ are the old timers. Recently, the consulting company I work for had the opportunity to hire a number of C++ programmers for a legacy project - we had one guy on staff, and couldn't find ANYONE else with the necessary skills.
It may be a matter of what business one is in.
On Windows, lots of people follow Microsoft's lead and use whatever language
they are pushing today.
People working on web servers tend to disappear into a maze of Java-based techniques.
On Unix, however (especially Linux and BSDs,
and this includes many embedded systems these days)
everything is C-based, the libraries you need to work with have a C API and so on.
Here C is a natural choice,
and C++ is just as natural -- provided the people know the language well enough.
For my hobby use, C++ replaces C on Unix,
simply because it's a better language without taking anything away.
I don't need to do my own memory management or write my own container types,
and I can throw together a small class if I see a use for some object-oriented
design someplace, or need RAII to manage some resource.
C++ is a process of reinventing the wheel over and over. The performance gains of doing things in C++ is usually lost because it wears down the programmer, and leads to sloppy coding. Higher Level Languages as part of the core language comes with many useful functions that are programs relatively good efficiency. Lets say Pythons List Data type where you can do a Sort on it or a concatenate, or get a sub list off of it, and more too. Yes you can do the same functionality with C++ but you need to make it yourself and build the Data Type and add the functions to do it, or get a library that may not work on an other platform or needs more libraries to work.
Have you ever used C++?
Python's lists correspond (roughly) to C++'s std::vector,
and the Python list sort() method corresponds to C++'s std::sort().
No need to reinvent any wheels here.
In case you just meant that there is no exact match for the Python list class in C++,
then that's true. But that is true for all languages but Python.
Also keep in mind that Python (which I like and use regularly)
buys its incredible powerfulness and simplicity by being one of the slowest languages around.
One of C++'s design goals was to never be so slow that the user has to resort to another
language, and that prevents it from having much of Python's convenience.
The thing is, C++ is huge. Just to have a solid working knowledge of the core language, you need to master whole rafts of things that have nothing whatsoever to do with the low-level operation of the machine, because even the core is a labyrinth of obscure corner cases that make language lawyers drool, and which, if expressed in pseudo-code, would be a bunch of gigantic switch statements with a couple dozen levels of ifs nested inside each case.
Absolutely. This is fairly easy to check, too; here's the most recent draft for C++0x, and it's already 1200+ pages! And they haven't even included everything they want to get there yet (such as concepts, which alone will add a lot more; a full list of what's not yet there, but is going to be, can be seen here). Now, how do you think, how many developers are going to understand it well enough?
Your logic is flawed.
It assumes
That there are other ISO-standardized languages, comparable in scope,
with a spec much smaller than 1200 pages.
That there are other languages comparable in scope, period.
Note that C++ needs to carry the baggage of C.
That developers actually learn the language from the ISO standard rather than books.
That developers have to relearn the whole language when C++0x comes out.
Seriously, you people keep claiming C++ is huge,
but never seem to come up with any solid evidence.
A decade ago it used to be an argument used by Java advocates,
but from what I hear (I don't use Java) that language has grown quite a bit since then.
I'm going to have to disagree. The C++ Programming Language is useless to actually learn the language and often times it fails as a reference. If all the ego was removed from the book, it might be useful for something. Compare it to K&R. You'll notice a difference in tone. [---]
I am not alone in my opinion.
The ego? Where did that come from?
Stroustrup likes C++; does that show in the book,
and does that irritate people who have decided to dislike the language?
That's the only reason for your statement I can honestly come up with.
I agree (grudgingly) that the book is probably not the best tutorial,
or even the best reference (for beginners, experienced programmers, or experienced C programmers).
It can be very brief when describing something which has huge consequences.
Still, I learned modern C++ from it --
that book, and the good people in comp.lang.c++.moderated.
I also have to point out that the chapters on development and design in general
are the best I have read in any book --
obviously drawn from many painful software project experiences.
That may be so, but there's more to it. It's only been recently fully implemented
Huh? The current standard is ten years old this year,
and G++ had good enough support for modern C++ at least in 1999 (gcc 2.95) and
good support in 2001 (gcc 3.0).
Full support is nothing you should rely on anytime soon; I have given up on the "export" keyword.
and a few years ago Stroustrup himself commented that he's constantly surprised that some things (e.g. template recursion) are even possible in C++.
Probably another tongue-in-cheek comment.
It is true that a lot of uses of templates were discovered inside C++ rather than
designed into it.
I don't see how that is a bad thing.
The language is overly complex. The key advice any C++ expert is "restrict yourself to a specific subset of C++". That's the bulk of the difficulty. If C++ were simplified to include only that subset, you'd have a lot less need for training,
So what part do you suggest removing, and how many decades do you allow
for people to adapt to it?
Note that removing C compatibility is not an option.
The question is flawed. Anyone worth their weight as a programmer doesn't care what language they
program in but. But Programing Methodoligy should they work with.
[...]
most good programmers with experience in these languge classes are not normally worried about what
to program in. They may have their personal favorates but, can code sucessfully in any language
even if they never coded in it before. Because once you understand the classes the rest is just a
google search from finding the right command and syntax of the languge.
That is also flawed, unless you're planning to exclusively write "Hello, world!" programs and
if clauses.
Any worthwhile programming language has its specific voice.
If you believe "it's all just syntactic sugar" or "implementation details",
or that you "can google for the details",
then I can guarantee your code will suck.
You may not realize it, but the person who has to maintain it will.
The old saying "a good programmer can write FORTRAN in any language"
wasn't meant as praise.
I like the hard drive noises. Lets be honest here, they are soft clicks and chirps, not chainsaw noises.
Older hard drives were often noisy, and probably some models still are.
I had one where R/W sounded like someone trampling broken glass and metal.
IIRC, the Seagate Barracuda was my first drive which I couldn't easily hear working.
We should be "stuck with a serial programming model". If your program runs too slow on a single 1 GHz CPU, lack of multicore techniques is the last thing you should be concerned about. The first thing you ought to do is optimize your damn code!
I believe SMP (when did we decide to start calling it "multicore"?) is
mostly useful (in everyday computing!) for multiple-user machines.
Right now I'm running a number of important jobs on a four-CPU Linux server.
At the same time, one guy has a process hogging 100% of one CPU (running an animated screen
blanker or whatever). This guy is on parental leave an will be back in August.
I am happy that this process wasn't coded to take advantage of all four cores.
Slashdot Mirror
I don't think I have ever done it. They are reserved for use in examples; using them elsewhere diminishes their power.
Of course, us C++ programmers phrase that a bit differently: "Unlike C++, Java and Python do not have RAII. You have to manually maintain 'finally' blocks everywhere where you may need to perform cleanup".
Depends on what your "threading needs" are. The Unix select(2) call takes care of one common use case, and has existed for 25 years.
What do you mean? None of those are Linux-specific. You are just as likely to need them on Solaris, HP-UX, *BSD, ...
And now you are surely joking. Unix programming has nothing to do with the UNIX brand. Never has, never will. If you say "I learned UNIX programming on a Mac because I needed to learn programming a real, branded UNIX", real programmers will treat you as a kook.
(Of course it is very useful for a Unix programmer to be familiar with various Unixes, on various computer architectures.)
Sure, but I bet the majority of them cover what we used to call Unix programming. I cannot think of any programming language or interface (except the kernel) which is Linux-specific. If there is one, it's surely because it sucks so badly that noone has bothered to port it to *BSD and Solaris.
I remember back in the mid-1980s, when my dad worked in a small hardware shop. The owner was into computers, so he sent his 2--3 employees on a computer course. These days, they teach MS Word, MS Excel and MS Internet Explorer on that kind of courses -- but back in the 1980s, they taught you to program in BASIC.
So my dad came home in the evening and said: "It was stupid. Bengt made the computer write 'Bengt, Bengt, Bengt' over and over again".
And that's how I still feel about this classic BASIC program.
Python, not VB, is the modern BASIC.
Python is also the modern programmable desk calculator.
Does VB have an easily accessible interactive mode? For that matter, does it have anything in common with BASIC?
That is assuming that you buy into the current SMP hype, which seems to assume that a majority (or even a largish minority) of programs will be CPU-bound, and impractical to break into cooperating processes a la popen("gzip -dc foo.gz", "r"). I do not see that happening.
Heck, people argue against using C because CPUs are so fast that you cannot tell the difference between a program written in optimized C and one that is orders of magnitude slower and written in Java or Python. And they are often right!
Oh, I run diff -y once a week or so. But I scroll around in source code hourly. Vertical space does matter a whole lot more.
When I code, I always keep emacs on the left half of my screen, and a terminal window (for running make, unit test etc) son the right half. In the terminal, I run screen(1) so I can have easy access to man pages and so on.
I'm not sure what I'd do with widescreen. I suspect I would end up with an unused vertical area, slightly too narrow for a third 80xX terminal ...
SunOS was BSD. Solaris is AT&T. See Wikipedia or something for the details of Sun's confusing naming and numbering scheme.
Do you mean tcsh? I sincerely hope noone writes shell scripts in csh or tcsh these days. I still kind of like tcsh as an interactive shell, but it's a dead end for scripting.
Also, I like bash scripting, but you should primarily teach the POSIX shell subset. Even Linux distributions try to avoid bashisms in their scripts.
I find this idea very odd -- that you do not learn to work with people by working with people, but by taking courses on history and literature.
Most nice people I know have no formal higher education.
I always use -W -Wall -pedantic -std=c89 plus any glibc #defines to enable POSIX/BSD/whatever functions I need.
Seeing people respect and use the gcc warning flags makes me happy, but I don't know why you chose to leave out -pedantic and (more importantly!) the option to select which bloody language you are feeding the compiler.
I think I understand what you mean: that it's wrong to write int foo=0; if you never intend to use the fact that foo starts out as zero. If so, I agree. That's just a way of making your bugs harder to find, and your code harder to read by obscuring its purpose. But in general, initializing variables is a good idea. In C99 and C++, I usually have something suitable to initialize them with, because I am allowed to declare them where I have the need for them, rather than at the top of the block.
IIRC, someone came with a revised APUE two years ago or so.
But yeah -- there are a few interesting questions. What does this book offer which isn't in Advanced Programming in the UNIX Environment, the man pages and the relevant standards? Is the reviewer familiar with Stevens' work? And why is the reviewed book Linux-specific, when all good code is portable across all modern Unixes?
(The Perl/Python programmer in me also wonders why you have to code in C to be a systems programmer.)
How does slow to write and obscure translate to "more secure"? It doesn't.
To me, "slow to write" translates to "programmer gets bored and sloppy". And if you are bored, it's not hard to write crappy, uninspired code even in a bondage & discipline language.
You are posting gibberish, or trolling. Either that, or Stroustrup has been dating your sister, or kicked your dog.
All Bjarne (sic!) has done to the C language is basing one (1) language on it. That was 25 years ago so K&R have probably forgiven him by now.
It may be a matter of what business one is in. On Windows, lots of people follow Microsoft's lead and use whatever language they are pushing today. People working on web servers tend to disappear into a maze of Java-based techniques. On Unix, however (especially Linux and BSDs, and this includes many embedded systems these days) everything is C-based, the libraries you need to work with have a C API and so on. Here C is a natural choice, and C++ is just as natural -- provided the people know the language well enough.
For my hobby use, C++ replaces C on Unix, simply because it's a better language without taking anything away. I don't need to do my own memory management or write my own container types, and I can throw together a small class if I see a use for some object-oriented design someplace, or need RAII to manage some resource.
Have you ever used C++? Python's lists correspond (roughly) to C++'s std::vector, and the Python list sort() method corresponds to C++'s std::sort(). No need to reinvent any wheels here.
In case you just meant that there is no exact match for the Python list class in C++, then that's true. But that is true for all languages but Python. Also keep in mind that Python (which I like and use regularly) buys its incredible powerfulness and simplicity by being one of the slowest languages around. One of C++'s design goals was to never be so slow that the user has to resort to another language, and that prevents it from having much of Python's convenience.
Your logic is flawed. It assumes
Seriously, you people keep claiming C++ is huge, but never seem to come up with any solid evidence. A decade ago it used to be an argument used by Java advocates, but from what I hear (I don't use Java) that language has grown quite a bit since then.
Also see Bjarne's canned rebuttal.
The ego? Where did that come from? Stroustrup likes C++; does that show in the book, and does that irritate people who have decided to dislike the language? That's the only reason for your statement I can honestly come up with.
I agree (grudgingly) that the book is probably not the best tutorial, or even the best reference (for beginners, experienced programmers, or experienced C programmers). It can be very brief when describing something which has huge consequences. Still, I learned modern C++ from it -- that book, and the good people in comp.lang.c++.moderated.
I also have to point out that the chapters on development and design in general are the best I have read in any book -- obviously drawn from many painful software project experiences.
Huh? The current standard is ten years old this year, and G++ had good enough support for modern C++ at least in 1999 (gcc 2.95) and good support in 2001 (gcc 3.0). Full support is nothing you should rely on anytime soon; I have given up on the "export" keyword.
Probably another tongue-in-cheek comment. It is true that a lot of uses of templates were discovered inside C++ rather than designed into it. I don't see how that is a bad thing.
So what part do you suggest removing, and how many decades do you allow for people to adapt to it? Note that removing C compatibility is not an option.
That is also flawed, unless you're planning to exclusively write "Hello, world!" programs and if clauses.
Any worthwhile programming language has its specific voice. If you believe "it's all just syntactic sugar" or "implementation details", or that you "can google for the details", then I can guarantee your code will suck. You may not realize it, but the person who has to maintain it will.
The old saying "a good programmer can write FORTRAN in any language" wasn't meant as praise.
Older hard drives were often noisy, and probably some models still are. I had one where R/W sounded like someone trampling broken glass and metal. IIRC, the Seagate Barracuda was my first drive which I couldn't easily hear working.
I believe SMP (when did we decide to start calling it "multicore"?) is mostly useful (in everyday computing!) for multiple-user machines.
Right now I'm running a number of important jobs on a four-CPU Linux server. At the same time, one guy has a process hogging 100% of one CPU (running an animated screen blanker or whatever). This guy is on parental leave an will be back in August.
I am happy that this process wasn't coded to take advantage of all four cores.
I find memory management is trivial in most real-life C++ code. And management of non-memory resources is easier than in Java.