Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Assignment operator=/copy constructor/temporaries, BROKEN!

Reply
Thread Tools

Assignment operator=/copy constructor/temporaries, BROKEN!

 
 
Fabrizio J Bonsignore
Guest
Posts: n/a
 
      09-17-2010
What is the point of OOP and C++, anyway? I want to write ... AO
Function(); ... AO x = Function(); I want some NEW x object of type AO
in its relevant scope to CATCH the AO object returned from function
Function(); copy it and become IT. I do NOT want to have a previous AO
object initialized in default values, AO x; THEN an assignment
operator called on it with Function(); [like in x.this-
>operator=(Function())] because it is a double initialization! I want

a COPY CONSTRUCTOR to be invoked under MY control, to make the NEW AO
x become initialized with the returned old value from Function(). It
happens that AO is a very complex abstraction of the world and
Function() returns a lengthy user process construct with lots of
values obtained from different sources and under different conditions
with lots of very processed and prepared fields and I want to further
process them in another scope in the application, so going through TWO
initializations, default constructor and assignment operator is just
overkill! I cannot simply copy bitwise because AO has the objective of
managing memory, ascertain an object is unique, store memory, and has
side effects like filling in GUI lists and painting in memory stecils
and... I understand that the object returned by **value** from
Function() is a temporary and anonymous memory address that will go
away at any moment out of my control, so I cannot take addresses and
modifying the calling argument in another function makes no sense (in
the absence of side effects) so const is not really necessary nor an
issue, BUT, I need to hold on to the memory of THAT complex instance
and that is the meaning of x! The copy constructor knows what to do
with its own class of objects, it knows what fields are just copied,
which ones initialized from default, which ones need CLONING(), which
ones require new memory before copying them, what complex lot of
processes to place under the rug and take out of the way so that the
user code looks clean and readable and maintainable, etc. But the
compiler is complaining if the copy constructor is programmed
explicitly! It does not accept both assignment operator= and explicit
copy constructor (EXPLICIT means EXPLICITLY PROGRAMMED, not a
hypothetical redundant keyword when implicit means not even mentioned
because bitwise copy is done automatically). I already tried several
combinations: the g++ compiler gets confsed with an illegal AO::AO(AO)
constructor signature! It does not accept BOTH assignment and copy
methods. I can workaround with idiot, I mean, idiom, AO(AO *);
[pointer argument copy constructor] and AO x = &Function(); [address
of temporary!], but it is NOT the C++ I knew for a decade+! Should be
simple and obvious that the returned temporary value has to subsist
til at LEAST the end of this (next) statement! Or function return
values become impossible! Which IS the point of OOP anyway: to handle
data as bundles along its methods and forget about details so complex
data can be handled as easily as arithmetic numbers. But NO! The
compiler is broken, and worse, I cannot see when it happened nor am
really sure it is not some hidden flag, make idiosincracy, weird name
clash, memory corruption, unwanted update or what (at least NOT
without wasting a lot of time like writing this complaint). I ve been
reading other people s call for help on the same problem and the
replies miss the issue, or the case is not exactly the same. Neither
explicit nor const affect the issue: the issue is the compiler looking
for illegal AO::AO(AO) and complaining for legal AO::AO(AO&) methods.
Similar problem with operator=(AO... both as pass-by-reference and
pass-by-value. The best documentation of a system is ALWAYS the system
itself! And its own standard, so any other written standard is just
ideal reality in the future and a goal to achieve IF at all possible!
Version I used is g++ 3.4.2. It was working and got broken, but I want
it to work in THIS project as is. I need a solution or a technical
explanation of why the compiler parser is complaining about looking
for AO::AO(AO) when it also says it is illegal when TO ALL MEANS
AO::AO(AO &) is TOTALLY equivalent and even stronger (should have
preference), and why it complaints if BOTH assignment= and copy
constructor methods are EXPLICITLY DEFINED (programmed). Changing to a
new version is not the best solution... there may be other issues and
so far no known bug has had an impact in this code, so if it is not
broken, do not fix it! But fix this problem, please. (BTW, mofeel.net
means in SPANISH: ...mocked the web).

Danilo J Bonsignore
 
Reply With Quote
 
 
 
 
Fabrizio J Bonsignore
Guest
Posts: n/a
 
      09-17-2010
I can use as a workaround a very verbose AO &Function() {static AO
AO_Function_return_var; ... return AO_Function_return_var;} Then I can
write without any danger AO x = Function(); and BOTH signatures, the
called function AO &Function(); and the copy constructor AO::AO(AO &);
will have a LITERALLY MATCHING SIGNATURE! Like in AO::AO((AO &)(AO
&)Function()); so both (AO &) terms cancel each other out AS IF this
was a mathematical algebra... but it is a VERY verbose solution and
besides it calls now for TRIPLE initialization! One for an empty AO
object to operate on, an assignment operator= call to re-initialize
the AO_Function_return_var object and FINALLY the correctly called
copy constructor for final result AO object x. This would have SOME
sense in a multithreading environment where access to the static
variables is the synchronization point, but at the cost of triple
initialization. Of course, WITHIN a same object, I do not even need
return types in functions! All functions become void F(); and all
operations are called on member variabled, but that is going BACK to
functional languages only lumped together in a different way! Then
treating it all as memory addresses (pointers) is an error prone
technique IF all return values have to be pointers! The code becomes
dirty with calls to delete and new and the chance of mismatching them
and/or not freeing memory in a web of function calls returning memory
addresses only.

Danilo J Bonsignore
 
Reply With Quote
 
 
 
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      09-17-2010
* Fabrizio J Bonsignore, on 17.09.2010 03:53:
> What is the point of OOP and C++, anyway? I want to write ... AO

[snip very long rambling explanation of something]
>
> Danilo J Bonsignore


Hi, Danilo or Fabrizio.

Please check out

<url: http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8>


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      09-17-2010
On Sep 17, 3:53*am, Fabrizio J Bonsignore <(E-Mail Removed)> wrote:
> What is the point of OOP and C++, anyway? I want to write ... AO
> Function(); ... AO x = Function(); I want some NEW x object of type AO
> in its relevant scope to CATCH the AO object returned from function
> Function(); copy it and become IT. I do NOT want to have a previous AO
> object initialized in default values, AO x; THEN an assignment
> operator called on it with Function(); [like in x.this->operator=(Function())] because it is a double initialization! I want
>
> a COPY CONSTRUCTOR to be invoked under MY control, to make the NEW AO
> x become initialized with the returned old value from Function(). It
> happens that AO is a very complex abstraction of the world and
> Function() returns a lengthy user process construct with lots of
> values obtained from different sources and under different conditions
> with lots of very processed and prepared fields and I want to further
> process them in another scope in the application, so going through TWO
> initializations, default constructor and assignment operator is just
> overkill!


Come down... You seem to want this:

typedef std::auto_ptr<AO> PAO;

PAO Function(irrelevant...)
{
PAO retval(new AO(irrelevant...));
prepare(*retval);
return retval;
}

This is similar to what is happening in Java/.NET world.

If copy-creation and copying of AO are expensive, you can easily
forbid them in C++ (simplest way: derive it from boost::noncopyable).
Also, you probably need to understand the rule of three of C and C++:

http://en.wikipedia.org/wiki/Rule_of...programming%29

Goran.
 
Reply With Quote
 
Fabrizio J Bonsignore
Guest
Posts: n/a
 
      09-17-2010
On Sep 17, 8:59*am, Goran <(E-Mail Removed)> wrote:
> On Sep 17, 3:53*am, Fabrizio J Bonsignore <(E-Mail Removed)> wrote:
> Come down... You seem to want this:


I am DOWN, stucked in a compiling problem.

> typedef std::auto_ptr<AO> PAO;


I said: pointers no, there is a pointer workaround but I need to know
why the compiler is rejecting the copy constructor looking for a non
definable signature.

> This is similar to what is happening in Java/.NET world.


I want C++, not Java nor .NET (whatever it is) nor any Java-C hybrid.

> http://en.wikipedia.org/wiki/Rule_of...programming%29


Rule of three, all right, THAT, is what is BROKEN, in this project AT
LEAST. Seems another project I have is accepting the code as I know it
but then produces errors in another unrelated area. Already tried
equalizing compiler flags but no, the compiler insists in ignoring the
**law of three**, which incidentally seems very suspicious when you do
have a decade and a half programming C++.

I do NOT want to FORBID expensive copying, I want to CONTROL IT. I do
not want to use boost, it is overhead-overkill (my searches and
backups break on the boost zip). In fact, if I do NOT want copying
and assignment, I DO NOT DEFINE THEM! Basically if I do not want them
I do not use them and it is clear by context the object has to be
totted around as a pointer (ie, window objects in Windows), but then
the system would produce spureous versions of the constructors! Seems
like this area of the language went SO ABSTRACT and STANDARD that it
did not touch CURRENT PRACTIVE and WORKING CASES. But then I am using
a downloadable compiler which seems to be far from an industrial heavy
some other provider s version.

Danilo J Bonsignore
 
Reply With Quote
 
Fabrizio J Bonsignore
Guest
Posts: n/a
 
      09-17-2010
I want this to be compilable and working AS IS:

class AO
{
public:
int i;
void Aha();// {i=1;}

AO &operator=(AO &x);// {i=x.i; return *this;}//should not matter if
inline or not

AO();// : i(0) {}
AO(AO &x);// {i=x.i;}
virtual ~AO();// {}
};

void AO::Aha() {
i=1;
}

AO::AO()
: i(0) {
}
AO::AO(AO &x) {
i=x.i;
}
AO &AO:perator=(AO &x) {
i=x.i;
return *this;
}
AO::~AO() {}

class BO
{
AO a;
public:

AO Retit();// {++a.i; return a;}
AO Retut();// {AO z; z.i = 10; return z;}
BO();
};

BO::BO() {
AO b;
b = a;
AO c(a);
AO d(b);
AO e(c);

a.Aha();
b.Aha();
c.Aha();
d.Aha();
e.Aha();

AO m = Retit();
AO n = Retit();
AO o(Retit());
AO p = n;
AO q = o;

AO f;
AO g = Retut();
AO h(Retut());
AO j = g;
AO k = h;

f = Retit();
f = Retut();
}

AO BO::Retit() {
++a.i;
return a;
}
AO BO::Retut() {
AO z;
z.i = 10;
return z;
}


BO testbo;

Danilo J Bonsignore
 
Reply With Quote
 
LR
Guest
Posts: n/a
 
      09-17-2010
Fabrizio J Bonsignore wrote:
> On Sep 17, 8:59 am, Goran <(E-Mail Removed)> wrote:
>> On Sep 17, 3:53 am, Fabrizio J Bonsignore <(E-Mail Removed)> wrote:
>> Come down... You seem to want this:

>
> I am DOWN, stucked in a compiling problem.
>
>> typedef std::auto_ptr<AO> PAO;

>
> I said: pointers no, there is a pointer workaround but I need to know
> why the compiler is rejecting the copy constructor looking for a non
> definable signature.


Can you please post the name of the compiler you are using and a very
small complete example that shows the error message you are getting.


>
>> This is similar to what is happening in Java/.NET world.

>
> I want C++, not Java nor .NET (whatever it is) nor any Java-C hybrid.
>
>> http://en.wikipedia.org/wiki/Rule_of...programming%29

>
> Rule of three, all right, THAT, is what is BROKEN, in this project AT
> LEAST. Seems another project I have is accepting the code as I know it
> but then produces errors in another unrelated area. Already tried
> equalizing compiler flags but no, the compiler insists in ignoring the
> **law of three**, which incidentally seems very suspicious when you do
> have a decade and a half programming C++.
>
> I do NOT want to FORBID expensive copying, I want to CONTROL IT. I do
> not want to use boost, it is overhead-overkill (my searches and
> backups break on the boost zip). In fact, if I do NOT want copying
> and assignment, I DO NOT DEFINE THEM!


Perhaps you ought to declare the copy ctor and assignment operator as
private and not give them bodies. At least this will verify at linkage
that you aren't using them.

LR
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-17-2010
Fabrizio J Bonsignore <(E-Mail Removed)>, on 17/09/2010 11:32:06, wrote:

> I want this to be compilable and working AS IS:


<snip original code>

Well, not exactly as is, as I had to fix some overly long one-line
comments and as I had to add some const here and there, but now it
compiles...

....hope that helps.

//-------
#include <iostream>

class AO {
public:
int i;
void Aha();// {i=1;}

AO &operator=(const AO &x);
// {i=x.i; return *this;}//should not matter if inline or not

AO();// : i(0) {}
AO(const AO &x);// {i=x.i;}
virtual ~AO();// {}
};

void AO::Aha() {
i=1;
}

AO::AO()
: i(0) {
}
AO::AO(const AO &x) {
i=x.i;
}
AO &AO:perator=(const AO &x) {
i=x.i;
return *this;
}
AO::~AO() {}

class BO {
AO a;
public:

AO Retit();// {++a.i; return a;}
AO Retut();// {AO z; z.i = 10; return z;}
BO();
};

BO::BO() {
AO b;
b = a;
AO c(a);
AO d(b);
AO e(c);

a.Aha();
b.Aha();
c.Aha();
d.Aha();
e.Aha();

AO m = Retit();
AO n = Retit();
AO o(Retit());
AO p = n;
AO q = o;

AO f;
AO g = Retut();
AO h(Retut());
AO j = g;
AO k = h;

f = Retit();
f = Retut();
}

AO BO::Retit() {
++a.i;
return a;
}

AO BO::Retut() {
AO z;
z.i = 10;
return z;
}

BO testbo;

using namespace std;

int main() {
cout << "Well, it compiles." << endl;
return 0;
}
//-------


--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
LR
Guest
Posts: n/a
 
      09-17-2010
Fabrizio J Bonsignore wrote:
> I want this to be compilable and working AS IS:


I made a few minor changes, but seems to compile, link and run.
>
> class AO
> {
> public:
> int i;
> void Aha();// {i=1;}
>
> AO &operator=(AO &x);// {i=x.i; return *this;}//should not matter if
> inline or not


What is the concern about the assignment operator being inline?
>
> AO();// : i(0) {}
> AO(AO &x);// {i=x.i;}
> virtual ~AO();// {}



virtual? Why?

> };
>
> void AO::Aha() {
> i=1;
> }
>
> AO::AO()
> : i(0) {
> }
> AO::AO(AO &x) {
> i=x.i;
> }


AO::AO(const AO &x)
:
i(x.i)
{}

I prefer my copy ctors to have const arguments and I prefer an
initialization list.


> AO &AO:perator=(AO &x) {
> i=x.i;
> return *this;
> }
> AO::~AO() {}
>
> class BO
> {
> AO a;
> public:
>
> AO Retit();// {++a.i; return a;}
> AO Retut();// {AO z; z.i = 10; return z;}
> BO();
> };
>
> BO::BO() {


BO::BO()
:
a()
{

> AO b;
> b = a;
> AO c(a);
> AO d(b);
> AO e(c);
>
> a.Aha();
> b.Aha();
> c.Aha();
> d.Aha();
> e.Aha();
>
> AO m = Retit();
> AO n = Retit();
> AO o(Retit());
> AO p = n;
> AO q = o;
>
> AO f;
> AO g = Retut();
> AO h(Retut());
> AO j = g;
> AO k = h;
>
> f = Retit();
> f = Retut();
> }
>
> AO BO::Retit() {
> ++a.i;
> return a;
> }


I think I'm somewhat missing the point of what you want to do. That code
is going to call a copy ctor. Is that what you want?

> AO BO::Retut() {
> AO z;
> z.i = 10;
> return z;
> }
>
>
> BO testbo;


Does the compiler you're using have some sort of optimization flag?
Perhaps it's trying to optimize too much?

What compilation error messages, linkage errors, or runtime errors are
you getting?

Again, can you please tell us what compiler you are using and post a
small complete example that demonstrates the problem you are having.

LR

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      09-17-2010
On 17 sept, 21:08, Fabrizio J Bonsignore <(E-Mail Removed)> wrote:

[rant]

It it is hard to understand what code on what compiler, where and for
what purpose you use. Better post code, it is hopefully less whiny. Be
a man, speak like a man, not like hurt alien of some sort. It is
usenet. Your own grandchildren may one day read it.

Feels that you want to make a constructor of class outside of class.
That is impossible and so you have to assign or copy construct
whatever you there constructed.

If you did not declare copy constructor and assignment operator then
compiler produces these for you (expect for cases the class was made
not copyable). That has been so as long i remember in C++ so i do not
get what you complain there.

 
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
Assignment operator self-assignment check Chris C++ 34 09-26-2006 04:26 AM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
Question about interference and Wireless Channel Assignment HOESan Wireless Networking 4 09-04-2004 08:36 PM
Comparison of Bit Vectors in a Conditional Signal Assignment Statement Anand P Paralkar VHDL 2 08-04-2003 08:40 PM
Help: conditional attribute assignment itsme VHDL 1 07-23-2003 03:26 PM



Advertisments