Re: Linux programming, is there any C++?
On Feb 18, 8:18 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Matthias Buelow wrote:
Jeff Schwab wrote:
[...]
I think the proof, for many of us, was the STL. Before I had
seen STL containers, I struggled briefly with MFC.
Why? There were a lot better libraries around, even back then.
If I wanted to store objects in an MFC container, I had to
inherit them from a particular class, override virtual
methods, and generally jump through a bunch of artificial
hoops.
A technique which went out of favor even before I learned C++,
around 1990.
The developers of the STL took a different approach: They wrote
containers that could hold objects of any type supporting particular
syntax and semantics.
That was more or less the standard approach at the time the STL
was being developed. The STL probably structured it more than
most, e.g. by requiring typedef's for things like value_type,
but that aspect of the STL was largely standard practice by the
time the STL came along: see the USL library, Booch components,
etc. (Even before templates were added to the language, people
were simulating them with macros.)
The syntax they chose was the syntax supported by the
primitive types inherited from C. Container elements had to
be assignable, copyable, constructible without arguments, etc.
Actually, explicitly avoiding any requirement for a default
constructor was probably an innovation of the STL. I think most
earlier libraries required it. (A more important innovation of
the STL was documenting such requirements in the form of
concepts.)
Most of my object types already supported those concepts,
using the expected syntax, so they just worked with the STL
containers, right out of the box.
Again, that's true of every component library I've ever seen.
Then I found out that the same algorithm, literally a single
piece of source code, could work with any container type that
supported a particular set of concepts.
Another innovation of the STL (although I think that the idea
was already "in the air" at the time) is precisely that
algorithms don't work with containers, but with sequences
(iterators).
Most of the standard library containers don't even accept
containers, but instead take iterators, which are in turn
classified according to the sorts of ideas they represent, all
using the same old pointer-style syntax inherited from C.
Which is, of course, that major flaw in the STL---requiring two
iterators instead of one causes no end of problems, making
filtering iterators incredibly difficult, and hindering the
normal nesting of function calls.
Then I found out that I had been wasting my time writing my
own string class, because the one in the standard library
supported more functionality
First, std::string was never part of the STL. And std::string
supports far less functionality than any other string class I
know: no trim or pad, no case manipulation, etc. (I'm not sure
that that's a default, however.)
with better syntax: Array-style indexed access to characters,
concatenation using operator+,
Interesting. All of the string classes I've ever seen support
this. I'm fairly convinced that array-style indexing, at least
for modification, should not be part of an abstraction which is
supposed to represent text---you never change a single
character, but replace one substring with another. (And of
course, the [] operator of std::string gives you access to the
underlying bytes, not the characters.) And while I gave up
arguing against it years ago, + is NOT the right operartor for
concatenation. At least to me, + implies commutitivity, and
concatenation definitely isn't commutitive. On the other hand,
+ is universally established for concatenation of strings---as I
said, I've never seen a string class in C++ (or a string type in
any other language, except AWK) which used anything else.
random access iterators...
Random access iterators are a misnomer (and in many ways, a
mis-feature---if you need a random access iterator, you aren't
iterating, but operating directly on the container).
all the other things I liked about plain char*, without the
headaches.
The same approach continues to be useful; in fact, some of the
neater items commonly used in modern C++ are smart pointers,
which support the same old syntax as raw pointers, but
actually encapsulate potentially complicated ideas.
Dereferencing a smart pointer can, for example, automatically
obtain and release a Mutex lock.
I'd like to see how that works. Or rather I wouldn't, since it
definitly sounds like a bad idea. Don't you mean rather that
smart pointers can manage the lock, holding it over the lifetime
of the pointer (rather than acquiring and releasing it with each
dereference).
[...]
Even features not "natively" supported by C++ can usually be implemented
by easy-to-use libraries. Sure, reference-counted smart pointers can be
used for simple garbage collection, but do you want to see something
really cool? Here's a library I haven't started using in production
code yet, but I'm itching to try:
http://www.boost.org/doc/html/lambda.html
This is more an example of the limitations of what you can do
within the current language. There are a number of subtle
issues, and you sometimes (frequently, in my experience) have to
use special constructions to make it work.
On the whole, lambda expressions/classes are something that
needs real language support. Boost::lambda does as much as is
possible without directly language support, but it still isn't
enough to make lambda truely effective.
C++ is a complicated language, but the wonder of it is that
you can get started with less training than it takes to write
decent C code.
C++ is a very complicated language. It's designed to solve
complicated problems. The complication is there, and can't be
avoided. The only question is whether you want it in the
language (which you have to learn once) or in your application
(which you have to master for each application).
The more you learn, the more C++ rewards you. I remember
someone I used to work with, who had a morbid fear of C++,
taking one look at a typical C++ reference book and laughing
derisively (yes, derisively, just like an arrogant Bond
villain). "How do they expect anybody to learn all that?" he
asked. The answer is that you don't have to learn it all
before you can use it.
But there's no real point in using it otherwise. The point is
that while it may be hard to learn, once you've learned it, the
time invested in doing so is paid back enormously in increased
productivity. (In many ways, it's like the wide spread
discussion between vim/emacs and simpler editors. It may take
more time to learn vim or emacs, but once you do, your
productivity improves enormously.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34