I am currently implementing, from the working paper, class
basic_string.  I'm not sure on a couple of things.  The first is
if the standard says:

insert ( const basic_string bs&str )
 Does this and that
insert ( charT *cp )
 insert ( basic_string ( cp );

am I non-complient if I put the real code in the charT* overload
and have the other call it?  I'm not sure the level of
complience that is required ...

Also, is there a validation suite that can put this class
through it's paces?

One more thing ... before calling traits::deallocate, should I
explicitly call destructors on the charT's in my array, since it
may be a class type, or does the definition of charT as being
'char-like' preclude this?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <3147413B.B10@trcinc.com> Rich Paul <rpaul@trcinc.com>
writes:

|> I am currently implementing, from the working paper, class
|> basic_string.  I'm not sure on a couple of things.  The first is
|> if the standard says:

|> insert ( const basic_string bs&str )
|>  Does this and that
|> insert ( charT *cp )
|>  insert ( basic_string ( cp );

|> am I non-complient if I put the real code in the charT* overload
|> and have the other call it?  I'm not sure the level of
|> complience that is required ...

At the most, only the externally observable behavior counts.  How you
implement the functions is your business.  (In some cases, certain
variations in the externally observable behavior are also allowed.)

|> Also, is there a validation suite that can put this class
|> through it's paces?

Is there a compiler which will compile it if it is complete?

|> One more thing ... before calling traits::deallocate, should I
|> explicitly call destructors on the charT's in my array, since it
|> may be a class type, or does the definition of charT as being
|> 'char-like' preclude this?

Good question.  In my implementation, I suppose that charT must have a
trivial constructor and destructor, but that is largely because of
laziness on my part; I know of nothing in the standard to support this.

Note that the destructors are not the only problem: you also need the
constructors.  More important, when inserting into the stream (and thus
shifting data up), you have to be careful to use the constructor on raw
memory, but assignment on memory that has already been constructed.
Typically, this will mean that you will have to use uninitialized_copy
for part of the shift, and copy_backward for the other.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]