Mailing-List: contact stdcxx-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-user@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <432075CE.8070806@roguewave.com>
Date: Thu, 08 Sep 2005 11:33:02 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716
MIME-Version: 1.0
To: stdcxx-user@incubator.apache.org
Subject: Re: informix
References: <73eb635e05090800335e9b8109@mail.gmail.com>
 <43204E75.40008@roguewave.com> <4320539F.7060004@googlemail.com>
 <43205A84.9020903@roguewave.com> <43206F78.2010104@googlemail.com>
In-Reply-To: <43206F78.2010104@googlemail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

okki wrote:
> 
> thanks for clarification, roguewave did some fine job.

Thanks!

> 
> i know i'm hitchhiking my own thread

That's fine, although I admit I am a little confused by the subject
you chose for the thread (informix?)

> but did you do performance 
> measurement/comparison with alternative std implementations?
> gnu,stdcxx,uClibc++,... ?

Yes. I have a paper with some details but as Amit says, it hasn't
been cleared for external consumption yet.

Overall, our implementation compares favorably to most others on
most of my benchmarks (I haven't used any third party ones). We
have a significant edge on every other implementation when it
comes to compilation speed, the size of generated object files
and executables, and the size of data. (This would suggest that
our implementation should do well in embedded environments).

When it comes to runtime efficiency, AFAIK, STLport comes closest
to our numbers and sometimes exceeds them. That's not to say that
stdcxx is always faster than anything else. We do have weaknesses
that we need to work on (floating point formatting comes to mind
as one of the big offenders since we use stdio. Contributions in
this area (or any other for that matter) are welcome! :)

Martin

> 
> 
> 
>> okki wrote:
>>
>>>>> just wanted to tell you that stdcxx compiles just fine within 
>>>>> interix/sfu 3.5.
>>>
>>>
>>>
>>> just when i thought everythings ok :) ... (well its still ok, but)
>>> how do i get rid of the "-lsupc++" requirement? does stdcxx still 
>>> rely on some parts of gcc?
>>
>>
>> Yes, it certainly does :) libsupc++ is the language support library,
>> implementing such facilities of core C++ language as exceptions, RTTI,
>> and dynamic memory allocation (operators new and delete). There's no
>> way to write even the simplest C++ program without it (actually, there
>> is, but those usually are too simple to be useful).
>>
>> The vast majority of compilers provide such a library, some as an
>> archive, some in the form of a shared library. If you are using the
>> native C++ standard library that comes with the compiler the support
>> library is linked in implicitly by the driver (or, in the case of
>> gcc, it's actually part of libstdc++ itself), so you don't see it
>> on the command line. When using a third party implementation of the
>> C++ standard library such as stdcxx, you must avoid linking in the
>> native implementation (to avoid ODR violations). With GCC you do
>> it by using the gcc command instead of g++ for linking and by also
>> specifying -lsupc++.
>>
>> I suppose you might be able to link libsupc++.a directly into the
>> stdcxx library and avoid explicitly mentioning it on your program's
>> link line but I haven't tried it.
>>
>>>
>>> gcc -D_RWSTD_USE_CONFIG -Istdcxx/include/ansi \
>>> -Istdcxx/include -Iinclude -nostdinc++ \
>>> src/*.cpp -O3 -o testcase.exe -B,static \
>>> -Lstdcxx/lib -lstd -lsupc++ -B,dynamic -ldl -s
>>>
>>> thanks in advance
>>>
>>> (ah btw: why incubator? compiled a whole lot of classes without any 
>>> modifications! out of the box! that's really cool :)
>>
>>
>> Incubation isn't necessarily a reflection of the state or quality of
>> the code (in the case of stdcxx, the project has been in development
>> and active use for over 10 years so it's quite mature by now).
>>
>> Every project donated to Apache must go through the incubator first
>> to make sure all legal issues (such as copyright/license transfers)
>> have been completed and the project itself has been fully migrated
>> to the ASF infrastructure (source code repository, bug tracking
>> database, Web site, etc.) before the ASF takes formal ownership of
>> it. The incubation period is also a good opportunity for maintainers
>> of the project who are new to Apache to learn the ropes (i.e., get
>> the "Apache Way" -- how to work within the organization, get to know
>> people, establish a development community around the project, etc.)
>>
>> Martin
>>