🚀 go-pugleaf

In article <4cteo4$32o@netlab.cs.rpi.edu>
Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:

|> >> |> The design of the exception classes has changed since Plauger's book was
|> >> |> written, and class "exception" no longer has a member function "raise".
|> >> |> The exception classes now have only
|> >> |>      default constructor
|> >> |>      copy constructor
|> >> |>      assignment operator
|> >> |>      virtual destructor
|> >> |>      virtual function "const char* what() const;"
|> >> 
|> >> |> The "what" function returns an implementation-defined null-terminated
|> >> |> character string.

|> I would suggest that it will return a :

|> typeid(*this).name() 

|> as the standard default behavior. This way we don't add another global
|> string to  the executable's data area, and we re-use the already existing
|> string ( which represents the name of the exception ).

I don't think so.  I would expect that the actual string will depend
upon the environment.  My interpretation of what is desirable is an
outputtable string, which could potentially be part of an error
message; the class name would hardly qualify.

In my own implementation, the string does depend on the environment
(environment variables LC_ALL, LC_MESSAGE and LANG).  I would expect
that this is the standard situation.

|> >> Does this include the constructors?  I don't see where this is stated in
|> >> the draft, and as most of the constructors (except bad_alloc and
|> >> bad_exception) take a reference to a string, I would expect them to
|> >> invoke the copy constructor for string, which I presume *can* throw
|> >> bad_alloc.

|> I believe that the string class would best implememnted as a
|> copy-on-change class, which means that the copy-constructor will not
|> actually duplicate the string but will increase the reference counter it
|> uses.

I don't believe that copy on write is allowed in the current draft.
Each string can have its own unique allocator; how do you implement
copy on write in such cases?  (Hmmm...  Maybe this is the answer to my
question.  The string in the exception class uses an allocator that
gets its memory from a special pre-reserved area.)

Even if copy on write were allowed, I can think of many reasonable
implementations in which string::data() (or string::c_str()) may throw
bad_alloc.  Maintaining the physical data internally as a contiguous
buffer makes most of the string manipulation functions relatively
expensive on long strings.  (Since I only use very short strings, this
doesn't bother me.  But it is a point that an implementor may want to
consider.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone