James Kanze wrote:
(liberally snipped post follows...)
> You might want to take a look at OSE
> (http://ose.sourceforge.net).
IMHO, a lot better designed and
> easier to use than the STL. Above all, a different approach.
> It tend to use STL mainly as the low level tools, over which I
> build the library I actually use. OSE is usable directly.
Seems like it has special sup****t for Python. Speaking of stuff that's
"in the air," it sure seems like Python is rapidly becoming the de facto
standard scripting/dynamic language for interfacing to programs written
in C++. Now I just have to convince the clients that they don't really
want all that legacy code they've written in a half dozen other
scripting languages, and that it's time to learn yet another...
>>> (Even before templates were added to the language, people
>>> were simulating them with macros.)
>
>> I don't know about "most people," but there was a relatively advanced
>> technice that I have used in C called XInclude:
>
>> #define ELEM_T int
>> # include "list.h"
>> #endif
s/endif/undef ELEM_T/ (my bad)
>> It's a far cry from what C++ templates give you. Googling XInclude
just
>> turns up something related to XML-related processing. Googling
XInclude
>> -XML also fails to turn up the XInclude pattern. It's still not an
>> especially well-known practice.
>
> Try googling for <generic.h>:-).
Lots of <generic.h>s, but none that look like precursors to templates.
I was thinking of headers that defined a bunch of type-specific
structures and functions by being included multiple times, each time
with a set of macros representing a different static type. They mention
it briefly here:
http://en.wikipedia.org/wiki/C_preprocessor#Token_Concatenation
> If I were going to write something with a GUI, I'd probably give
> wxWidgets a trial. On the other hand, GUI's are something that
> Java actually does quite well. (More because Swing is well
> designed, that because of anything in the language itself.)
I like Swing, too, although the handful of GUI experts I know still seem
wary of it. I haven't used wxWidgets, but I hear mixed reviews.
>> The only other "iterators" I was using at the time were
>> hateful little C-style things that were intended to work like
>> this:
>
>> some_lib_iter* iter =
some_lib_create_iter(some_lib_some_container);
>>
>> while (!some_lib_iter_done(iter)) {
>> some_item* item = (some_item)some_lib_iter_next(iter);
>> // ...
>> }
>
>> By the way, I'm currently using a recently written,
>> professional, industry-specific C++ library that sup****ts
>> almost the same idiom, and I still don't like it.
>
> It's very close to the USL idiom:-). And the Java one. And
> yes, combining advancing and accessing in a single function is
> NOT a good idea.
Do you use istream_iterator?
> But one iterator still beats two, when you
> have one function providing the range for another, or when you
> want a filtering iterator. (Look at all the hoops
> boost::iterator has to jump through to make their stuff work.)
I'll take a look.
>>>> 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.
>
>> It hasn't been a problem for me. Maybe I've just been spoiled
>> by being a client, rather than an implementer, of the STL.
>
> So how to you write a function which returns a range,
I don't think I've ever needed to. If I did, I'd probably follow the
STL approach of returning a std::pair (like std::equal_range).
> and use
> the return value of that function as the argument to a function
> which takes a range? Or how do you use the decorator pattern on
> an iterator, to provide a filtering iterator?
That, I've done, and with some success. I didn't come across any
particular problems (or if I did, they're so subtle I still don't see
them). You have the outer, decorating iterator, and the inner iterator
whose type is a template parameter. Intercept all
increment/dereference/etc. calls, and provide whatever delegation and
decoration are necessary. No fuss, no muss. Clean, simple client code.
I guess you're not a big fan of STL-style iterators, but I still love
them.
> My usual policy today is to write my iterators according to the
> GoF pattern, with three functions: isDone(), next() and
> element(), adding isEqual() if at all possible. And to have
> them inherit from IteratorOperators<>, which uses the Barton and
> Nackman trick to provide the STL interface. When it makes no
> difference otherwise, I'll use the STL interface, on the grounds
> that that's what most C++ programmers will be most familiar
> with.
Please continue to provide that interface. :)
> But the clean interface is there if I need it, e.g. for
> chaining, filtering, etc.
If that's really what you want, then more power to you.
>>> And std::string sup****ts 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.)
>
>> The fact that those aren't member functions does not mean
>> they're difficult; in fact, they're trivial to write.
>
> But you have to write them:-).
Well, yes, once. Or use the freely available, existing implementations,
which are probably good enough for the typical new C++ developer's
purposes.
> Seriously, the problem with std::string is that it is sort of a
> bastard---it's too close to an STL container of charT to be an
> effective abstraction of text, and it adds a bit too much which
> is text oriented to be truly an STL container.
I don't see those as contradictory goals. Any representation of text is
effectively a container of characters.
> In its defense: even today, I'm not sure what a good abstraction
> of text should sup****t.
Right, there still does not seem to be any widespread agreement on that.
It's probably a good idea to keep the C++ standard string class
interface minimal, until C++ developers know what they really want.
>> Case-insensitive compare is covered in plenty of introductory
>> C++ texts, because it's one of the easiest things to show
>> people.
>
> Case insensitive compare is one of the most difficult problems I
> know. Just specifying it is extremely difficult.
Depends what you mean by it. What most new C++ developers mean by it is
a pretty simple idea, and a FAQ. Plenty of string cl***** that have
alleged case-insensitive comparison functions actually provide only the
toupper-each-char implementation.
If you're talking about an industrial-strength, ****table implementation,
then of course it gets complicated, as do all natural-language related
issues. If you have a copy of Effective STL handy: The simple case is
covered by Item 35, and the complicated case is Appendix A, which is the
Matt Austern article from the May 2000 C++ Re****t.
http://lafstern.org/matt/col2_new.pdf
This article is getting a little long in the tooth; has anything really
changed? The only new info I've seen is library-specific do***entation
(ICU and Qt).
>>>> with better syntax: Array-style indexed access to characters,
>>>> concatenation using operator+,
>
>>> Interesting. All of the string cl***** I've ever seen sup****t
>>> 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.
>
>> Er, I don't?
>
> Then your code is probably wrong.
I don't believe it is wrong. But you're entitled to your opinion.
> (Note that you're certainly
> not alone in this. The toupper and tolower functions in C and
> in C++ all suppose a one to one mapping, which doesn't
> correspond to the real world, and every time I integrated my
> pre-standard string class into a project, I had to add a
> non-const []---although the class sup****ted an lvalue substring
> replace:
> s.substring( 3, 5 ) = "abcd" ;
> was the equivalent of
> s = s.replace( 3, 5, "abcd" ) ;
> .)
Whether toupper and tolower are correct is a completely orthogonal issue
to whether it makes sense for the string class to have array-style
character indexing.
>>> (And of course, the [] operator of std::string gives you
>>> access to the underlying bytes, not the characters.)
But that makes sense for that particular abstraction, because
std::string is a typedef meant to represent the common case of
characters that fit within bytes. If the idea of a character is too
complex to be represented by a char or wchar_t, then it merits its own,
dedicated type, with sup****t for conversions, normalization, etc.
>> That's a sometimes-true but fundamentally misleading
>> statement. If you have a character type that serves better
>> than char or wchar_t, you're free to instantiate basic_string
>> with it, specialize char_traits for it, and generally define
>> your own character type.
>
> Are you kidding. Have you ever tried this?
Yes, and it seemed to work well. It never got released in production
code though, because there just wasn't any need for it.
> But that's not the problem. I usually use UTF-8, which fits
> nicely in a char. But [] won't return a character.
What do you mean? std::basic_string::operator[] returns a
reference-to-character, as defined by the character and traits types
with which basic_string was instantiated.
>> The lack of a real Unicode character type in the standard
>> library is a valid weakness, but not a fundamental limitation
>> of the std::basic_string.
>
> Even char32_t will sometimes require two char32_t for a single
> character: say a q with a hacek.
I'll take your word for that example. :) Characters just aren't all the
same size anymore.
http://www.joelonsoftware.com/articles/Unicode.html
>> And by the way, I was relating my own experience. At the time
>> I first used std::string, the characters I needed to represent
>> fit very comfortably into bytes, and the [] operator did
>> provide correct access to them.
>
> Take a look at my .sig. I should be obvious that this is not
> the case for me.
Your sig looks fine to me, accented characters and all. It's actually a
nice proof of concept, since it includes three different (Western)
languages.
> But even in English, if you're dealing with text, how often do
> you replace a single letter, rather than a word?
Admittedly, not often. It's just not something that comes up a lot. If
I'm accessing an individual character, chances are good that I'm
actually iterating over the characters in a string. This kind of code
is usually just buried in low-level library functions. If a library is
going to sup****t strings and substrings, then some code somewhere has to
work at this level. There's no getting around it.
Even if the standard library provided lots of Unicode-friendly string
sup****t, indexed character access would still be im****tant. There will
always be per-character functionality needed by client code, but not
provided directly by the library.
>>> 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.
>
>> That's a valid point.
>
> I suggested / (in C++, & has the wrong precedance), but that
> went over like a lead ballon.
>
>>> 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.
>
>> I like operator+ as a concatenator. What I think is more
>> confusing (until you get used to it) is that the same operator
>> is valid for individual chars, but with completely different
>> meaning.
>
> That's because char isn't a character type, but a small integral
> type.
And a badly misnamed one, at that.
> That's because we don't have a character type. (As
> mentionned above, I'm not sure that we have enough practice,
> even today, to know what we would really need in a character
> type, so perhaps the current situation is the best we can do.
> or would be, if char were required to be unsigned.)
Yup.
>> #include <iostream>
>
>> int main() {
>> char c = 'c', d = 'd';
>
>> /* "199" on ASCII platforms. */
>> std::cout << (c + d) << '\n';
>> }
>
>> The standard library types behave so much like primitive types
>> most of the time, that I find it jarring when they are
>> different.
>
>>>> 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).
>
>> That difference is correct, but I find it a natural extension
>> of iteration. Anyway, what the STL calls iterators are really
>> more like "pointer-like objects that may be used for
>> iterating, but may sometimes also be used for other stuff."
>
> Exactly. Which is both their force and their weakness.
>
> [...]
>>> 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).
>
>> No, I mean acquiring and releasing with each dereference. You first
>> create a type that acquires the lock in its constructor and releases in
>> its destructor. The smart pointer creates a tem****ary of that type on
>> each dereference. This implements the extreme case of fine
granularity,
>> acquiring the locking the mutex for an absolute minimum amount of time,
>> but with potentially frequent calls to the locking code. Accessing an
>> object only through such a locking smart-pointer is similar to using a
>> Java object with only "synchronized" methods, where every time you call
>> a method, you first have to get a lock on the object.
>
> That much I understood. One of the things that I found out
> quickly in Java is that synchronized methods were useless, and
> could only be considered a misfeature. (But I guess it's nice
> to say that in C++, you can emulate even the misfeatures of
> another language.)
Right. :)
> Of course, I'd thought about the technique you describe above,
> and rejected it because it doesn't work in some frequent cases,
> e.g.:
>
> f( smartPtr->get1(), smartPtr->get2() ) ;
Good call.
>>>> 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.
>
>> Huh? Do you really think you know every nook and cranny of
>> the standard off the top of your head, including the standard
>> libraries?
>
> Not every nook and cranny. But I do expect anyone using C++ to
> have at least an awareness of what it can do.
In my experience, most C++ developers have no idea what the language can
do. They use it as a sort of "C with cl*****," replacing
function-pointers with virtual functions, but otherwise writing
glorified C code.
> You don't have to
> know the details, but you do have to know that the possibility
> exists, and where you should start looking in the do***entation.
Agreed. If you're not at least vaguely aware that a feature might
exist, you're not going to benefit from it.
> My point is just that if your goal is to just learn a minimum,
> and start hacking code, C++ probably isn't the language for you.
Oh, I think it is. Suppose you start with <insert language-of-the-month
here>. "Wow," you say, "this is really neat! LotM lets me print 'hello
world' with just a single line!" Or (this one is in vogue now): "Look
how much stuff I can do with Excel macros! I'm going to implement all
my business logic using them. Instead of writing applications, I'll
give everybody macro-heavy spreadsheets to fill in."
Sooner or later, that person needs to write a real, non-trivial program,
at which point the knowledge they gleaned from "Learn Language X in 24
Seconds" becomes worse than useless. It becomes baggage. Writing very
small programs in C++ is harder than writing them in some other
languages, but the point of newbie hacking isn't just to get something
working, but to lay the groundwork for harder tasks that lie ahead.
I'm sure you've seen this. I agree with it:
http://www.research.att.com/~bs/learn.html
> The minimum necessary is a good deal more than for a lot of
> other languages. But... the effort you invest won't be wasted,
> because once you do have a good grasp of the language, your
> productivity will be considerably higher than in any other
> language.
Probably true.
> (At least, that's been my experience. But of course,
> I've not tried every other possible language---maybe there's one
> out there in which I'd be even more productive. If so, however,
> I'm willing to bet that it will be just as complicated as C++,
> if not more so.)
I would have liked to see a more Smalltalk-heavy industry. All modern
dynamic languages seem to me like convoluted imitations of Smalltalk.
I'm not a Smalltalk expert, and it doesn't seem have much of a fan-base
anymore (like the Lisp cult), but the syntax was so clean, and you could
****t it to a new bare-hardware platform in a Summer. What happened?
Was it the licensing? Why is Java the server-side "safe bet," rather
than Smalltalk?
>> It's enough to have a fundamental grasp of the items you use
>> regularly, and know where to look to get more information. I
>> do not ever expect to have the whole thing memorized. Even if
>> I were intimately familiar with the current standard, I'd
>> still have to update my knowledge every 5 years or so, which
>> seems to go against your "learn it once" philosophy.
>
> It's a fact of life that in this profession, we can't afford to
> stop learning. And unlearning. (About six months ago, I was
> cleaninig out some old directories, and came accross some code
> I'd written almost 20 years ago. I wouldn't consider such code
> acceptable today, but back then, my employers thought very
> highly of it.)
The mark of the true professional, as opposed to the mere practitioner,
is that he keeps improving.
|
