What is the counterpart of Java API Specification in C++

[xz]

Hi, I am currently switching from Java to C++.
When I code in Java, I use the following website to find the
specifications of classes and methods:

http://java.sun.com/j2se/1.5.0/docs/api/

I think there must be several websites providing similar information
for C++.
I did find some but they were not as good as I expected.
Could you guys recommend some good ones?

Thanks!

 

[Alf P. Steinbach]

* xz:

Hi, I am currently switching from Java to C++.
When I code in Java, I use the following website to find the
specifications of classes and methods:

http://java.sun.com/j2se/1.5.0/docs/api/

I think there must be several websites providing similar information
for C++.
I did find some but they were not as good as I expected.
Could you guys recommend some good ones?

Dinkumware: <url: http://www.dinkumware.com/manuals/default.aspx>.

SGI: <url: http://www.sgi.com/tech/stl/>

Microsoft: <url:
http://msdn2.microsoft.com/en-us/library/cscc687y(VS.80).aspx>.

 

[bhadorn]

Hi, I am currently switching from Java to C++.
When I code in Java, I use the following website to find the
specifications of classes and methods:

http://java.sun.com/j2se/1.5.0/docs/api/

I think there must be several websites providing similar information
for C++.
I did find some but they were not as good as I expected.
Could you guys recommend some good ones?

Thanks!

In C++ there is no API reference like Java has. Each library has its
own reference. There fore it depends what kind of library you are
using (STL, ZeusFramework, MFC etc.)

The ZeusFramework has lots of classes similar to Java (Lists, Maps,
String, Calendar and much more).
It also includes RMI for C++, Serializing and networking
See http://www.xatlantis.ch/api/zeusbase/index.html

 

[Roland Pibinger]

The ZeusFramework has lots of classes similar to Java (Lists, Maps,
String, Calendar and much more).
It also includes RMI for C++, Serializing and networking
See http://www.xatlantis.ch/api/zeusbase/index.html

<offtopic>
Unfortunatey, Zeus seems to be unaware of RAII, the central C++ idiom,
e.g.
http://www.xatlantis.ch/examples/zeus_example.html#Step1
http://www.xatlantis.ch/examples/rmi_example.html#Step4

Tranferring the usability and convenience of Java libraries to C++ is
certainly a good idea (usable C++ libraries are sorely needed). But
these libraries should use C++ styles and idioms where they provide
much better solutions (e.g. for resource handling).
</offtopic>

 

[bhadorn]

I'm aware that throwing exceptions is not supported by Zeus-Framework,
if you mean that. There are very good reasons not using exceptions
with C++. Since C++ has no GC, it might cause resource leaks and
unexpected program states witch is really ugly.

Zeus supports interfaces, software modules written in different
program languages (so, dll). Exceptions are a problem here. For
complex application, I prefer using return values.

PS: By the way, I think those problems were known to other development
teams as well. Thats why COM uses return values and not exceptions.

 

[Roland Pibinger]

I'm aware that throwing exceptions is not supported by Zeus-Framework,
if you mean that.

I mean this: http://en.wikipedia.org/wiki/RAII
Admittedly, I've only looked at the examples at your web-site and the
style in which they are written.

There are very good reasons not using exceptions
with C++.

In some cases yes, certainly not in general. More often than not
exceptions make programs safer and considerably clean up code.

Since C++ has no GC, it might cause resource leaks and
unexpected program states witch is really ugly.

Quite the contrary!

 

[Michael DOUBEZ]

bhadorn a écrit :

I'm aware that throwing exceptions is not supported by Zeus-Framework,
if you mean that.

Do you mean you are exception neutral or that you simply ignore the
exceptions part ?

There are very good reasons not using exceptions
with C++.

I known of some reasons but I am curious about what you call VERY GOOD
reasons.

Since C++ has no GC, it might cause resource leaks and
unexpected program states witch is really ugly.

It has no relation with GC, it is about exception awareness. But it is
true that it is easier in Java to code without exception awareness and
have no memory leak. Which doesn't mean the program has a correct behavior.

Zeus supports interfaces, software modules written in different
program languages (so, dll). Exceptions are a problem here. For
complex application, I prefer using return values.

There are good practice about exception just as with return value. It is
far easier to ignore them with return value though.

