Is this good style of C++?

[Cheng Mo]

Recently I happens to read some sourcecode which has different style
from my previous experience.

In this style, all functions return a RETURN_TYPE_T which is defined as
typedef unsigned int RETURN_TYPE_T;
and the return value can only be enum value
enum
{
SUCCESS = 0,
FAILURE = 1,
ABORT = 2
};
If a function should return a object, the API is not like
Foo getFoo();
or
Foo* getFoo();
Instead, it is declared as
RETURN_TYPE_T getFoo(Foo* foo);
The caller has to new a Foo or get pointer to Foo object through other
way first, and then call this method with the pointer as parameter.

The function fill valuable info into the Foo object pointed by the
paramter. The result of invocation is judged by inspecting the returned
RETURN_TYPE_T value.

This style of coding seems strange to me, but I am told that it is a
good style, because it applys the rule "Who creates it, who releases
it". As a result, this style are supposed to reduce risk of memory leak.

I am still not quite convinced. Anybody with long time C++ exprirence
can give some comments?
Thanks & Regards

[Ioannis Vranos]

Cheng Mo wrote:

Recently I happens to read some sourcecode which has different style
from my previous experience.

In this style, all functions return a RETURN_TYPE_T which is defined as
typedef unsigned int RETURN_TYPE_T;
and the return value can only be enum value
enum
{
SUCCESS = 0,
FAILURE = 1,
ABORT = 2
};
If a function should return a object, the API is not like
Foo getFoo();
or
Foo* getFoo();
Instead, it is declared as
RETURN_TYPE_T getFoo(Foo* foo);
The caller has to new a Foo or get pointer to Foo object through other
way first, and then call this method with the pointer as parameter.

The function fill valuable info into the Foo object pointed by the
paramter. The result of invocation is judged by inspecting the returned
RETURN_TYPE_T value.

This style of coding seems strange to me, but I am told that it is a
good style, because it applys the rule "Who creates it, who releases
it". As a result, this style are supposed to reduce risk of memory leak.

I am still not quite convinced. Anybody with long time C++ exprirence
can give some comments?

If such a style is used in an application for a particular reason (that
is, it is not a style), then it is OK.
Otherwise as a *general style* of programming for C++ it looks primitive
and ancient.
If you want to handle errors you had better use exceptions, and not
return error code checks that this style implies.
If you want to create bullet proof code without memory leaks or *any
other resource* leaks, use "Resource Acquisition is Initialisation" (RAII):
http://groups.google.com/groups?q=%2...ntua.gr&rnum=1


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Peter Koch Larsen]

All in all its horrible.

"Cheng Mo" <mo******@nospa m.nospam> skrev i en meddelelse
news:co******** **@avnika.corp. mot.com...

Recently I happens to read some sourcecode which has different style from
my previous experience.

In this style, all functions return a RETURN_TYPE_T which is defined as
typedef unsigned int RETURN_TYPE_T;
and the return value can only be enum value
enum
{
SUCCESS = 0,
FAILURE = 1,
ABORT = 2
}; Do not use UPPERCASE_ONLY for values. These names should be reserved for
macroes only. If a function should return a object, the API is not like
Foo getFoo();
or
Foo* getFoo();
Instead, it is declared as
RETURN_TYPE_T getFoo(Foo* foo);
The caller has to new a Foo or get pointer to Foo object through other way
first, and then call this method with the pointer as parameter. Also horrible. The first signature should be preferred unless the call could
fail in a normal case in which case a smart pointer (see boost) would be
appropriate.
The function fill valuable info into the Foo object pointed by the
paramter. The result of invocation is judged by inspecting the returned
RETURN_TYPE_T value. In general, using exceptions is far more reliable. There's no forgetting of
checking the return-type, and you would not have to obfuscate your code with
all that checking.
This style of coding seems strange to me, but I am told that it is a good
style, because it applys the rule "Who creates it, who releases it". As a
result, this style are supposed to reduce risk of memory leak. This is good advice, but not so relevant for C++. Use RAII instead.
I am still not quite convinced. Anybody with long time C++ exprirence can
give some comments?
Thanks & Regards

Kind regards
Peter

[Ioannis Vranos]

Peter Koch Larsen wrote:

Do not use UPPERCASE_ONLY for values. These names should be reserved for
macroes only.

Actually one convention is to name all constants with uppercase, be them
macros, const objects, or members of an enumeration.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Kuba Ober]

>> If a function should return a object, the API is not like

Foo getFoo();
or
Foo* getFoo();
Instead, it is declared as
RETURN_TYPE_T getFoo(Foo* foo);
The caller has to new a Foo or get pointer to Foo object through other
way first, and then call this method with the pointer as parameter.

The function fill valuable info into the Foo object pointed by the
paramter. The result of invocation is judged by inspecting the returned
RETURN_TYPE_T value.

This style of coding seems strange to me, but I am told that it is a
good style, because it applys the rule "Who creates it, who releases
it". As a result, this style are supposed to reduce risk of memory leak.

If you want to handle errors you had better use exceptions, and not
return error code checks that this style implies.

Unless errors are frequent and expected, in which case exceptions are not
such a good choice. Throwing an exception typically has big overheads, so
unless given error is *exceptional*, it should be handled w/o throwing an
exception. Network code comes to mind, if transmission errors, timeouts
etc. are frequent.

Cheers, Kuba Ober

[Ioannis Vranos]

Kuba Ober wrote:

Unless errors are frequent and expected, in which case exceptions are not
such a good choice. Throwing an exception typically has big overheads, so
unless given error is *exceptional*, it should be handled w/o throwing an
exception. Network code comes to mind, if transmission errors, timeouts
etc. are frequent.

Well, my experience is in .NET, where every error is signified as an
exception and not as a return value, and so far I had no problems with
it. Also all the C++ standard library with the exception of the C
subset, uses exceptions to signify run-time errors.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[jeffc]

"Kuba Ober" <ku**@mareimbri um.org> wrote in message
news:co******** **@charm.magnus .acs.ohio-state.edu...

If you want to handle errors you had better use exceptions, and not
return error code checks that this style implies.

Unless errors are frequent and expected, in which case exceptions are not
such a good choice.

Unexpected behavior is pretty much the definition of an exception.

[Andre Kostur]

Ioannis Vranos <iv*@remove.thi s.grad.com> wrote in
news:1102010767 .803954@athnrd0 2:

Kuba Ober wrote:

Unless errors are frequent and expected, in which case exceptions are
not such a good choice. Throwing an exception typically has big
overheads, so unless given error is *exceptional*, it should be
handled w/o throwing an exception. Network code comes to mind, if
transmission errors, timeouts etc. are frequent.

Well, my experience is in .NET, where every error is signified as an
exception and not as a return value, and so far I had no problems with
it. Also all the C++ standard library with the exception of the C
subset, uses exceptions to signify run-time errors.

I don't agree with that assessment. End-of-file on a stream, for example,
is _not_ an exception, neither is dynamic_casting a pointer to an unrelated
type. Offhand I can only think of a couple of places where an exception is
thrown from the Standard library, and that's because either it really is an
exceptional case (like running out of memory), or there is no other way to
indicate an error (like dynamic_casting a reference to an unrelated type,
or using .at() on a vector past the end of the vector).

[Ioannis Vranos]

Andre Kostur wrote:

I don't agree with that assessment. End-of-file on a stream, for example,
is _not_ an exception, neither is dynamic_casting a pointer to an unrelated
type.

These are not errors. End-of-file is just the end of a file and
dynamic_cast is actually a run-time test.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Andre Kostur]

Ioannis Vranos <iv*@remove.thi s.grad.com> wrote in
news:1102022154 .76165@athnrd02 :

Andre Kostur wrote:

I don't agree with that assessment. End-of-file on a stream, for
example, is _not_ an exception, neither is dynamic_casting a pointer
to an unrelated type.

These are not errors. End-of-file is just the end of a file and
dynamic_cast is actually a run-time test.

Then I don't understand exactly what you would call an "error" then. IMHO:
If I try to read some data from a stream, and I don't get the data I was
expecting, then I'd call that an error. If I try to dynamic_cast a pointer
to an unrelated type, the runtime will return me a NULL to signify that
error. If I try to dynamic_cast a reference to an unrelated type, the
runtime will throw an exception to signify that error.