phimsch@vnet3.vub.ac.be (Peter Himschoot) writes:
:
: Where can I find information about how exceptions are implemented ?
:
:  (   I know, in the german magazine Siggy's writing for ...      [ :-)   )
:
: Thanx  !
:
: Peter
:

You can find a brief explanation in C++ Report, (March-April 1994) "Exception
Handling. Supporting the runtime mechanism" by Josee Lajoie. (pronunciation?!)


''''  |||    |||    |||))   |||||||||||||||||||||||||||||||||||||||||||||||||||
''''  |||  --+++--  ||| ))  || Juan Fernandez Vazquez. Telefonica I+D (R&D)  ||
****  |||  --+++--  ||| ))  || jfv@tid.es  TLF: +34 1 337 39 17 FAX:...42 22 ||
****  |||    |||    |||))   |||||||||||||||||||||||||||||||||||||||||||||||||||

Exceptions (see for example ``The C++ Programming Language (2nd edition)''
Chapter 9) allow errors to be reported from constructors and overloaded
functions. If your compiler doesn't yet support exceptions see Andy Koenig's
column in The C++ Report for techniques to survive until exceptions arrive.

>    Suppose the constructor should fail for some reason, such as a low
> memory condition during the "el2" buffer allocation.   What is the
> best way of indicating constructor failure so that action may be taken
> by the main program ?

Use a two step initializing by having a constructor that does not (!)
allocate any memory and for example a memeber function Create()
that does the allocation. Create could then return an error code

>    Suppose the overloaded assignment should fail for some reason, such
> as a low memory condition when allocating a new buffer for
> "obj2cls1.el2".  What is the best way of indicating assignment failure
> so that action may be taken by the main program ?

If your Compiler supports it you could use exceptions. I am not
experienced in using exceptions but at short you will have the
possibility to setup some conditions (for example low memory)
and you are able to define actions to be taken if this condition
occurs.

Hope, I could help at least for your first problem
Ronald

--

-------------------------------------------------------------------------
Ronald HASENBERGER                                  Hasenberger@elin.co.at
ELIN-Energieanwendung GesmbH
A-1141 Vienna, Austria, Penzingerstr.76
Phone: +43 1 89100-3524                     Fax: +43 1 8946046

Hello everyone,

this is the 1st time I'm posting in a newgroup where 'the big boys play',
so fogive me if I'm violating the netiquette.

On 17 May 94 bs@alice.att.com (Bjarne Stroustrup)  posted:

[...]
> functions. If your compiler doesn't yet support exceptions see Andy Koenig's
> column in The C++ Report for techniques to survive until exceptions arrive.

Is anybody out there to give an exact reference (issue, etc.), I never heard
from this publication before. I am currently writing an article for
a german magazine on a run-time implementation of exceptions using MI for
stack unwinding, which I have used with various compilers for MS-DOS.
Andy Koenig's approach might open additional aspects.

Thx in advance,
Siggy
--
CU, bsb@bora.ms.sub.org
----------------------------------------------------------------------
bernd s. brentrup  //#   ##  ###           phone: +49-251-864978 (VFD)
hensenstr. 181    //  # #  # #  #           fido:        2:2449/504.21
d 48161 muenster //#  # #  # #  #         gernet:       21:490/2004.21
frg             //  ##   ##  ###  && C++     cis:          100045,2454
----------------------------------------------------------------------
## CrossPoint v3.02 ##

In article <5P9DS3zMgLB@bora.ms.sub.org> Bernd _Siggy_ Brentrup,
bsb@bora.ms.sub.org writes:
>Is anybody out there to give an exact reference (issue, etc.), I never
heard
>from this publication before. I am currently writing an article for
>a german magazine on a run-time implementation of exceptions using MI for
>stack unwinding, which I have used with various compilers for MS-DOS.
>Andy Koenig's approach might open additional aspects.
>
>Thx in advance,
>Siggy
>--
>CU, bsb@bora.ms.sub.org

