SGI STL Rope in g++? - c++

It seems that there is a implementation of rope in my /usr/include/c++/4.5.1/ext/rope (and ropeimpl.h). I compared it with SGI STL and the code seems to be pretty much the same codebase.
I'm not aware of its status or if its functional or not. Nor i am aware if this is super old stale code, or code in progress
in any case, i haven't found any references about how to use it (if functional). Do you know something i'm missing? are there usage examples i can use?
EDIT if you see the cvs history here, you'll see last activity was 4 months ago, which doesn't look like pretty active, but doesn't look abandoned either.

It's taken straight from the SGI code, and is still maintained (I changed it just the other day to fix a longstanding bug) but is only documented briefly with the deprecated extensions.

I haven't looked at ropes since the nineties, but the SGI STL documentation for rope<T, Alloc> is still on-line. Also The Rope Implementation Overview.

Related

Is adobe ASL (adam and eve) still alive? what is a replacement?

Being a fan of STL, I've been looking for a modern way of GUI development.
It seems that the latest theoretical ideas were in ASL. At least, that is what theoretical papers on gui look at. For example, Algorithms for user interfaces (2009)
However, the latest change in asl was in 2010. The forums are also seem empty. It seems that ASL is not maintained and not used a lot.
I still couldn't find anything as advanced and generic. What do people use now that fills the gap?
It's been a few years, so I'm sure the original questioner has moved on by now. However, for anybody with the same question, it appears that development has moved to GitHub. As of January 2014, this is not stated on the old ASL website.

What do I need to know about C++0x? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Where can I learn more about C++0x?
I am fairly familiar with C++03 but I still need to come to terms with C++0x so I would like to read some fairly digestible information on C++0x.
I have looked at the Wikipedia but I am on the look out for something that is more readable. So is there a book or series of blog entries that provide a nice introduction to the matarial?
There is a ton of stuff on this very site - some of the posts include very informative discussion. I would point you to Google but it's going to be more efficient to search in C++0x tagged posts here imo.
Here's a good one to start with, which includes indirection to Stroustrup's own summary. Scott Meyers has presentation materials on the topic here.
Check up on your favourite compiler's support for the new version. Microsoft VC10 support is summarized here. GCC info can be found here.
Official state of the standard for the language is available here. Evolution of the language is in many places tied to ongoing work in Boost. See here for some info on that.
Honestly my preference these days is to look here for 99% of needed info rather than resort to a book.
It's too early for a book. The standard isn't fixed yet.
Now, if you think wikipedia is hard to read, you might try Stroustrup's page about it. However it might seem harder to read to some.
There's a good tutorial on codeproject here for VC++. Even if you aren't using Visual Studio though it's still useful.
Learn whatever feature you would have loved having in C++98 in the first place. For me, it was variadic templates, lambda functions, decltype and other cool stuff.
If you still don't know what to learn first, maybe you should try to understand what issues from the C++98 are adressed. I say this because all the xvalue, move semantics and al stuff is quite heavy to grasp if you don't know what the problems were (and still are btw). This may imply learning some more C++98 first.
Then, you can always browse the Wikipedia article and look at whatever you find cool. Implementors don't provide all the features yet, so you'll look like a 5 year old staring at the front window of a toy store. This is a good reason to behave like one.
I really liked this series of blog posts by the Visual C++ Team Blog:
The Future of the C++ Language
Lambdas, auto, and static_assert: C++0x Features in VC10, Part 1
Rvalue References: C++0x Features in VC10, Part 2
decltype: C++0x Features in VC10, Part 3
I found the Overview of the New C++ (C++0x) book by Scott Meyers to be a good, detailed summary of the main features. It's more of a presentation with very detailed footnotes that an actual book, but it's still an excellent, short read.
I suggest you using the book functionality of Wikipedia to make it more readable/printable. I did the same for the C++0x page.

