No sorry. Most of my time has been spent on just getting the correctness tests in. There are no performance tests in the test suite at this time. I'd love to get some donated though.
I see this on the webpage:
• Fast execution.
• Minimal memory use.
• Fast compile times.
Any early numbers?
No sorry. Most of my time has been spent on just getting the correctness tests in. There are no performance tests in the test suite at this time. I’d love to get some donated though.
Speaking of test suites, any thoughts about using GoogleTest? Despite some of its crazier bits and pieces (hehe), the basics make for very nice unit tests. I can also contribute a lot of help with test runners etc for other build systems as I work on GoogleTest.
I’m also looking at adding performance testing to GoogleTest before too long so that might dovetail nicely.
I haven't looked at GoogleTest. I'll look into it.
One of the things I like about the current test suite is its simplicity. It consists of a single shell script 175 lines long. That means if it isn't doing what one wants, it is easy to change it without too much trouble. It is also set up to report "unimplemented sections." That is, the test suite has a directory for every sub-section in the working draft. If a directory doesn't have any tests, that sub-section is reported as unimplemented (as opposed to just being silently forgotten).
I see this on the webpage:
• Fast execution.
• Minimal memory use.
• Fast compile times.
Any early numbers?
No sorry. Most of my time has been spent on just getting the correctness tests in. There are no performance tests in the test suite at this time. I’d love to get some donated though.
Speaking of test suites, any thoughts about using GoogleTest? Despite some of its crazier bits and pieces (hehe), the basics make for very nice unit tests. I can also contribute a lot of help with test runners etc for other build systems as I work on GoogleTest.
I’m also looking at adding performance testing to GoogleTest before too long so that might dovetail nicely.
I haven’t looked at GoogleTest. I’ll look into it.
One of the things I like about the current test suite is its simplicity. It consists of a single shell script 175 lines long. That means if it isn’t doing what one wants, it is easy to change it without too much trouble.
No complaints there, and frankly, that’s almost exactly how GoogleTest works too – every test is its own executable, standard unix ideas of success and failure for that executable. The nice parts of GoogleTest would be the reports that failed tests produce, etc; basically the code of the test. The only changes I could conceive up to the way tests are run is to get parallelism, but I’m not fond of complex text runners either.
It is also set up to report “unimplemented sections.” That is, the test suite has a directory for every sub-section in the working draft. If a directory doesn’t have any tests, that sub-section is reported as unimplemented (as opposed to just being silently forgotten).
That’s awesome, and I’d not want to loose it either. (I had already seen this in svn, was excited about the idea.)
I have a lot of respect for libstdc++ and for all of those who have worked on it over the years. I've tried to build a better library. Maybe I've succeeded, maybe I haven't (most likely I have in some places and not in others). I do know that no parts would be better if I did not try.
I'll also openly state that this library has been targeted straight at Apple's platforms (for the benefit of Apple's customers). That being said, most of the library is portable. We feel that others may benefit from the generous open source license for this library.
Nothing. We still support libstdc++ 4.2. Howard is just saying that the implementation to date has been focused on making it work on Apple platforms, without much concern so far for portability etc.