In article <37C5571F.CE3802EE@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

> PS: Does anyone use "return EXIT_SUCCESS;"?

I usually use "return ProgStatus.instance().returnCode()".  What it maps
to in case of success is platform dependant -- the default is
EXIT_SUCCESS, but the Unix implementation uses 0.

The reason is simple: I have my own return codes: SUCCESS, WARNING,
ERROR, FATAL, INTERNAL.  The default mapping is for the first two to map
to EXIT_SUCCESS, and the others to EXIT_FAILURE.  Under Unix, however,
they map to assending integers.  And WARNING is a bad name, because it
is really a second success, used for cases like grep, where you return 1
if you don't find any matches.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

whbloodworth@my-deja.com schrieb:
>
> int main (void) { }
>
> VC++ produces the following warning:
>
> warning C4508: 'main' : function should return a value; 'void' return
> type assumed

[snip]

another (maybe even more) funny thing:

int func (int Int)
{
 if (Int)
 {
  return 0;
 }
 throw ("I dont need a return statement!");
}

Visual 5 will give an error C2202 (yes, an _error_): not all branches return
a value (or so)...

LOL!

Cheers,
Daniel
(kaeps _at_ informatik.uni-leipzig.de)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com wrote:

[...]

> Seriously, I wouldn't change it to void main unless my code was so
> riddled with Microsoft'isms that there was no chance of it ever running
> elsewhere anyway.  It's a warning, not an error ; if suppressing it is
> an issue (and I agree it should be), then IMHO piping the output of the
> compiler through sed is the easiest and the best way.  It is, at any
> case, the solution I've always used.  (Yes, including with VC++.)

Another obvious solution is to simply add "return 0;" to the
end of main. This is conforming and will satisfy VC++.
Some even consider it good style ;-)

PS: Does anyone use "return EXIT_SUCCESS;"?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
...
> PS: Does anyone use "return EXIT_SUCCESS;"?

Yes. That's what I normally use. It's self-documenting, which is an
advantage over 0. There's also an off-chance that EXIT_SUCCESS is
defined as something other than 0, in which case EXIT_SUCCESS is
probably better than 0, in some highly implementation-dependent way.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer <nospam.gregb@hal-pc.org> wrote...
> sorry, I don't use exceptions.

Why?

Performance overhead? Philosophy?

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.gregb@hal-pc.org> writes:

> > int main (void) { }
> > VC++ produces the following warning:
> > warning C4508: 'main' : function should return a value; 'void' return
> > type assumed
> >
> > "void return type assumed" ???? What ? void assumed?
>
> This warning is no different than any other function without a return.  I
> think you will find that if you change it to
>    void main(void) {}
> it will compile without any complaints.

Yes, that's the problem.  The warning suggests that you take a legal
program (3.6.1/5: "If control reaches the end of main without
encountering a return statement, the effect is that of executing
return 0;") and turn it into an illegal program. (3.6.1/2: "An
implementation shall not predefine the main function... It shall have
a return type of int.")
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> <whbloodworth@my-deja.com> wrote in message
> news:7ps1sg$dev$1@nnrp1.deja.com...
....
> > int main (void) { }
> > VC++ produces the following warning:
> > warning C4508: 'main' : function should return a value; 'void' return
> > type assumed
> >
> > "void return type assumed" ???? What ? void assumed?
>
> This warning is no different than any other function without a return.  I
> think you will find that if you change it to
>    void main(void) {}
> it will compile without any complaints.

Which would be yet another problem with the compiler.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7pu4es$1mv3$1@news.hal-pc.org>, Greg Brewer
<nospam.gregb@hal-pc.org> writes
>This warning is no different than any other function without a return.  I
>think you will find that if you change it to
>   void main(void) {}
>it will compile without any complaints.

Of course, but it will not be conforming C++.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> <whbloodworth@my-deja.com> wrote in message
> news:7ps1sg$dev$1@nnrp1.deja.com...
> >
> > The standard states that 'unexpected' will be called if a function
> > throws something other than what is specified in the throw
> > specification.  For example,
> > class E : public logic_error { };
> > class F : public logic_error { };
> > void Foo (void) throw (E)
> > {
> >    throw F(); // should call unexpected()
> > }
> > Using M$ VC++, the above function Foo will successfully (depending on
> > how you look at it) throw F() and the caller can catch it.
>
> sorry, I don't use exceptions.

So does that mean you don't use the standard C++ library? Just curious..
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 24 Aug 99 20:53:22 GMT, "Greg Brewer" <nospam.gregb@hal-pc.org> wrote:

><whbloodworth@my-deja.com> wrote in message
>news:7ps1sg$dev$1@nnrp1.deja.com...
>
>> Also, M$ will warn the developer if he/she does not return a value from
>> main...which I can live with despite the fact that the C++ standard also
>> states that main implicitly returns 0 if not specified.  The problem is
>> with their warning.  Given the following:
>>
>> int main (void) { }
>> VC++ produces the following warning:
>> warning C4508: 'main' : function should return a value; 'void' return
>> type assumed
>>
>> "void return type assumed" ???? What ? void assumed?
>
>This warning is no different than any other function without a return.  I
>think you will find that if you change it to
>   void main(void) {}
>it will compile without any complaints.
>
>Greg Brewer

This warning is quite different from all other functions without return
values. See below (3.6.5). As commented by W.Bloodworth, VC++ is warning
about well-defined legal C++. I don't know if it will return 0 as required
by the standard, but it indicates that it will not (void type assumed).

If you change it to void main(void) {}, as you suggest, you no longer have
a valid ISO C++ program. (3.6.2 - It shall have a return type of type int).

(from the C++ Standard)
3.6.1  Main function

1 A  program  shall  contain a global function called main, which is the
  designated start of the program.  It is implementation-defined whether
  a  program  in a freestanding environment is required to define a main
  function.
...

2 An implementation shall not predefine the main function.   This  func-
  tion  shall  not  be  overloaded.  It shall have a return type of type
  int, but otherwise its type is implementation-defined.  All  implemen-
  tations shall allow both of the following definitions of main:
          int main() { /* ... */ }
  and
          int main(int argc, char* argv[]) { /* ... */ }
...

5 A return statement in main has the effect of leaving the main function
  (destroying  any  objects with automatic storage duration) and calling
  exit with the return value as the argument.  If  control  reaches  the
  end  of  main  without  encountering a return statement, the effect is
  that of executing
          return 0;

Regards,
Bruce Wheeler
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7pu4es$1mv3$1@news.hal-pc.org>,
  "Greg Brewer" <nospam.gregb@hal-pc.org> wrote:
> <whbloodworth@my-deja.com> wrote in message

> > Also, M$ will warn the developer if he/she does not return a value
> > from main...which I can live with despite the fact that the C++
> > standard also states that main implicitly returns 0 if not
> > specified.  The problem is with their warning.  Given the following:

> > int main (void) { }
> > VC++ produces the following warning:
> > warning C4508: 'main' : function should return a value; 'void'
return
> > type assumed

> > "void return type assumed" ???? What ? void assumed?

> This warning is no different than any other function without a
> return. I think you will find that if you change it to
>    void main(void) {}
> it will compile without any complaints.

Which it shouldn't, supposing conforming C++, since void main is
illegal:-).

Seriously, I wouldn't change it to void main unless my code was so
riddled with Microsoft'isms that there was no chance of it ever running
elsewhere anyway.  It's a warning, not an error ; if suppressing it is
an issue (and I agree it should be), then IMHO piping the output of the
compiler through sed is the easiest and the best way.  It is, at any
case, the solution I've always used.  (Yes, including with VC++.)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd <scott@coyotegulch.com> wrote in message
news:7q13ut$q6v$1@hardcore.ivn.net...
>
> Greg Brewer <nospam.gregb@hal-pc.org> wrote...
> > sorry, I don't use exceptions.
>
> Why?
>
> Performance overhead? Philosophy?

Some of that.  Mainly, its because they weren't supported in Borland 3.1
which is what I wrote my main application with.  When I rewrote the
application to port to Win32, exceptions were discouraged by the vendor of
my GUI libraries as causing exe size to increase in size dramatically.  My
new design made much greater use of templates and multiple inheritance than
the old and I expected that adding exception handling was one area that I
could skip.  Besides, I don't see that I have anything I need exceptions to
handle in my main app.

My application uses .dll drivers extensively and that is one area where
exceptions might be useful but I haven't had time to look into very hard.
One area that I've constantly had problems with is in my routines that do
some pretty heavy duty math.  I'm constantly having trouble with domain
errors; usually in areas where the ratio of two numbers is so close to zero
that it becomes zero.  We bought the libraries.  You can tell they were
originally written in FORTRAN and a translator program converted it to C.
Anyway, I thought about changing all the math programs to try and catch
problems.  Something like changing all calls to sqrt to Sqrt and coding a
Sqrt function as
   double Sqrt(double v) {
        double answer;
        try answer = sqrt(v);
        catch domain_error:
            answer = ???;
        return answer;
    }
I never did it.  Excuse any syntax error, I'm inexperience with the syntax,
don't care to take the time to go look it up, and I think you get the jest
of what I thought of doing.  First, I wasn't sure what to return.  In most
cases, there should be a fair approximation of the answer.  For those who
took calculus, it's just a limit problem.  Unfortunately, the fair
approximation depends on the equation and the values that the function call
is apart of and that information isn't available as written.  I can think of
ways around the problem but they take time I don't have.

Second, I'm not sure it would work.  I couldn't find any documentation that
suggests that sqrt would throw a domain_error.  domain_error is just
something I made up for the purposes of what I'm writting.  I couldn't find
any predefined exceptions for the math libraries.  A general catch might
work but I couldn't find anything to suggest that the math libraries throw
exceptions at all.

Greg Brewer





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard Browne <richb@pobox.com.au> wrote in message
news:935573895.543292@jaguarundi...
> > <whbloodworth@my-deja.com> wrote in message
> > news:7ps1sg$dev$1@nnrp1.deja.com...
> > sorry, I don't use exceptions.
>
> So does that mean you don't use the standard C++ library? Just curious..

That's pretty much correct.  I don't trust the standard C++ libraries.
Anything that new and complicated is bound to have bugs.  The C libraries
have bugs but I am familiar enough with them that I can work around them
easily.  "Better the devil you know ..." as the saying goes.

Greg Brewer





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7q1r13$1a8b$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>
>Richard Browne <richb@pobox.com.au> wrote in message
>news:935573895.543292@jaguarundi...
>> > <whbloodworth@my-deja.com> wrote in message
>> > news:7ps1sg$dev$1@nnrp1.deja.com...
>> > sorry, I don't use exceptions.
>>
>> So does that mean you don't use the standard C++ library? Just curious..
>
>That's pretty much correct.  I don't trust the standard C++ libraries.
>Anything that new and complicated is bound to have bugs.  The C libraries
>have bugs but I am familiar enough with them that I can work around them
>easily.  "Better the devil you know ..." as the saying goes.

