By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,897 Members | 1,969 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,897 IT Pros & Developers. It's quick & easy.

Is it good practice for a function to return data?

P: n/a
Is it good practice in C++ for a member function to return data or is
it better that data is stored in private member variable and printed
in the member function?

should i be using

int function1()
{
....
return i
}

and then call it from main()

main()
{
int i = function1();
printf("Value of i is %d", i);
}
or

function()
{
....
printf("Value of i is %d", i);
}
Jul 22 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
zalzon wrote:
Is it good practice in C++ for a member function to return data
or is it better that data is stored in private member variable
and printed in the member function?

Should I be using

int function1(void) {
....
return i;
}

and then call it from main()

int main(int argc, char* argv[]) {
int i = function1();
printf("Value of i is %d", i); return 0; }

or

void function(void) {
....
printf("Value of i is %d", i);
}


You should try to avoid "side effects" --
input and output are side effects.
They change the state of the program.
In C++ you should write:

std::cout << "Value of i is " << i;
Jul 22 '05 #2

P: n/a
zalzon <za***********@zalll.com> wrote:
Is it good practice in C++ for a member function to return data or is
it better that data is stored in private member variable and printed
in the member function?

should i be using

int function1()
{
....
return i
}

and then call it from main()

main()
{
int i = function1();
printf("Value of i is %d", i);
}
or

function()
{
....
printf("Value of i is %d", i);
}


In this spicific example, I would say that the first (function1) would
be the better choice. It can be used to output the value of 'i' (as
shown) and it can be used in contexts where the value isn't usposed to
be output.
Jul 22 '05 #3

P: n/a

"zalzon" <za***********@zalll.com> wrote in message
news:uh********************************@4ax.com...
Is it good practice in C++ for a member function to return data or is
it better that data is stored in private member variable and printed
in the member function?

should i be using

int function1()
{
....
return i
}

and then call it from main()

main()
{
int i = function1();
printf("Value of i is %d", i);
}
or

function()
{
....
printf("Value of i is %d", i);
}


Its almost always bad practice to print data from member functions,
generally
clients of the class want just to get the value, not print it out - which in
a realworld
program would be unwanted both because of the volume and the lack of
context.
What's more the data might not might not even be seen on STDOUT.
If your data is just simple types like int, char, etc,
the client can easily generate his own output functions, if the data is a
more complex
type is usually a good idea to provide (friend) formating function which
works with the
base output stream class - in this way the client can format output in many
differnet forms,
on the output or in a memory stream to produce his own output.

dave
Jul 22 '05 #4

P: n/a
zalzon <za***********@zalll.com> wrote in message news:<uh********************************@4ax.com>. ..
Is it good practice in C++ for a member function to return data or is
it better that data is stored in private member variable and printed
in the member function?
That depends.
should i be using

int function1()
{
....
return i
}

and then call it from main()

main()
{
int i = function1();
printf("Value of i is %d", i);
}
First of all, using printf in C++ is rarely a good idea.
or

function()
{
....
printf("Value of i is %d", i);
}


IMO, it's perfectly reasonable for a class to overload the insertion
and/or extraction operators to do I/O on complete objects. One common
(and useful) idiom for that is to have a virtual member function to do
the I/O, and have it invoked from a global overload of operator<< or
operator>>, as applicable. In that case, a member function doing I/O
makes perfect sense.

OTOH, if your member function's basic idea is to produce a value
(which you happen to be printing out at the moment) then having it do
the I/O as well probably isn't such a great idea.

There are a couple more possibilities. One is to put the computation
(or whatever) into a base class that also has a (possibly pure)
virtual function that handles processing the output. Then a derived
class can specify how the output will be processed by overloading that
virtual function.

A similar possibility is to pass a parameter that specifies how to
process the output -- one way is to pass a pointer to a function to be
invoked on the output (this more or less matches the version above
with virtual functions). Another is to use an iterator, and write the
output to the iterator. In this case, you can easily put the output
into something like a collection, or you can pass a
std::ostream_iterator, which will write the data to a stream.

