Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Return a container from a class method

Reply
Thread Tools

Return a container from a class method

 
 
padulg@gmail.com
Guest
Posts: n/a
 
      07-27-2006
Hello at all,
I have a problem: I have a class named "ball" with a method named
"split".

This is the declaration in ball.h:

class ball : public procObject
{
public:
ball();
ball(GLfloat size, GLfloat x_pos, GLfloat y_pos, GLfloat z_pos);
~ball();

GLvoid draw(GLint mode); //implemented
ball* clone();

list<ball*> split(GLint ntimes);
};

This is th implementation in ball.cpp

list<ball*> ball::split(GLint ntimes)
{
list<ball*> new_balls;
.....
....

return new_balls;

}

Is it possible, and if it is how can I do that?

 
Reply With Quote
 
 
 
 
mlimber
Guest
Posts: n/a
 
      07-27-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hello at all,
> I have a problem: I have a class named "ball" with a method named
> "split".
>
> This is the declaration in ball.h:
>
> class ball : public procObject
> {
> public:
> ball();
> ball(GLfloat size, GLfloat x_pos, GLfloat y_pos, GLfloat z_pos);
> ~ball();
>
> GLvoid draw(GLint mode); //implemented
> ball* clone();
>
> list<ball*> split(GLint ntimes);
> };
>
> This is th implementation in ball.cpp
>
> list<ball*> ball::split(GLint ntimes)
> {
> list<ball*> new_balls;
> ....
> ...
>
> return new_balls;
>
> }
>
> Is it possible, and if it is how can I do that?


If you're lucky, the compiler might optimize the copy of the list away,
but generally speaking it can't do so. A better way would be to pass
the list in as a reference:

void ball::split( GLint ntimes, list<ball*>& new_balls )
{
list.clear();
// ... same stuff as before, except for the return
}

Cheers! --M

 
Reply With Quote
 
 
 
 
padul
Guest
Posts: n/a
 
      07-27-2006
The compiler return ,me these errors:

ball.h:23: error: 'list' has not been declared
ball.h:23: error: expected ',' or '...' before '<' to


is there anyway to resolve this problem, I would know how to pass as
parameter a container o return a container from a method of a class.
Thanks.


Padul

mlimber wrote:
> (E-Mail Removed) wrote:
> > Hello at all,
> > I have a problem: I have a class named "ball" with a method named
> > "split".
> >
> > This is the declaration in ball.h:
> >
> > class ball : public procObject
> > {
> > public:
> > ball();
> > ball(GLfloat size, GLfloat x_pos, GLfloat y_pos, GLfloat z_pos);
> > ~ball();
> >
> > GLvoid draw(GLint mode); //implemented
> > ball* clone();
> >
> > list<ball*> split(GLint ntimes);
> > };
> >
> > This is th implementation in ball.cpp
> >
> > list<ball*> ball::split(GLint ntimes)
> > {
> > list<ball*> new_balls;
> > ....
> > ...
> >
> > return new_balls;
> >
> > }
> >
> > Is it possible, and if it is how can I do that?

>
> If you're lucky, the compiler might optimize the copy of the list away,
> but generally speaking it can't do so. A better way would be to pass
> the list in as a reference:
>
> void ball::split( GLint ntimes, list<ball*>& new_balls )
> {
> list.clear();
> // ... same stuff as before, except for the return
> }
>
> Cheers! --M


 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      07-27-2006

mlimber skrev:

> (E-Mail Removed) wrote:

[snip]
> >
> > This is th implementation in ball.cpp
> >
> > list<ball*> ball::split(GLint ntimes)
> > {
> > list<ball*> new_balls;
> > ....
> > ...
> >
> > return new_balls;
> >
> > }
> >
> > Is it possible, and if it is how can I do that?

>
> If you're lucky, the compiler might optimize the copy of the list away,
> but generally speaking it can't do so. A better way would be to pass
> the list in as a reference:
>
> void ball::split( GLint ntimes, list<ball*>& new_balls )
> {
> list.clear();
> // ... same stuff as before, except for the return
> }
>


I have two questions: first why you choose to force a weird syntax
because some optimization not would take place. Is there any indication
that the procedure in question is on an expensive path?
My second question is why you believe the optimizer can't do the RVO.
The compilers I use all perform RVO without any problems provided
optimizations are turned on. In that case your code is not only more
verbose and less natural - it is also slower.

> Cheers! --M


Recheers
Peter

 
Reply With Quote
 
padul
Guest
Posts: n/a
 
      07-27-2006