My apologies, I had got the distinct impression that you were using VC++
and MFC :(  Obviously not if bugs in libraries concern you.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7q1r13$1a8b$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> wrote:

> Richard Browne <richb@pobox.com.au> wrote in message
> news:935573895.543292@jaguarundi...
> > > <whbloodworth@my-deja.com> wrote in message
> > > news:7ps1sg$dev$1@nnrp1.deja.com...
> > > sorry, I don't use exceptions.
> >
> > So does that mean you don't use the standard C++ library? Just curious..
>
> That's pretty much correct.  I don't trust the standard C++ libraries.
> Anything that new and complicated is bound to have bugs.  The C libraries
> have bugs but I am familiar enough with them that I can work around them
> easily.  "Better the devil you know ..." as the saying goes.

Do you use C++ features? Those could be buggy in your compiler too.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7q1qoa$1a68$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>Some of that.  Mainly, its because they weren't supported in Borland 3.1
>which is what I wrote my main application with.  When I rewrote the
>application to port to Win32, exceptions were discouraged by the vendor of
>my GUI libraries as causing exe size to increase in size dramatically.  My
>new design made much greater use of templates and multiple inheritance than
>the old and I expected that adding exception handling was one area that I
>could skip.  Besides, I don't see that I have anything I need exceptions to
>handle in my main app.

I guess your compiler vendor agrees with you which maybe why their main
applications periodically fall over destroying my work, as well as doing
other bizarre things at the most inconvenient times.

There must be something wrong when the only sensible thing I can do to
prevent loss of work is to turn a machine off (risking other types of
loss and damage) so that it will not have a chance to delete temporary
backup files.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7ps1sg$dev$1@nnrp1.deja.com>, whbloodworth@my-deja.com
says...

> The standard states that 'unexpected' will be called if a function
> throws something other than what is specified in the throw
> specification.  For example,
>
> class E : public logic_error { };
> class F : public logic_error { };
>
> void Foo (void) throw (E)
> {
>    throw F(); // should call unexpected()
> }
>
> Using M$ VC++, the above function Foo will successfully (depending on
> how you look at it) throw F() and the caller can catch it.

True.  And if you compile with /W4, it will give you a warning:

C4290: C++ Exception Specification ignored

IOW, they're pretty explicit about this.  Though this is clearly a
violation of the standard, it should also be pointed out that quite a
few people have _serious_ reservations about this area of the
standard; in the opinion of many (including myself) any compiler that
DOES follow C++ exception specifications should certainly provide a
mode in which they can be ignored and should also make that mode the
default.  Exception specifications are a good and wonderful thing if
and only if they are enforced statically not dynamically.  I.e. if the
compiler can detect a problem and refuse to compile code that violates
an exception specification, great.  For many purposes, calling
unexpected() at runtime is a TERRIBLE thing.

> Also, M$ will warn the developer if he/she does not return a value from
> main...which I can live with despite the fact that the C++ standard also
> states that main implicitly returns 0 if not specified.

The standard doesn't define the term warning; it just uses
"diagnostic".  Despite this, the usual nature of things in a compiler
is that what it calls an error is telling you that you've done
something that's clearly wrong -- e.g. violated part of the standard.
A warning, at least as the term is usually used, is telling you that
the it's telling you about something that's legal, but is probably a
questionable practice.  IMO, despite the fact that the standard says
that running off the end of main() is the same as returning 0, many
people (myself included) consider this a questionable practice, so the
warning is a reasonable one.  Also note that this warning is in the
four-thousands.  In case you're not aware of how MS numbers things,
that means this is a level-4 warning, which is the maximum level of
which the compiler is capable.  IOW, they're making it fairly clear
that they consider this fairly unlikely to cause any real problem, but
it's something you MIGHT want to know about anyway.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7ps1sg$dev$1@nnrp1.deja.com>, whbloodworth@my-deja.com wrote:

> The standard states that 'unexpected' will be called if a function
> throws something other than what is specified in the throw
> specification.  For example,
>
> class E : public logic_error { };
> class F : public logic_error { };
>
> void Foo (void) throw (E)
> {
>    throw F(); // should call unexpected()
> }
>
> Using M$ VC++, the above function Foo will successfully (depending on
> how you look at it) throw F() and the caller can catch it.

Well, at least this problem just exists for one of the rare debugging
support features (non-empty exception specifications) that found its way
into the language standard <snicker>.

> Also, M$ will warn the developer if he/she does not return a value from
> main...which I can live with despite the fact that the C++ standard also
> states that main implicitly returns 0 if not specified.

Oh, come on. This is such a minor feature.

> The problem is
> with their warning.  Given the following:
>
> int main (void) { }
>
> VC++ produces the following warning:
>
> warning C4508: 'main' : function should return a value; 'void' return
> type assumed
>
> "void return type assumed" ???? What ? void assumed?

Sure.

    void f();

    void g() { return f(); }

> You would think they could at least change the warning without "having
> to be backward compatible"...which is the standard M$ excuse for not
> conforming.

If they're going to change the warning, why not just fix it then? They
would have to add a special case for the warning in main(), which is at
least half way to fixing the compiler.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<whbloodworth@my-deja.com> wrote in message
news:7ps1sg$dev$1@nnrp1.deja.com...
>
> The standard states that 'unexpected' will be called if a function
> throws something other than what is specified in the throw
> specification.  For example,
> class E : public logic_error { };
> class F : public logic_error { };
> void Foo (void) throw (E)
> {
>    throw F(); // should call unexpected()
> }
> Using M$ VC++, the above function Foo will successfully (depending on
> how you look at it) throw F() and the caller can catch it.

sorry, I don't use exceptions.

> Also, M$ will warn the developer if he/she does not return a value from
> main...which I can live with despite the fact that the C++ standard also
> states that main implicitly returns 0 if not specified.  The problem is
> with their warning.  Given the following:
>
> int main (void) { }
> VC++ produces the following warning:
> warning C4508: 'main' : function should return a value; 'void' return
> type assumed
>
> "void return type assumed" ???? What ? void assumed?

This warning is no different than any other function without a return.  I
think you will find that if you change it to
   void main(void) {}
it will compile without any complaints.

Greg Brewer
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

whbloodworth@my-deja.com writes:

> The standard states that 'unexpected' will be called if a function
> throws something other than what is specified in the throw
> specification.  For example,
...
> Using M$ VC++, the above function Foo will successfully (depending on
> how you look at it) throw F() and the caller can catch it.
...

the latest version of VC++ does not handle exception specifications.
If you have MSDN for October 1998, the MSDN page:

mk:@MSITStore:C:\Program%20Files\Microsoft%20Visual%20Studio\MSDN98\98OCT\1033\vccore.chm::/html/_core_exception_handling_syntax.htm

says:

<quote>
Microsoft Specific ->

Microsoft C++ does not support the function exception specification
mechanism, as described in section 15.4 of the ANSI C++ draft.

END Microsoft Specific
</quote>

--
kevin kostrzewa
work: kkostrzewa@csisolutions.com
home: tkkost@newsguy.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The standard states that 'unexpected' will be called if a function
throws something other than what is specified in the throw
specification.  For example,

class E : public logic_error { };
class F : public logic_error { };

void Foo (void) throw (E)
{
   throw F(); // should call unexpected()
}

Using M$ VC++, the above function Foo will successfully (depending on
how you look at it) throw F() and the caller can catch it.

Also, M$ will warn the developer if he/she does not return a value from
main...which I can live with despite the fact that the C++ standard also
states that main implicitly returns 0 if not specified.  The problem is
with their warning.  Given the following:

int main (void) { }

VC++ produces the following warning:

warning C4508: 'main' : function should return a value; 'void' return
type assumed

"void return type assumed" ???? What ? void assumed?

You would think they could at least change the warning without "having
to be backward compatible"...which is the standard M$ excuse for not
conforming.

W. Bloodworth


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]