Using return values also means you have to increase the complexity of
the code in order to verify every return value which often obfuscate the
execution path.
To the contrary, I would expect return value to be more suitable for
simple parts while exception should be used as the complexity increases.

PS: By the way, I think those problems were known to other development
teams as well. Thats why COM uses return values and not exceptions.

I don't know COM development well but AFAIK COM doesn't let exception
escape and use them internally which is a good practice from my point of
view and not an inherently flaw of exception.
Narrowing the range of exception that cross boundaries means the user as
less to catch.

Michael

 

[Nemanja Trifunovic]

There are very good reasons not using exceptions
with C++. Since C++ has no GC, it might cause resource leaks and
unexpected program states witch is really ugly.

That's one of the reasons you were suggested to use RAII. Unlike GC,
it will help you manage all resources, not just memory, and not just
for exceptions.

To learn how to write exception-safe code with C++ I highly recommend
the book "Exceptional C++", by Herb Sutter:
http://www.amazon.com/exec/obidos/ASIN/0201615622/peerdirinc

 

[JohnQ]

I mean this: http://en.wikipedia.org/wiki/RAII
Admittedly, I've only looked at the examples at your web-site and the
style in which they are written.


In some cases yes, certainly not in general. More often than not
exceptions make programs safer and considerably clean up code.

I thought the accepted rule of thumb was: "use a return code when you can,
use exceptions when you have to". ???

John

Quite the contrary!

Uh oh: exception AND GC talk in one post... could very well be a TROLL!

John

 

[Ian Collins]

I thought the accepted rule of thumb was: "use a return code when you
can, use exceptions when you have to". ???

Accepted by whom?

 

[JohnQ]

Accepted by whom?

Smart software developers?

John

 

[Roland Pibinger]

I thought the accepted rule of thumb was: "use a return code when you can,
use exceptions when you have to". ???

I wouldn't support that rule.
Instead of:

int foo1() {
if (doSomething() == XYZ_OK) {
// ...
if (doSomethingElse() == ABC_OK) {
// ...
} else {
// error handling
}
} else {
// error handling
}
// ...
return errVal;
}

I want to write:

void foo2() {
doSomething();
doSomethingElse()
}

 

[James Kanze]

I thought the accepted rule of thumb was: "use a return code when you can,
use exceptions when you have to". ???

The generally accepted rule of thumb is to select the most
appropriate form of error reporting, depending on the type of
error and the context in which it appears. There are definitly
cases where exceptions are the most appropriate form, even
sometimes when return codes would be possible. (And of course,
return codes and exceptions are far from the only
possibilities.)

 

[bhadorn]

bhadorn a écrit :


Do you mean you are exception neutral or that you simply ignore the
exceptions part ?


I known of some reasons but I am curious about what you call VERY GOOD
reasons.


It has no relation with GC, it is about exception awareness. But it is
true that it is easier in Java to code without exception awareness and
have no memory leak. Which doesn't mean the program has a correct behavior.


There are good practice about exception just as with return value. It is
far easier to ignore them with return value though.

Using return values also means you have to increase the complexity of
the code in order to verify every return value which often obfuscate the
execution path.
To the contrary, I would expect return value to be more suitable for
simple parts while exception should be used as the complexity increases.


I don't know COM development well but AFAIK COM doesn't let exception
escape and use them internally which is a good practice from my point of
view and not an inherently flaw of exception.
Narrowing the range of exception that cross boundaries means the user as
less to catch.

Michael

Hi Michael,

I just updated my website. There you find the very good reason, why
Zeus-Framework does not use exception externaly.
http://www.xatlantis.ch/education/interfaces.html

about the RAII: I updated my examples using auto pointer TAutoPtr<T>
now, witch I think is a step in the right direction

wbr

bhadorn

 

[Michael DOUBEZ]

bhadorn a écrit :

I just updated my website. There you find the very good reason, why
Zeus-Framework does not use exception externaly.
http://www.xatlantis.ch/education/interfaces.html

You are mixing Borland binaries with VC++ binaries. I can see where it
can be useful but I wouldn't wager on its reliability.

Concerning exception, IIRC windows has a specific system called
Structured Exception Handling (SEH for the intimates) which mess with
the stack and the way it unwinds; I don't know more about it, it's not
my application field. Perhaps it is the reason why you got those
problems. A MSVC group may tell you more about it.

Michael