I'm working under linux enviroment with kdevelop3 that use g++.
There is any solution at my question?
Thanks

peter koch wrote:
> mlimber skrev:
>
> > (E-Mail Removed) wrote:

> [snip]
> > >
> > > This is th implementation in ball.cpp
> > >
> > > list<ball*> ball::split(GLint ntimes)
> > > {
> > > list<ball*> new_balls;
> > > ....
> > > ...
> > >
> > > return new_balls;
> > >
> > > }
> > >
> > > Is it possible, and if it is how can I do that?

> >
> > If you're lucky, the compiler might optimize the copy of the list away,
> > but generally speaking it can't do so. A better way would be to pass
> > the list in as a reference:
> >
> > void ball::split( GLint ntimes, list<ball*>& new_balls )
> > {
> > list.clear();
> > // ... same stuff as before, except for the return
> > }
> >

>
> I have two questions: first why you choose to force a weird syntax
> because some optimization not would take place. Is there any indication
> that the procedure in question is on an expensive path?
> My second question is why you believe the optimizer can't do the RVO.
> The compilers I use all perform RVO without any problems provided
> optimizations are turned on. In that case your code is not only more
> verbose and less natural - it is also slower.
>
> > Cheers! --M

>
> Recheers
> Peter


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      07-27-2006
"padul" <(E-Mail Removed)> wrote...
> I'm working under linux enviroment with kdevelop3 that use g++.
> There is any solution at my question?
> Thanks
>
> peter koch wrote:
>> mlimber skrev:
>>
>> > (E-Mail Removed) wrote:

>> [snip]
>> > >
>> > > This is th implementation in ball.cpp
>> > >
>> > > list<ball*> ball::split(GLint ntimes)
>> > > {
>> > > list<ball*> new_balls;
>> > > ....
>> > > ...
>> > >
>> > > return new_balls;
>> > >
>> > > }
>> > >
>> > > Is it possible, and if it is how can I do that?


Why ask if it's possible? Why not just try it? The only negative
side I see is that you keep pointers. Make sure you don't try storing
pointers to local objects in your 'list'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      07-27-2006
padul wrote:
> mlimber wrote:
> > void ball::split( GLint ntimes, list<ball*>& new_balls )
> > {
> > list.clear();
> > // ... same stuff as before, except for the return
> > }

>
> The compiler return ,me these errors:
>
> ball.h:23: error: 'list' has not been declared
> ball.h:23: error: expected ',' or '...' before '<' to
>
>
> is there anyway to resolve this problem, I would know how to pass as
> parameter a container o return a container from a method of a class.


First, put your reply to other posts inline or below the post you are
responding to. I've fixed your reply above.

Second, change list.clear() to new_balls.clear(). Mea culpa.

Cheers! --M

 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      07-27-2006
peter koch wrote:
> mlimber skrev:
> > If you're lucky, the compiler might optimize the copy of the list away,
> > but generally speaking it can't do so. A better way would be to pass
> > the list in as a reference:
> >
> > void ball::split( GLint ntimes, list<ball*>& new_balls )
> > {
> > list.clear();
> > // ... same stuff as before, except for the return
> > }
> >

>
> I have two questions: first why you choose to force a weird syntax
> because some optimization not would take place. Is there any indication
> that the procedure in question is on an expensive path?


It could be premature optimization, sure. But let's also not
prematurely pessimize.

> My second question is why you believe the optimizer can't do the RVO.
> The compilers I use all perform RVO without any problems provided
> optimizations are turned on. In that case your code is not only more
> verbose and less natural - it is also slower.


First, the OP didn't specify the compiler in question. Some don't do
the RVO at all. Second, RVO can only be applied on initialization. For
instance...

vector<int> Foo()
{
vector<int> v;
v.push_back( 1 );
v.push_back( 2 );
return v;
}

void Bar()
{
vector<int> v = Foo(); // RVO applied!
// ... use v somehow ...
v = Foo(); // RVO not applied!
}

For more info, see this section from _Efficient C++ Programming_ by
Lippman:

http://www.awprofessional.com/articl...p?p=25033&rl=1

Cheers! --M

 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      07-27-2006

mlimber skrev:

> peter koch wrote:
> > mlimber skrev:
> > > If you're lucky, the compiler might optimize the copy of the list away,
> > > but generally speaking it can't do so. A better way would be to pass
> > > the list in as a reference:
> > >
> > > void ball::split( GLint ntimes, list<ball*>& new_balls )
> > > {
> > > list.clear();
> > > // ... same stuff as before, except for the return
> > > }
> > >

