On Oct 1, 6:25 pm, stefan.heinzm...@arcor.de (Stefan Heinzmann) wrote:
> The subject line says it.

No, but why do you want to do this?

> What workarounds are there?

None that I know of.  Where would you go if you caught them?

> Is there any motion for supporting it in a future version of the
> standard? Maybe with function try blocks in main()?

> Or are there good reasons why it should not be allowed, or
> hard/impossible to implement?

The question is what it would mean.  Normally, if a constructor
exits via an exception, the object doesn't exist, and there's no
way to access it.  Static objects are always accessible,
everywhere.  Doing anything but terminating the program would
violate this contract.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 1 Okt., 21:51, James Kanze <james.ka...@gmail.com> wrote:
> > Is there any motion for supporting it in a future version of the
> > standard? Maybe with function try blocks in main()?
> > Or are there good reasons why it should not be allowed, or
> > hard/impossible to implement?
>
> The question is what it would mean.  Normally, if a constructor
> exits via an exception, the object doesn't exist, and there's no
> way to access it.  Static objects are always accessible,
> everywhere.  Doing anything but terminating the program would
> violate this contract.

Due to my own hesitation you gave nearly the answer I where
about to write ;-). And exactly at this point I considered the
possibility that one might want to catch the exception, write a
proper log entry (or some other user-feed back) and than quit.

This would be a little bit different than using the terminate handler
for this because I have no access to the most recent exception
any more. On the other side this argumentation weakens,
once the newly proposed facility "current_exception" is accepted,
see [propagation] in the most recent draft N2369 or in the
header <exception> synposis thereof ([support.exception]).

Greetings from Bremen,

Daniel

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 1, 12:25 pm, stefan.heinzm...@arcor.de (Stefan Heinzmann)
wrote:
> The subject line says it.
>
> What workarounds are there?
>
> Is there any motion for supporting it in a future version of the
> standard? Maybe with function try blocks in main()?
>
> Or are there good reasons why it should not be allowed, or
> hard/impossible to implement?
>
> Cheers
> Stefan
>
> ---

Will a function-try-block on the ctor do what you want?  See 15/3.

---
Randy

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 2, 2:43 am, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> Due to my own hesitation you gave nearly the answer I where
> about to write ;-). And exactly at this point I considered the
> possibility that one might want to catch the exception, write a
> proper log entry (or some other user-feed back) and than quit.

If you need that sort of thing, you can always wrap the variable in
question in your own little helper class which has a try-block in
constructor. For your specific case (writing logs), it could even be a
single template to cover all your globals.


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2 Okt., 19:18, int...@gmail.com wrote:
> If you need that sort of thing, you can always wrap the variable in
> question in your own little helper class which has a try-block in
> constructor. For your specific case (writing logs), it could even be a
> single template to cover all your globals.

Although this is generally a reasonable approach - especially for
straightforward applications - the above described
last-chance-to-explain-something behaviour might be what you
need, if you have a very large modularized application where
one very deep component - you did not belief at all that this
component did exist at all (maybe the part of a thirdparty
library, where you have no source code available) - throws in
one of it's global object constructions. Plug-in-based applications
are full of these things and this would be at least a little
accommodation to your customer...

Greetings from Bremen,

Daniel Kr   gler


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 2, 8:40 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> On 2 Okt., 19:18, int...@gmail.com wrote:

> > If you need that sort of thing, you can always wrap the variable in
> > question in your own little helper class which has a try-block in
> > constructor. For your specific case (writing logs), it could even be a
> > single template to cover all your globals.

> Although this is generally a reasonable approach - especially for
> straightforward applications - the above described
> last-chance-to-explain-something behaviour might be what you
> need, if you have a very large modularized application where
> one very deep component - you did not belief at all that this
> component did exist at all (maybe the part of a thirdparty
> library, where you have no source code available) - throws in
> one of it's global object constructions. Plug-in-based applications
> are full of these things and this would be at least a little
> accommodation to your customer...

For plug-ins there's no problem, since you can put a try/catch
around the call to load the plug-in.  (The real problem, of
course, is knowing the types you have to catch:-).)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 4 Okt., 22:53, James Kanze <james.ka...@gmail.com> wrote:
> On Oct 2, 8:40 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
> wrote:
>
> For plug-ins there's no problem, since you can put a try/catch
> around the call to load the plug-in.  (The real problem, of
> course, is knowing the types you have to catch:-).)

I don't know why I wrote it in this way. You are right, I don't
want to say plugins, but actually I meant static libraries.

Thanks for your correction,

Daniel


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]