Choosing between these isn't necessarily easy. One of the basic
precepts, however, is that a function should generally do one thing,
so you should usually think about what the function does and act
accordingly. If the function's intent is "print out X" then doing the
I/O probably makes sense. If its intent is "compute X" then it almost
certainly should NOT print it out. If its intent is to produce a
(perhaps large) number of X, then one of the final versions (e.g.
virtual function or iterator) may make the most sense.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #5

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cg**********@nntp1.jpl.nasa.gov>...

[ ... ]
You should try to avoid "side effects" --
input and output are side effects.


So you think programs should avoid doing input and output? Assignment
is also a side-effect, so you apparently think that should be avoided
as well.

That's certainly possible -- in fact, people have been doing it in
Lisp, ML, and a number of other functional languages for years. I
don't see C++ as being particularly well-suited to this style of
programming though...

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #6

P: n/a
Jerry Coffin wrote:
E. Robert Tisdale wrote:

[ ... ]
You should try to avoid "side effects" --
input and output are side effects.
So you think programs should avoid doing input and output?
Assignment is also a side-effect,
so you apparently think that should be avoided as well.


Yes!
That's certainly possible --
in fact, people have been doing it
in Lisp, ML, and a number of other functional languages for years.
I don't see C++ as being particularly well-suited
to this style of programming though...


C++ *is* well-suited to this programming style --
it just isn't anal about it.
Jul 22 '05 #7

P: n/a
jc*****@taeus.com (Jerry Coffin) wrote in message

[...]
IMO, it's perfectly reasonable for a class to overload the insertion
and/or extraction operators to do I/O on complete objects. One common
(and useful) idiom for that is to have a virtual member function to do
the I/O, and have it invoked from a global overload of operator<< or
operator>>, as applicable. In that case, a member function doing I/O
makes perfect sense.
I believe I'm following you here so if I were to re-write the above
statement in terms of source code:

class X
{
int Jdx;
friend std::ostream& operator << (std::ostream& os, X const& x);
public:
virtual void std::ostream& Print ( ostream& os ) { os << Jdx; }
}

friend std::ostream& operator << (std::ostream& os, X const& x)
{
return x.Print(os);
}

So far so good?

Now heres where this approach gets interesting from the perspective of
an apprentice. For the purposes of discussion, assume class X has 10
member data, three of which is - say - line of sight positions with
units direction cosines.
Occassionally I'm interested in outputting all 10 member data.
Similarily, there are times when I'm interested in outputting only the
line of sight positions.

Perhaps irrelevant, but lets also assume the environment allows one
the opportunity to type in the name of a function and pass parameters
to function calls. Upon doing that the function executes. In any
event, how do you approach the print function?

OTOH, if your member function's basic idea is to produce a value
(which you happen to be printing out at the moment) then having it do
the I/O as well probably isn't such a great idea.

There are a couple more possibilities. One is to put the computation
(or whatever) into a base class that also has a (possibly pure)
virtual function that handles processing the output. Then a derived
class can specify how the output will be processed by overloading that
virtual function. For instance?
A similar possibility is to pass a parameter that specifies how to
process the output -- one way is to pass a pointer to a function to be
invoked on the output (this more or less matches the version above
with virtual functions). Another is to use an iterator, and write the
output to the iterator. In this case, you can easily put the output
into something like a collection, or you can pass a
std::ostream_iterator, which will write the data to a stream.
This sounds like
vector<int> Vec(5);
copy (Vec.begin(), Vec.end(), ostream_iterator<int>(cout, ' '));

Yes/No?

Now how would you map said approach to a class X?
Choosing between these isn't necessarily easy.


Agreed. There are times when one's faced with multiple classes and a
need to instrument data. Your first option is straightforward in the
sense that each class could maintain their own print function. A
while back I overheard a professor discussing the creation of an
'instrumentation' class which supports the concept of plug-in. In
essence, you'd plug-in (assuming I understand the prof) the
instrumentation class into class X and sure enough/somehow your data
will be extracted for you. That's a novel idea and sounds suprisingly
efficient. Truth is, the idea is incomprehensible/makes no sense to
me.
Jul 22 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.