This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.
Hey--just a couple of points.
1) About -fnew-abi. I'm getting different errors than you. Here's mine:
g++ -DHAVE_CONFIG_H -I. -I../../src.libstdc++/src -I.. -nostdinc++
-I../../src.libstdc++ -I../../src.libstdc++/stl -fno-implicit-templates
-D_GNU_SOURCE -g -fnew-abi -c -fPIC -DPIC
../../src.libstdc++/src/complex.cc
../../src.libstdc++/src/complex.cc: In function `class
std::complex<double> std::polar(const double &, const double &)':
../../src.libstdc++/src/complex.cc:90: no matching function for call to
`cos (const double &)'
../../src.libstdc++/src/complex.cc:90: no matching function for call to
`sin (const double &)'
../../src.libstdc++/src/complex.cc: In function `class
std::complex<double> std::log10(const class std::complex<double> &)':
../../src.libstdc++/src/complex.cc:125: no match for `complex double /
std::complex<double>'
../../src.libstdc++/src/complex.cc: In function `class
std::complex<double> std::pow(const double &, const class
std::complex<double> &)':
../../src.libstdc++/src/complex.cc:150: no match for `complex double *
std::complex<double>'
make: *** [complex.lo] Error 1
I believe these errors are fixed with the shadow script, meaning you'll
have to shadow your headers first. I'm having problems with it, but it
should work, and in any case it seems like it'll be fixed quickly. How to
do this (courtesy of nathan:)
I have more-or-less-finished wrapping the C library in the "std::"
namespace. The library should now be compatible with unadulterated
"-fnew-abi".
To use it, first get an updated libstdc++-v3 tree. Then at the top
level run the script
inclosure -I [path to your Egcs private headers] -I /usr/include
[bkoz note: path is same as what you'll see with g++ -v test.cc, ie
something like:
#include "..." search starts here:
#include <...> search starts here:
/nfs/rhino/plate/bkoz/H-x86-egcs/include/g++-2
/nfs/rhino/plate/bkoz/H-x86-egcs/include
/nfs/rhino/plate/bkoz/H-x86-egcs/i686-pc-linux-gnu/include
/nfs/rhino/plate/bkoz/H-x86-egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.02/include
/usr/include
thus just do -I for all of these, ie
-I/nfs/rhino/plate/bkoz/H-x86-egcs/include/g++-2
etc.
end note]
and see if it complains about <machine/ansi.h> or something.
(This is a bash/ksh script, sue me.) If so, say
inclosure -I [your Egcs private headers] -I /usr/include \
-G machine/ansi.h
and add -G options until you get a clean run. Then say:
inclosure -I [your Egcs private headers] -I /usr/include \
-G machine/ansi.h [etc] | mkcshadow
This will create a tree of shadow headers to correspond to those
files in your /usr/include (etc) tree that are used by standard
headers.
Now, when building, the compiler options should include:
-fnew-abi -I$dir/shadow -I$dir/cshadow -I$dir/std -I$dir
Eventually we will dispense with shadow/, and fold its contents
directly into bits/ and std/, but for now I propose to keep
them separate until the shadow header scheme is better-tested.
As it is it has only been tested with glibc-2.0, and will
certainly need (probably minor) tweaks to work on Solarix.
Note that the "bad alias" bug I reported last week makes this
incompatible with Egcs-1.1 (and current snapshots?) when compiling
programs that include <.h> headers directly. :-(
Anyway--just assume that -fnew-abi will work, and go ahead with the
derivation from iterator.
2) about ChangeLog entries:
1999-01-20 Philip Martin <pm@corris.dircon.co.uk>
* bits/basic_string.h: Add iterator hooks.
* bits/string.tcc: Ditto.
* bits/std_sstream.h: Ditto.
* src/misc-inst.cc: Ditto.
* src/os_raw.cc: Ditto.
* stl/bits/stl_iterator.h: Ditto.
* stl/bits/stl_vector.h: Ditto.
* testsuite/24/24iterator.cc: Add testcase for string and vector
iterators.
This is what it should look like. Please append to every patch. . . see
http://egcs.cygnus.com/contribute.html for the low-down. Would it be
easier if I put up a page linked off the libstdc++ page about this and
other style issues? (Note that emacs users can just to (Cx-4a) to bring up
the ChangeLog. . .)
3) names. Two things. . .
a) _Self. I don't like this convention (which I guess started in
deque::iterator?) -- it seems confusing. I'd rather have things like
+ typedef basic_string<_CharT, _Traits, _Alloc> _Self;
changed to
+ typedef basic_string<_CharT, _Traits, _Alloc> string_type;
which seems far more intuitive to me. Can anybody trace this usage, or
give me a compelling reason for the introduction of it?
b) _PointerIterator. Which is it, a pointer or an iterator? ;)
First, it adds yet another naming convention, _PsomeUpper, when we have
some_upper from standard c++, and things like _Alloc_hider from our
styleguide. Second, look at stuff like
template <int __inst>
class __malloc_alloc_template {
these are long, difficult to parse names that explain exactly what the
class does. To me, this means some abbreviation of "random access
iterator." It doesn't matter if it is the random access iterator used in
deque, as it is clearly labled what deque uses. Hmm, maybe we could do
something like
typedef __random_access_iterator<Tp, string<Tp...> > _String_iterator;
?? What do you think?
Other than these relatively minor quibbles, I have no problems with your
approach or implementation. Nice job.
-Benjamin