> >
> > I have two questions: first why you choose to force a weird syntax
> > because some optimization not would take place. Is there any indication
> > that the procedure in question is on an expensive path?

>
> It could be premature optimization, sure. But let's also not
> prematurely pessimize.


It is NEVER premature pessimization if the result requires you to write
obfuscated code such as
container <t> c;
cfunc(c);
instead of
container <t> c = cfunc();
>
> > My second question is why you believe the optimizer can't do the RVO.
> > The compilers I use all perform RVO without any problems provided
> > optimizations are turned on. In that case your code is not only more
> > verbose and less natural - it is also slower.

>
> First, the OP didn't specify the compiler in question. Some don't do
> the RVO at all. Second, RVO can only be applied on initialization. For
> instance...


Just out of curiosity. What compiler released in this millenium does
not do RVO or NRVO?
>
> vector<int> Foo()
> {
> vector<int> v;
> v.push_back( 1 );
> v.push_back( 2 );
> return v;
> }
>
> void Bar()
> {
> vector<int> v = Foo(); // RVO applied!
> // ... use v somehow ...
> v = Foo(); // RVO not applied!
> }


Right - but the first solution is still preferable. First, you keep the
natural look of the code (which is most important - code is written to
be read!). Second, you can more easily get the strong exception
guarantee here and lastly this code will be as efficient as your
"return value in a parameter" as soon as the new r-value extensions get
implemented

/Peter

>
> For more info, see this section from _Efficient C++ Programming_ by
> Lippman:
>
> http://www.awprofessional.com/articl...p?p=25033&rl=1
>


An excellent book no longer in my possession ;.-)
> Cheers! --M


/Peter

 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      07-28-2006
peter koch wrote:
> mlimber skrev:
> > peter koch wrote:
> > > mlimber skrev:
> > > > If you're lucky, the compiler might optimize the copy of the list away,
> > > > but generally speaking it can't do so. A better way would be to pass
> > > > the list in as a reference:
> > > >
> > > > void ball::split( GLint ntimes, list<ball*>& new_balls )
> > > > {
> > > > list.clear();
> > > > // ... same stuff as before, except for the return
> > > > }
> > > >
> > >
> > > I have two questions: first why you choose to force a weird syntax
> > > because some optimization not would take place. Is there any indication
> > > that the procedure in question is on an expensive path?

> >
> > It could be premature optimization, sure. But let's also not
> > prematurely pessimize.

>
> It is NEVER premature pessimization if the result requires you to write
> obfuscated code such as
> container <t> c;
> cfunc(c);
> instead of
> container <t> c = cfunc();
>
> > First, the OP didn't specify the compiler in question. Some don't do
> > the RVO at all. Second, RVO can only be applied on initialization. For
> > instance...

>
> Just out of curiosity. What compiler released in this millenium does
> not do RVO or NRVO?


Well, like I said, the OP didn't specify, and unfortunately, not
everyone has the option of use modern compilers. (Half of my current
project uses VC6, for instance, while the other half uses a quite
compliant EDG-based compiler, and some code has to work on both).

> >
> > vector<int> Foo()
> > {
> > vector<int> v;
> > v.push_back( 1 );
> > v.push_back( 2 );
> > return v;
> > }
> >
> > void Bar()
> > {
> > vector<int> v = Foo(); // RVO applied!
> > // ... use v somehow ...
> > v = Foo(); // RVO not applied!
> > }

>
> Right - but the first solution is still preferable. First, you keep the
> natural look of the code (which is most important - code is written to
> be read!). Second, you can more easily get the strong exception
> guarantee here and lastly this code will be as efficient as your
> "return value in a parameter" as soon as the new r-value extensions get
> implemented


Certainly this is the preferable syntax, but it, too, has a drawback
besides the question of compiler support: it requires the programmer to
remember to make use of RVO and not perform an implicit copy. I see it
as a trade-off, which can be decided one way or the other in specific
instances by the needs of the project, but if a conservative approach
should be taken, then the explicit parameter approach should be used.

Cheers! --M

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why a class can't access protected method from another class in thesame package,the method is interited from the ohtner class from differntpackage? junzhang1983@gmail.com Java 3 01-28-2008 02:09 AM
Carriage Return added during return of large string from class method Xeno Campanoli Ruby 0 02-13-2006 08:39 PM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM
STL: container's values setup by another container Maitre Bart C++ 2 02-11-2004 12:11 AM
std::container::iterator vs std::container::pointer Vivi Orunitia C++ 11 02-04-2004 08:09 AM



Advertisments