To use or not to use C++0x features [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
How are you using C++0x today?
I'm working with a team on a fairly new system. We're talking about migrating to MSVC 2010 and we've already migrated to GCC 4.5. These are the only compilers we're using and we have no plans to port our code to different compilers any time soon.
I suggested that after we do it, we start taking advantage of some of the C++0x features already provided like auto. My co-worker suggested against this, proposing to wait "until C++0x actually becomes standard." I have to disagree, but I can see the appeal in the way he worded it. Nevertheless, I can't help but think that this counter-argument comes more out of fear and trepidation of learning C++0x than a genuine concern for standardization.
Given the new state of the system, I want for us to take advantage of the new technology available. Just auto, for instance, would make our daily lives easier (just writing iterator-based for loops until range-based loops come along, e.g.).
Am I wrong to think this? It is not as though I'm proposing we radically change our budding codebase, but just start making use of C++0x features where convenient. We know what compilers we're using and have no immediate plans to port (if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform). Otherwise it seems to me like avoiding the use of iostreams in 1997 just because the ISO C++ standard was not published yet in spite of the fact that all compilers already provided them in a portable fashion.
If you all agree, could you provide me arguments I could use to strengthen my position? If not, could I get a bit more details on this "until the C++0x is standard" idea? BTW, anyone know when that's going to be?
I'd make the decision on a per-feature basis.
Remember that the standard is really close to completion. All that is left is voting, bugfixing and more voting.
So a simple feature like auto is not going to go away, or have its semantics changed. So why not use it.
Lambdas are complex enough that they might have their wording changed and the semantics in a few corner cases fixed up a bit, but on the whole, they're going to behave the way they do today (although VS2010 has a few bugs about the scope of captured variables, MS has stated that they are bugs, and as such may be fixed outside of a major product release).
If you want to play it safe, stay away from lambdas. Otherwise, use them where they're convenient, but avoid the super tricky cases, or just be ready to inspect your lambda usage when the standard is finalized.
Most features can be categorized like this, they're either so simple and stable that their implementation in GCC/MSVC are exactly how they're going to work in the final standard, or they're tricky enough that they might get a few bugfixes applied, and so they can be used today, but you run the risk of running into a few rough edges in certain border cases.
It does sound silly to avoid C++0x feature solely because they're not formalized yet. Avoid the features that you don't trust to be complete, bug-free and stable, but use the rest.
Theoretical but not practical disadvantages of using C++0x:
Makes it harder to port to different compilers.
Not adhering to any published standard.
Practical advantages of using C++0x:
Makes your daily lives easier, hence more productive.
It's a debate between what's theoretically right, and what's practical. If your team has any intent of actually doing something with this code, the practical should outweigh the theoretical tenfold.
One thing you don't need to (mostly) worry about now is features being added or taken away because the working draft reached "Final Committee Draft" (FCD) back in march. Feature-wise should be frozen, standards committee will not accept any-more proposals for C++0x.
Downside is it's still a draft and not finalized yet, the standards committee are in the phase of making corrections and adjustments before finalizing and publish the ISO standard (expected release to be march 2011). That could mean minor syntactic or semantic/behaviour changes which could make your code not compilable or not work correctly once you compile with a compiler that is more standard compliant than the one you're using at the time you wrote the code.
You'll probably have to wait sometime for compilers like VC++10 to get update with any corrections/adjustments made.
We had the exact same problem so we compromised. We took the C++ 0x TR1 release and then only took the portions that we knew we wanted to use. Sounds like a lot of work, but so far it's worked out well. We're using the regex libraries, tuples, and a couple of others. Once the standard is ratified, then we'll migrate to the full C++ 0x. This obviously isn't the best solution but it was one that has worked well for us.
If you intend to make your system open source within a not-too-far future, then that's an argument for not using too many bleeding-edge features. A production system running Debian or Red Hat won't necessarily have a bleeding-edge compiler installed.
You said
if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform
but that a compiler exists for a platform doesn't always mean that it's installed/used/wanted, especially on production systems.
If, on the other hand, you intend to do all the compiling yourself, this is not an issue.

What's the future of std::valarray look like?

Up until fairly recently I hadn't been keeping up with the C++11 deliberations. As I try to become more familiar with it and the issues being worked, I came across this site which seems to be advocating for deprecating or removing std::valarray since most people are using Blitz++ instead. I guess I'm probably one of the few people out there who still uses std::valarray (and yes I know the class has a sordid past, a tarnished present, and a questionable future). But, it does what I need, and perhaps more important, it's part of the standard (for now any way).
Aside from the one site above, I've been able to find very little on what is actually happening with std::valarray in the new standard, and was hoping that somebody on SO might be able to provide some insight and / or references where Google, Wikipedia and even the C++ Standards Committee Web Site have so far failed me. Thanks.
std::valarray is included in C++11. It has not been deprecated or removed. It has been updated to include move operations
std::valarray is defined in ยง26.6[numarray] of the C++11 language standard.

Has the STL changed much?

I'm wanting to become conversant in the use of the Standard Template Library. If I come across a general reference or beginner's guide published around 1995-97, can I rely on the information in it? How much has STL changed in the last dozen years?
Yes! There are new additions. The TR1 update is now implemented in most environments.
Your older book is still useful to learn the basics. But you will want to find a reference for TR1 to learn about some very useful new features. In a couple of areas, the new features are preferred over older ones. (What comes to mind is bind1st and bind2nd functionality is fully encapsulated in the more general bind construct.)
In addition, there are the boost libraries. (boost.org) Boost is a a collection of libraries, some are very useful, others are obscure. Some of the features in TR1 came from boost, so there is some overlap. There is at least one good book about Boost out there.
Not a whole lot, if at all. The current standard was published in 1998.
cplusplus.com has a more up-to-date reference, which you can compare for yourself.
I'd recommend also that you get a copy of Scott Meyers' Effective STL.
I like the SGI reference to the STL
http://www.sgi.com/tech/stl
Which includes a set of resource for further reading
http://www.sgi.com/tech/stl/other_resources.html
I think that this documentation was done by the crater of the STL (could bee wrong on that).
But the STL has not changed since it was made official.
The new additions for TR1 are currently not officially available but will be part of the new standard. Though you can grab them via boost. Which is another set of libraries you should look at.