When I heard the author speak at a meeting of the ACCU recently, he described statecharts somewhat differently from the basic FSMs I knew.
Basically, statecharts allow some extensions to FSM: nested states, init/entry/exit actions for states, and probably some others. Apparently these are all defined in UML.
The author's basic approach is to represent the state as a pointer-to-member-function. Except that he's working on embedded systems, which means he uses C, which means he hacks his own OO in C. I must admit that this distracted somewhat from his main point.
Most experts will tell you never to use using directives or use declarations in header files, since you can't always predict the environment they will be used in. In your source files, however, it doesn't matter so much, and you can use whatever you're comfortable with.
In practice, the big problem with the STL is that Microsoft doesn't like it. It's one of those standards that Microsoft doesn't control, yet is so widely used that they can't ignore it. So they support it, but badly. (OpenGL gets similar treatment. So does C++ itself. Microsoft prefers their own dialect of C++, which is not fully compatible with the ISO standard.)
This should get better soon, since Herb Sutter and Stan Lippman are both at Microsoft now, and seem dedicated to standards compliance
The STL doesn't help too much with the big problem of C and C++ programming: keeping track of who owns what. auto_ptr and the STL don't play well together. That's a lack, and it's not easily fixed. There have been three iterations of auto_ptr semantics, all of which have some painful problem. See "comp.std.c++" for discussions on this subject.
If you haven't yet, you should look at boost. They have a very useful smart pointer library.
The first time I seriously used STL in a real project, I ran into a SERIOUS, SERIOUS problem with the implementation of the _map_ container. It was a performance issue. I no longer recall the type of the things I was mapping, but it completely escaped notice in debugging, because the time it took to access a map entry seemed to go up as something like the fifth power of the number of entries in the table... a few hundred entries, no problem; a thousand entries, fuhgeddaboudit. I'm talking milliseconds on maps with a hundred entries, ten to twenty seconds on maps with a thousand...
I don't know what problem you ran into, but a conforming implementation of map would not have those performance characteristics. map.operator[] has O(log n) access time.
String isn't threadsafe in Solaris either; I believe that's actually SGI's implementation.
Depends on what compiler you're using. AFAICT, string from Forte 6 is threadsafe (COW* with atomic increment). gcc 3.0's string is also threadsafe (COW with atomic increment). Other platforms may be threadsafe by simply not implementing COW (STLPort, for example). string on MSVC 6 is definitely _not_ threadsafe (COW, but no atomic inc); I think gcc 2.95 is the same.
Of course, you have to understand any API you choose to use. The exception specifications for STL are well documented, so you know when an exception could potentially be thrown.
vector.push_back() is about as fast as you could wish (0(1) time). If you try to insert into the middle of a vector, you will get a performance hit, however, since many elements have to be moved to make space for the new one. If you need insertions in the middle, you should be using list.
STL is much more than data structures. The three tiers are Containers, Iterators, and Algorithms. Data structures (containers) are just one part.
Don't read headers to learn STL. Get a good book like Nicolai Josuttis's _The_C++_Standard_Library or visit SGI's STL Site
Don't inherit from an STL container. They are not designed for inheritance (no virtual destructors). Instead, keep your current model and prefer aggregation.
vector itself is very useful as a container, as well as for using C interfaces; since the storage is guaranteed to be contiguous (at least in the technical corrigendum), you can do things like:
Slashdot Mirror
When I heard the author speak at a meeting of the ACCU recently, he described statecharts somewhat differently from the basic FSMs I knew.
Basically, statecharts allow some extensions to FSM: nested states, init/entry/exit actions for states, and probably some others. Apparently these are all defined in UML.
The author's basic approach is to represent the state as a pointer-to-member-function. Except that he's working on embedded systems, which means he uses C, which means he hacks his own OO in C. I must admit that this distracted somewhat from his main point.
Most experts will tell you never to use using directives or use declarations in header files, since you can't always predict the environment they will be used in. In your source files, however, it doesn't matter so much, and you can use whatever you're comfortable with.
This should get better soon, since Herb Sutter and Stan Lippman are both at Microsoft now, and seem dedicated to standards compliance
If you haven't yet, you should look at boost. They have a very useful smart pointer library.
I don't know what problem you ran into, but a conforming implementation of map would not have those performance characteristics. map.operator[] has O(log n) access time.
Depends on what compiler you're using. AFAICT, string from Forte 6 is threadsafe (COW* with atomic increment). gcc 3.0's string is also threadsafe (COW with atomic increment). Other platforms may be threadsafe by simply not implementing COW (STLPort, for example). string on MSVC 6 is definitely _not_ threadsafe (COW, but no atomic inc); I think gcc 2.95 is the same.
*COW = Copy On Write
You sounded like you weren't sure. I just wanted to emphasize that it was nailed down, and that it's a bad idea (tm)
Of course, you have to understand any API you choose to use. The exception specifications for STL are well documented, so you know when an exception could potentially be thrown.
vector.push_back() is about as fast as you could wish (0(1) time). If you try to insert into the middle of a vector, you will get a performance hit, however, since many elements have to be moved to make space for the new one. If you need insertions in the middle, you should be using list.
STL is much more than data structures. The three tiers are Containers, Iterators, and Algorithms. Data structures (containers) are just one part.
Don't read headers to learn STL. Get a good book like Nicolai Josuttis's _The_C++_Standard_Library or visit SGI's STL Site
Don't inherit from an STL container. They are not designed for inheritance (no virtual destructors). Instead, keep your current model and prefer aggregation.
I think the parent meant never use vector
vector itself is very useful as a container, as well as for using C interfaces; since the storage is guaranteed to be contiguous (at least in the technical corrigendum), you can do things like:
vector<char> buffer(100);
readSomeData(&buffer[0], 100);
The page below has an interesting discussion of why the implementations of many languages on .NET will be just C# with a new "skin"
http://www.javalobby.org/clr.html
Of course, I haven't checked the facts, so it could just be FUD.
Actually it's not Indo-European, but Finno-Urgic, which also includes Hungarian and Estonian.
Truly amazing to see a comment on Slashdot with Ellijay mentioned (I'm originally from Ellijay).
There are some good examples of quines (self-replicating programs) at http://www.nyx.net/~gthompso/quine.htm
Also, I like Esoteric Topics in Computer Programming