🚀 go-pugleaf

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                             ]

Rich Paul <rpaul@trcinc.com> wrote:
> I am currently implementing, from the working paper, class
> basic_string.  ...
>  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?

(I assume Paul means Allocator::deallocate.)
The requirements on a character type used as an element
of a string certainly should be documented, at least as 
well as are other template parameters in the Draft.  As
I recall, this was an open issue for the Strings chapter,
but the expectation was that characters would be assumed to 
to have (at most) ignorable constructors and destructors.

I have some good news and bad news for Paul ... 
The bad news is that the traits and allocator interfaces were
both changed at the March '96 meeting.  The good news is that
both are considerably simpler than before.

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/


[ 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                             ]