Where can I find information about how exceptions are implemented ?

 (   I know, in the german magazine Siggy's writing for ...      [ :-)   )

Thanx  !

Peter

+-----------------------------------------------------------------------+
| Peter Himschoot                     E-mail   phimsch@vnet3.vub.ac.be  |
| Programming Technology Lab          Phone    (+32) 2-6413491          |
| Computer Science Department         Fax      (+32) 2-6413495          |
| Vrije Universiteit Brussel          Pleinlaan 2                       |
| B-1050 Brussels                     Belgium                           |
+-----------------------------------------------------------------------+

Greetings...

     I am relatively new to C++, having learned it on my own after
programming in C for many years.  I am converting some of my source
files to C++ from C, and I have a few questions.  These are as
follows:

     Consider the following short program, where the member "el2"
points to a dynamically allocated buffer :

class cls1 {
   int el1;
   char *el2;
};

main()
{
   cls1 obj1cls1, obj2cls1;
   ...
   obj2cls1=obj1cls1;
   ...
}

   Suppose the constructor should fail for some reason, such as a low
memory condition during the "el2" buffer allocation.   What is the
best way of indicating constructor failure so that action may be taken
by the main program ?

   Suppose the overloaded assignment should fail for some reason, such
as a low memory condition when allocating a new buffer for
"obj2cls1.el2".  What is the best way of indicating assignment failure
so that action may be taken by the main program ?

Several solutions seem to suggest themselves to me, but I have
concerns about them.  Some of these solutions are :

Global error flag :

     I prefer to avoid the use of global variables whenever possible.

Argument to the constructor or assignment :

     This one is easy to implement for constructors, but could be
difficult to implement for overloaded operators like the assignment.
There seems to be no place to put an argument to the assignment.

Error flag internal to the object :

     If the object itself is to be dynamically allocated, and the
allocation fails, there is no object to hold the flag to be tested.

I would greatly appreciate any suggestions anyone has to offer.

                                                    With Thanks......

___________________________________________________________________
                  |         Internet: VISHART@ubvms.cc.buffalo.edu
Joe Hart          |     ///    Plink: OSS542
Niagara Falls, NY | \\\///  Ham call: WA2SND
                  |  \XX/   AMIGA - Computers for REAL MEN
===================================================================

JOSEPH F. HART (vishart@ubvms.cc.buffalo.edu) wrote:
> Greetings...

>      I am relatively new to C++, having learned it on my own after
> programming in C for many years.  I am converting some of my source
> files to C++ from C, and I have a few questions.  These are as
> follows:

>      Consider the following short program, where the member "el2"
> points to a dynamically allocated buffer :

> class cls1 {
>    int el1;
>    char *el2;
> };

> main()
> {
>    cls1 obj1cls1, obj2cls1;
>    ...
>    obj2cls1=obj1cls1;
>    ...
> }

>    Suppose the constructor should fail for some reason, such as a low
> memory condition during the "el2" buffer allocation.   What is the
> best way of indicating constructor failure so that action may be taken
> by the main program ?

IMHO, the best way is to throw an exception.

If your compiler does not yet support exceptions, I've seen various
ways of indicating an error during construction.  One such way is to
write a member function ok() which returns true if the object is ok
to use.

>    Suppose the overloaded assignment should fail for some reason, such
> as a low memory condition when allocating a new buffer for
> "obj2cls1.el2".  What is the best way of indicating assignment failure
> so that action may be taken by the main program ?

Same answer as above.

> Several solutions seem to suggest themselves to me, but I have
> concerns about them.  Some of these solutions are :
> Global error flag :
>      I prefer to avoid the use of global variables whenever possible.

This is wise, globals create reentrancy problems.

> Argument to the constructor or assignment :
>      This one is easy to implement for constructors, but could be
> difficult to implement for overloaded operators like the assignment.
> There seems to be no place to put an argument to the assignment.

You've discovered a very good reason for using exceptions -- when
there is no other [convenient] way to report the error.

> Error flag internal to the object :
>      If the object itself is to be dynamically allocated, and the
> allocation fails, there is no object to hold the flag to be tested.

If dynamic allocation (operator new) fails, it will throw an exception
if the compiler supports exceptions.  Otherwise it will return zero.
Either way, you should know about the failure.  But object assignment
and dynamic allocation of objects are separate operations.