Question on this overload program

[yungman]

I have been working on making a deep copy of sum in operator+() by putting sum outside of the function so it doesn't not get destroyed when exit the function. I still run into problems I tested using strncpy_s for object First, Second works and display accordingly. but the problem is with operator+(). I don't know any better how to fix it. Please give me some guidance. This is really beyond my knowledge, it's hard to take a hint at this point.

Here is my work, I made it as short as possible for easy reading.

This is main:

#include <iostream>
#include "OverLoad.h"
#include <cstring>
using namespace std;

int main()
{ const int size = 25; char Ara[size] = "First", Arb[size] = "Second", Arc[size] = "Result";
    Vec First(Ara, 1, 2);
    cout << " In main,  " << First.name << "(" << First.x << "," << First.y << ")\n\n";

    Vec Second(Arb, 3, 4);
    cout << " In main,  " << Second.name << "(" << Second.x << "," << Second.y << ")\n\n";
    Vec Result(Arc);
    cout << " In main,  " << Result.name << "(" << Result.x << "," << Result.y << ")\n\n";
// Cannot use overload =
    Result = First + Second;
 //Cannot read Result.x, Result.y
    cout << " (" Result.x << "," << Result.y << ") = (" << First.x << "," << First.y <<
        ") = (" << Second.x << "," << Second.y << ") \n\n";
    return 0;
}

Here is the header file:

#ifndef OverLoad_H
#define OverLoad_H
#include <iostream>
#include <cstring>
using namespace std;
class Vec
{  
public: 
     double x, y; 
     char sumName[25] = "sum"; char name[25];
     Vec sum() { x = 0; y = 0; strncpy_s(name, 25, sumName, 25); }//OK, declaring Vec sum.
     Vec(char* desc)//work
        { x = 0;  y = 0; 
          strncpy_s(name, 25, desc, 25);
        }
     Vec(char* desc, double x0, double y0)//work
        { x = x0;  y = y0; 
          strncpy_s(name, 25, desc, 25);//Copy First or Second into name.
        }
     void operator+ (const Vec& rhs) const//sum is public, no need to return
        { sum.x = x + rhs.x;  sum.y = y + rhs.y;} //Problem using sum
     Vec &operator=(Vec &right)
        {x = right.x; y = right.y; return *this;}
};
#endif

This is the error list:

Please advice whether this is the right way to have deep copy.

Thanks

 

[Jarvis323]

You can do this:

Vec operator+ (const Vec& rhs) const {
    return Vec( "sum", x + rhs.x, y + rhs.y );
}

Which is really just a simplification of this,

Vec operator+ (const Vec& rhs) const {
    Vec sum(  "sum", x + rhs.x, y + rhs.y );
    return sum;
}

And you can use std::string as a helper, to make life easier if you want,

Vec operator+ (const Vec& rhs) const {
    return Vec(
        ( std::string( name ) + " + " + std::string( rhs.name ) ).c_str() ,
         x + rhs.x,
         y + rhs.y );
}

Note it is returning a Vec by value, which is crucial. You wouldn't want to return a temporary object by address/reference for reasons already explained.

While the returned Vec will go out of scope, it will be first passed into the copy constructor, or operator= function, of the object that you assign it to, or be used in an expression in some other way.

For example,

Vec v( "v", 0.0, 1.0 );
Vec u ( "u", 1.0, 0.9 );

Vec w = v + u;
Vec w( v + u  ); // above is short for this, since = was used during instantiation copy constructor is used
Vec w( v.operator+( u ) ); // above is short for this
// result of operator+ goes directly into copy constructor, where it is copied before it is destroyed

Vec w;
w = v + u; // in this case, since w is assigned after instantiation, operator= will be called
w.operator=( v.operator+( u ) ); // this is equivalent to above
// result of operator+ goes directly into operator=, where it is copied before it is destroyed

Also, you forgot to copy the name in operator=, and also it is advised to check for self assignment in operator=.

Vec &operator=(const Vec &right) {
    if ( this != &other ) {
        x = right.x;
        y = right.y;
        strncpy_s( name, 25, right.name, 25);
    }
    return *this;
}

For cases where you had a dynamic array (pointer to memory allocated with new), you can see how to do the deep copy in this link.

https://en.cppreference.com/w/cpp/language/operators

And like Mark pointed out below, get rid of your sum() member function.

 

[Mark44]

From post #31, Source.cpp:

// Cannot use overload =
    Result = First + Second;

Your comment above misses the point. The expression on the right of the assignment operator assumes that you have a valid operator+(), that returns a Vec object. You don't, since your implementation, shown below, returns void. IOW, your implementation doesn't return anything at all.

Since you haven't overloaded the + operator, the expression First + Second is a syntax error.

From the same post, Overload.h:

Vec sum() { x = 0; y = 0; strncpy_s(name, 25, sumName, 25); }//OK, declaring Vec sum.
.
.
.
void operator+ (const Vec& rhs) const//sum is public, no need to return
        { sum.x = x + rhs.x;  sum.y = y + rhs.y;} //Problem using sum

What's worse, you have a function member named sum(), but your operator+() seems to be using sum as if it were a Vec object. This is also wrong.

 

[yungman]

Guys, I have to get back to all these, I was searching on web and youtube, now I know what is shallow copy, you put the stuffs on stack, sounds like deep copy needs to put on heap. Is stack the same as the memory for push and pop stack in assembly language?

I do NOT know all these, that's why I was so lost when you guys tried to explain. I am still going to watch a little more on that first and I'll be back. These are all new to me. More new terms and names for me!

I'll be back in a little. Thanks both of you a lot, I don't want to waste any more of your time at this moment,

Thanks a million.Edit:
I did not even know operator=() is called assignment operator! I was searching and searching, couldn't find that until I did a wild guess after reading the book. The book didn't even use the name assignment, just one sentence about assigning a value that lead me to try that!

 

[Jarvis323]

Guys, I have to get back to all these, I was searching on web and youtube, now I know what is shallow copy, you put the stuffs on stack, sounds like deep copy needs to put on heap. ...

No. The stack is where memory is allocated for the local variables in a function. When a function is called, the stack is created to make that space, and when the function returns, the stack destroyed. So anything on the stack exists only inside of that function when it is called until it returns.

The heap is a global area to store things. You allocate some of it to use with new, for example, and then it stays allocated until you call delete. You access that memory through a pointer.

Deep copy is just a general concept. It means don't copy the address, copy what the address is pointing to. You do that when it makes sense to do. If you want to just have two copies of the address to the same memory on the heap, then that's what you do. If you want to have two objects each with their own copy of that memory, then the second object needs to allocate memory and copy the data over to it's own memory. It's like either two people sharing one house, or two people each with their own houses.

Any time you do assignment with a primitive c++ type (int, char, int*, char*, etc.), it is a straightforward copy of the value. But the pointer's value is an address. So, if copying the pointer isn't what you want, you need to go to that address and grab the stuff stored there to copy over.

 

[Filip Larsen]

And you can use std::string as a helper, to make life easier if you want,

Vec operator+ (const Vec& rhs) const {
return Vec(( std::string( name ) + " + " + std::string( rhs.name ) ).c_str() ,x + rhs.x,y + rhs.y );
}

Note it is returning a Vec by value, which is crucial. You wouldn't want to return a temporary object by address/reference for reasons already explained.

I know you guys are trying to help yungman as he goes in strange directions, but advice him to mix std::string and C-strings is in my opinion a good example of showing him how C++ happily let's people shoot themself in the foot if they really want to. The c_str() from the above expression is going to be a dangling pointer no matter what context you use it in.

I will repeat my recommendation to yungman: If you want to learn modern C++ then use the modern "safe" API's, like the standard library, instead of trying to visit every anti-pattern and trap that the C-style API's has to offer. Shooting yourself in the foot over and over is of course one kind of lesson, but since a workable and clean approach for C++ programs do exists, why not take that instead.

 

[Jarvis323]

The c_str() from the above expression is going to be a dangling pointer no matter what context you use it in.

I don't think so. I think that the temporary ( std::string( name ) + " + " + std::string( rhs.name ) ) is destroyed at the end of the expression it's part of. That occurs after the constructor it is an argument to returns.

https://stackoverflow.com/questions/584824/guaranteed-lifetime-of-temporary-in-c

since a workable and clean approach for C++ programs do exists, why not take that instead.

Which is the workable c++ approach though if he wants to have all of the data held by his struct be contiguous in memory? He could use std::array< char, N >, but really that's essentially the same thing as char [N]. Personally my preference would be to use string everywhere (including in the arguments) except exactly where it comes to being stored in the struct. Of course you should probably never try to retain the pointer inside a string beyond the expression it's used in though.

For example,

Vec( const std::string & desc, double x0, double y0)
{
    x = x0;  
    y = y0;
    strncpy_s( name, 25, desc.c_str(), 25 );
}

 

[Filip Larsen]

I don't think so. I think that the temporary ( std::string( name ) + " + " + std::string( rhs.name ) ) is destroyed at the end of the expression it's part of. That occurs after the constructor it is an argument to returns. In general it is fine to pass a temporary object as a const reference or pointer

I cannot disagree with that. Your post just just (re)triggered a general opinion I have on the matter.

My comment was based on the assumption that c-string was being used as is and not copied over to a new buffer as it is in this specific case. But this also my point. In general such constructions are like small bombs you place in your program ready to go off if you change one part that will break the assumptions of another part. I understand the needs and trade-offs for doing this when experienced people know what they do and they can encapsulate such assumptions (like hidden as implementation detail in a class, as could be argued is the case here), but if a novice programmer should know about this it is should be to have the pattern on his dont-use-this list and not as a tool in his toolbox.

I know I am repeating myself, but you can learn to build skyscrapers the easy way by looking at design and procedures that is known to work good, or you can do it the hard way by repeating all the mistakes until, one day perhaps, your building finally stands without collapsing. Or in other words, the way forwards should be learning good patterns in general and then occasional anti-pattern to know what to stay away from and why.

Edit: fixed silly wording.

 

[Jarvis323]

I cannot disagree with that. Your post just (re)triggered a general opinion I have on the matter.

My comment was based on the assumption that c-string was being used it is and not copied over as is the case for the constructor in this case. But this also my point. In general such constructions are like small bombs you place in your program ready to go off if you change one part that will break the assumptions of another part. I understand the needs and trade-offs for doing this when experienced people know what they do and they can encapsulate such assumptions (like hidden as implementation detail in a class, as could be argued is the case here), but if a novice programmer should know about this it is should be to have the pattern on his dont-use-this list and not as a tool in his toolbox.

I know I am repeating myself, but you can learn to build skyscrapers the easy way by looking at design and procedures that is known to work good, or you can do it the hard way by repeating all the mistakes until, one day perhaps, your building finally stands without collapsing. Or in other words, the way forwards should be learning good patterns in general and then occasional anti-pattern to know what to stay away from and why.

I agree with you, especially about the part where knowing the hidden implementation or standard details is necessary to know if it is safe or not. I guess code should be obviously safe just by looking at.

 

[Vanadium 50]

but advice him to mix std::string and C-strings is in my opinion a good example of showing him how C++ happily let's people shoot themself in the foot if they really want to.

I agree that, except in rare instances, one should not mix C and C++ strings. It adds confusion and potential for error with little benefit. However, to be fair, this advice has been given before and rejected by the OP. The people who are trying to help are doing the best they can.

Which is the workable c++ approach though if he wants to have all of the data held by his struct be contiguous in memory?

Why would one want that? To be less flip, you seem to be describing a desire to have an array of variable and mutable length elements in contiguous and unfragmented memory. That is a hard and expensive thing to do. It's seldom necessary.

 

[Jarvis323]

I agree that, except in rare instances, one should not mix C and C++ strings. It adds confusion and potential for error with little benefit. However, to be fair, this advice has been given before and rejected by the OP. The people who are trying to help are doing the best they can.
Why would one want that? To be less flip, you seem to be describing a desire to have an array of variable and mutable length elements in contiguous and unfragmented memory. That is a hard and expensive thing to do. It's seldom necessary.

One advantage is that you can read and write to and from disk much faster, and simpler. Or maybe you're using a gpu and need to move data to and from it, or maybe you are using mpi and moving data between processes.

The fact c and c++ guarantee contiguity of fields in a struct, in the order they are declared, is a pretty useful thing, especially for a vec.

That said a vec class with a string in it is also usually a bad idea as I mentioned. But maybe you have small strings you want associated with the vectors as some sort of categorical data, like a protein or something.

In yungman's case, I think he is still not ready to try binary IO with heap allocated and variable size data inside a class, as it would be more complicated to manage than anything he's done yet. And I knew he is going to want to do IO, like he did in the past, and I predicted he would run into a bunch of problems with that. So for him I think my recommendation will make his life easiest and prevent him from shooting himself in the foot a whole lot in the near future.

I also just thought, no matter if he should use an array in a class rather than a string, he should know the difference in terms of memory.

 

[jtbell]

I will repeat my recommendation to yungman: If you want to learn modern C++ then use the modern "safe" API's, like the standard library, instead of trying to visit every anti-pattern and trap that the C-style API's has to offer. Shooting yourself in the foot over and over is of course one kind of lesson, but since a workable and clean approach for C++ programs do exists, why not take that instead.

I can see where yungman is coming from, because I have a copy of the book he's using: Gaddis, Starting Out with C++, 6th ed. (2010). He provided a link to a PDF in a previous post in some other thread. Even though it's dated 12 years after the C++98 standard, it's still very "old-fashioned" in its treatment of std::string versus C-strings, and std::vector versus C-style arrays.

For example, it starts chapter 10 by introducing C-strings, and spends most of the chapter using them. The last section of the chapter introduces std::string. In later chapters, he always uses C-strings, as far as I can tell. The material on std::string was obviously "tacked onto" an earlier edition of the book. Chapter 7 handles C-style arrays and std::vector similarly.

Unfortunately, I don't know a more modern textbook to suggest (*), that is, a real textbook intended for college/university introductory programming courses. I stopped teaching such a course around 2005, when I had to give it up to another person in my department. He switched the course to Java, because that was the trend in the US at that time. I suspect there isn't much demand for C++ textbooks for such courses any more.

Gaddis's book is now in its 9th edition. The table of contents that I can see at the publisher's website looks pretty much the same, which suggests that its treatment of std::string and std::vector is the same, unfortunately.

(*) except for the book that I used in my course, which is long out of print, but which is now freely available from the author, as I've posted elsewhere.

 

[Mark44]

The stack is where memory is allocated for the local variables in a function. When a function is called, the stack is created to make that space, and when the function returns, the stack destroyed. So anything on the stack exists only inside of that function when it is called until it returns.

I disagree with part of the above. The stack is neither created nor destroyed. When a program starts up, it has its own chunk of stack storage to work with, as well as its own chunk of heap storage. When a function is called, space is allocated on the stack for local variables and function parameters. When the function returns to its caller, that stack space is reclaimed for possible later use by other functions or the OS.

 

[yungman]

I just want to give a quick reply to acknowledge everyone. I am just barely get to Jarvis323 post 32. It will take me a while to go and try out the suggestions one by one and ask question as this is important. I don't want to seem rude ignoring all your hard work posting.

This is how I feel I'm learning, none of these are in the book, the book only show one example of each, the scope is very limited, looking at different ways of doing things is a good learning process even though it turns out it shouldn't be done that way. So I am taking my time on this even if I have to stretch chapter 14 beyond Christmas.

Like I experimented in post 31 declaring sum outside the operator+(), it is NOT the usual way. BUT according to P825 of Gaddis's book, you can totally change the inside of a operator function:

I declared sum inside the header file separately. But I got error when I put sum.x = x + rhs.x inside operation+(). I should be able to do that EVEN it is not the best way. Why the compiler gave me an error? It's not that I insist to do it my way, I want to know why. I think this is very important to know even though that's NOT the right way to do. I would like to find out why. I am sure I'll run into this kind of things in the future. My thinking was if I declare sum outside operator+(), it will NOT be destroyed when exiting the function. I still think that is one way of "deep" copying in a twisted sense!

Almost all the things in this thread is not talked about in the book, the book only show one way of doing things. I find this is very educational. Let me get back to jarvis323's post 32.

I'll be back.

Thanks.

 

[Vanadium 50]

One advantage is that you can read and write to and from disk much faster, and simpler

My preference here is transient-persistent separation: the way you write data might be different from how you use it. You can do a lot of processing while the CPU is waiting for the data to rotate its way under the disk read head. Also, my experience is that there is more to be gained by storing less data than packing it more efficiently.

My data is all transparently compressed by the files system by LZ4/ Padding space between objects with nulls is no big deal - they will be (largely) compressed away so there is little penalty for them.

 

[Jarvis323]

My preference here is transient-persistent separation: the way you write data might be different from how you use it. You can do a lot of processing while the CPU is waiting for the data to rotate its way under the disk read head. Also, my experience is that there is more to be gained by storing less data than packing it more efficiently.

My data is all transparently compressed by the files system by LZ4/ Padding space between objects with nulls is no big deal - they will be (largely) compressed away so there is little penalty for them.

In my case, I am doing distributed computing with MPI on 3d multivariate data. I need to do things like have each process load one chunk of the data, and also in parallel write it's result so that the results from all processes are combined into one file. And sometimes the layout of the chunk of data to read or write is not contiguous inside memory for each process, but is structured regularly. For this I use MPI_IO collective read and write operations with custom file views, that require you have some regular structure, because you specify how the process writes it's part based on offsets and sizes and stuff like that. Then also the data is huge, and IO is sometimes the bottleneck, so IO performance is critical. And then once the data is read, it's copied onto gpu's, using cudaMemcpy, for example. If I have a struct or class which doesn't allocate heap memory, then everything I described is perfectly fine. But if I had an std::string mixed in, then I would have a major headache. That said, the data has always been numerical.

 

[Mark44]

just want to give a quick reply to acknowledge everyone. I am just barely get to Jarvis323 post 32.

Before you post a response it would be a good idea to read all of the responses by other members, and not just stop at some post 10 or 15 posts back. That way you might not have to post a question that has already been answered.

BUT according to P825 of Gaddis's book, you can totally change the inside of a operator function:

And he says, "it is not a good programming practice." Just because the language allows you to do something, doesn't mean it's a good thing to do.

I declared sum inside the header file separately. But I got error when I put sum.x = x + rhs.x inside operation+().

There's an explanation in post #33. It's frustrating for many of us when you don't read or skip over some posts, and then ask a question that has already been answered.

 

[Jarvis323]

Also, you don't have to use my suggestion, instead as others have suggested, you are probably better off just using std::strings, and just move on rather than get hung up in this c-style stuff.

 

[yungman]

Before you post a response it would be a good idea to read all of the responses by other members, and not just stop at some post 10 or 15 posts back. That way you might not have to post a question that has already been answered.
And he says, "it is not a good programming practice." Just because the language allows you to do something, doesn't mean it's a good thing to do.
There's an explanation in post #33. It's frustrating for many of us when you don't read or skip over some posts, and then ask a question that has already been answered.

Too many new stuffs here, I just had to stop and asked about initialization list before I can move on. Do you know if I don't understand things in a few consecutive post, reading on blindly is a waste of time. I thought I am being courteous to come back and said I'll get to it instead of letting everyone spent their time posting and I am MIA! This is no win. It might be very obvious to expert like you, for me, I have been grasping for air and try to keep my head above water right now.

I am trying to learn as much on my own I was watching a good video on assignment operator and Copy Constructor, the initialization lists stuff came up and I had to stop and search as I won't be able to follow if I don't understand it. These are NOT in the book.

 

[Mark44]

Do you know if I don't understand things in a few consecutive post, reading on blindly is a waste of time.

It's a waste of our time if you don't read what we have already written, and then ask a question that was answered in a post you didn't read or skipped over. I wouldn't have brought it up if the same thing had not happened several times.
At the very least, you could scan through the responses and see if someone has answered a question that you are about to ask. It's not necessary that you understand everything others have written on the first pass through it. You can always go back through the responses again, and focus more deeply on what you don't understand.

 

[yungman]

Is physics forum going to condone V50 with all the spikeful remarks in this prestige forum? He is NOT helping except being spikeful. This is an education forum, he is obviously taking it very personal. Notice he putting LIKE on everything that is degrading to me? This is small...on his part. Get a life. You can band me, I'll find other ways to learn C++, I just want to point out the lack of life of him, Get a life, find something better to do! When I was on PF advising people on EE, if they are rude, I'd say it once and just put on ignore. I have better things to do in life.

 

[Mark44]

Is physics forum going to condone V50 with all the spikeful remarks in this prestige forum? He is NOT helping except being spikeful.

V50 has two posts in this thread, neither of which was aimed at you or discussed you in any way.

BTW, the word is "spiteful."

Notice he putting LIKE on everything that is degrading to me?

The things that you view as being degrading to you are for the most part truthful comments about the way you approach this forum. I would agree that some of V50's comments in other threads were harsh, but for you to complain about posts in this thread that V50 agrees with and likes is pretty thin.

You come here to this forum to ask for help, and get tons of help. If we ask you to make it easier to help you by making your code easier to read, by reading our replies before launching into posts with questions we've already answered, it seems to me a more reasonable thing to do would be to help us out, not post baseless complaints.

 

[yungman]

V50 has two posts in this thread, neither of which was aimed at you or discussed you in any way.

BTW, the word is "spiteful."
The things that you view as being degrading to you are for the most part truthful comments about the way you approach this forum. I would agree that some of V50's comments in other threads were harsh, but for you to complain about posts in this thread that V50 agrees with and likes is pretty thin.

You come here to this forum to ask for help, and get tons of help. If we ask you to make it easier to help you by making your code easier to read, by reading our replies before launching into posts with questions we've already answered, it seems to me a more reasonable thing to do would be to help us out, not post baseless complaints.

This is a long feud between me a V50. He needs to get a life instead of being spiteful. We are all old, just let it go.

The difference is he only mock and spite, he never helps. Like I said, I was on the other end not too long ago advising people, give it a rest to the beginners. Don't like it, don't respond. Don't spite people, get a life.

 

[Mark44]

@yungman, regarding the problem you were trying to solve when you opened this thread (adding a C-string name field to the class), here are some pieces of my solution. The code is based on what @jtbell posted.
The class definition, in what I'm calling ThreeV.h:

#include <iostream>
#include <cstring>

using std::cout; using std::endl;
using std::ostream;
const int SIZE = 25;

class ThreeVector
{
private:
    double x, y, z;
    char name[SIZE];
    int serialNum;          // unique for each ThreeVector instance
    static int numVectors;  // counts the number of ThreeVectors constructed
public:
    ThreeVector();                        // default constructor
    ThreeVector(double, double, double, const char*);
    ThreeVector(const char* name);
    ThreeVector(const ThreeVector&);      // copy constructor
    ~ThreeVector();
    ThreeVector operator+ (const ThreeVector&) const;
    ThreeVector& operator= (const ThreeVector&);
    friend ostream& operator<< (ostream& out, const ThreeVector& v);
};

A couple of the function definitions, in the same file:

// Default ctor
ThreeVector::ThreeVector()
{
    x = 0;  y = 0;  z = 0;
    strncpy_s(name, SIZE - 1, "Default", SIZE - 1);
    numVectors++;
    serialNum = numVectors;    
    cout << "-- Default-constructed vector #" << serialNum << endl;   
}
// Another ctor
ThreeVector::ThreeVector(double x0, double y0, double z0, const char * str) 
{
    x = x0;  y = y0;  z = z0;
    strncpy_s(name, SIZE-1, str, SIZE - 1);
    numVectors++;
    serialNum = numVectors;
    cout << "-- Constructed vector #" << serialNum << endl;     
}

// Overloaded operator+()
ThreeVector ThreeVector::operator+ (const ThreeVector& rhs) const
{
    ThreeVector sum("Sum");
    sum.x = x + rhs.x;  sum.y = y + rhs.y;  sum.z = z + rhs.z;
    //cout << "-- " << *this << " + " << rhs
    //    << " = " << sum << "." << endl;
    cout << "Return from operator+..." << endl;
    return sum;    
}

Not shown are

• a constructor that initializes the name portion with a specified string, and initializes the other data members to 0
• a copy constructor
• the destructor (same as jtbell posted)
• overloaded operator=()
• overloaded operator<<() (same as jtbell posted)

The class consumer:

#include <iostream>
#include "ThreeV.h"
using std::cout; using std::endl;

int main()
{    
    cout << "Declare a and b..." << endl;
    ThreeVector a(1, 2, 3, "VecA"), b(4, 5, 6, "VecB");
    cout << "a: " << a << " b: " << b << endl;
    cout << "Declare c and add c = a + b..." << endl;
    ThreeVector c;
    ThreeVector d("VecD");
    cout << "c: " << c << " d: " << d << endl;
    c = a + b;
    cout << "c: " << c << endl;
    cout << "Return from main()..." << endl;    
}

 

[yungman]

Hi Mark

I want to first apologize to you and the forum that my anger got the best of me yesterday and got you caught in the middle.

I did take a detour as I want to learn deeper into shallow copy and more on assignment operator. But I am back. I really want to catch up the posts I've missed since yesterday. Just want to make sure you know I am not MIA, I am back, give me some time to catch up with your suggestion and Jarvis323's first and work down the line.

Thanks for all your help. I'll be back.

Alan

 

[yungman]

From post #31, Source.cpp:

// Cannot use overload =
    Result = First + Second;

Your comment above misses the point. The expression on the right of the assignment operator assumes that you have a valid operator+(), that returns a Vec object. You don't, since your implementation, shown below, returns void. IOW, your implementation doesn't return anything at all.

Since you haven't overloaded the + operator, the expression First + Second is a syntax error.

From the same post, Overload.h:

Vec sum() { x = 0; y = 0; strncpy_s(name, 25, sumName, 25); }//OK, declaring Vec sum.
.
.
.
void operator+ (const Vec& rhs) const//sum is public, no need to return
        { sum.x = x + rhs.x;  sum.y = y + rhs.y;} //Problem using sum

What's worse, you have a function member named sum(), but your operator+() seems to be using sum as if it were a Vec object. This is also wrong.

Thanks for the reply. I was trying to declare sum as an object of Vec not a member function. How can I do that in the class declaration?

My goal is to have a real object to use in the operator+() so it won't be destroyed upon exiting the function.

I tried

char sumName[25] = "sum";
Vec(){ name = sumName; x = 0; y = 0}// constructor with no argument
Vec sum();

It didn't work. So I tried the other way. Seems like I cannot declare an object inside the class definition.Thanks

 

[Mark44]

I was trying to declare sum as an object of Vec not a member function. How can I do that in the class declaration?

Look at the code of yours that I quoted, and that you just quoted. You have a function named sum that returns a Vec object and in your operator+() overload, you have some undeclared object named sum. You can't do that!

My goal is to have a real object to use in the operator+() so it won't be destroyed upon exiting the function.

Why? Look at the code I posted in post #54. I show an implementation of operator+() that works. That code creates a temporary object named sum, and returns it. Before it gets destroyed, the overloaded operator=() will assign the values in sum to whatever object is on the left side of the assignment.

 

[Mark44]

I tried

char sumName[25] = "sum";
Vec(){ name = sumName; x = 0; y = 0}// constructor with no argument
Vec sum();

It didn't work. So I tried the other way. Seems like I cannot declare an object inside the class definition.

Line 3 is wrong. When you create an object by calling the default constructor, you don't include the parentheses.
Look at the code I provided, in the part with main(). I didn't give you all the code, but you should be able to fill in the missing pieces and get the code in main() to run.

 

[yungman]

Hi Mark
I copied your program in post

@yungman, regarding the problem you were trying to solve when you opened this thread (adding a C-string name field to the class), here are some pieces of my solution. The code is based on what @jtbell posted.
The class definition, in what I'm calling ThreeV.h:

#include <iostream>
#include <cstring>

using std::cout; using std::endl;
using std::ostream;
const int SIZE = 25;

class ThreeVector
{
private:
    double x, y, z;
    char name[SIZE];
    int serialNum;          // unique for each ThreeVector instance
    static int numVectors;  // counts the number of ThreeVectors constructed
public:
    ThreeVector();                        // default constructor
    ThreeVector(double, double, double, const char*);
    ThreeVector(const char* name);
    ThreeVector(const ThreeVector&);      // copy constructor
    ~ThreeVector();
    ThreeVector operator+ (const ThreeVector&) const;
    ThreeVector& operator= (const ThreeVector&);
    friend ostream& operator<< (ostream& out, const ThreeVector& v);
};

A couple of the function definitions, in the same file:

// Default ctor
ThreeVector::ThreeVector()
{
    x = 0;  y = 0;  z = 0;
    strncpy_s(name, SIZE - 1, "Default", SIZE - 1);
    numVectors++;
    serialNum = numVectors;
    cout << "-- Default-constructed vector #" << serialNum << endl;
}
// Another ctor
ThreeVector::ThreeVector(double x0, double y0, double z0, const char * str)
{
    x = x0;  y = y0;  z = z0;
    strncpy_s(name, SIZE-1, str, SIZE - 1);
    numVectors++;
    serialNum = numVectors;
    cout << "-- Constructed vector #" << serialNum << endl; 
}

// Overloaded operator+()
ThreeVector ThreeVector::operator+ (const ThreeVector& rhs) const
{
    ThreeVector sum("Sum");
    sum.x = x + rhs.x;  sum.y = y + rhs.y;  sum.z = z + rhs.z;
    //cout << "-- " << *this << " + " << rhs
    //    << " = " << sum << "." << endl;
    cout << "Return from operator+..." << endl;
    return sum;
}

Not shown are

• a constructor that initializes the name portion with a specified string, and initializes the other data members to 0
• a copy constructor
• the destructor (same as jtbell posted)
• overloaded operator=()
• overloaded operator<<() (same as jtbell posted)

The class consumer:

#include <iostream>
#include "ThreeV.h"
using std::cout; using std::endl;

int main()
{
    cout << "Declare a and b..." << endl;
    ThreeVector a(1, 2, 3, "VecA"), b(4, 5, 6, "VecB");
    cout << "a: " << a << " b: " << b << endl;
    cout << "Declare c and add c = a + b..." << endl;
    ThreeVector c;
    ThreeVector d("VecD");
    cout << "c: " << c << " d: " << d << endl;
    c = a + b;
    cout << "c: " << c << endl;
    cout << "Return from main()..." << endl;
}

Hi Mark

Do you mean I just copy the ones in bold blue above straight from Jtbell's program with no change?

Also. For what ever reason passing c-string like ThreeVector a(1, 2, 3, "VecA") never works. I always have to:

char name[]="Alan";
ThreeVector a(1, 2, 3, name);

Don't ask me why, it always is! Is it because my VS is the free version?

Thanks

 

[jtbell]

For what ever reason passing c-string like ThreeVector a(1, 2, 3, "VecA") never works. I always have to:

char name[]="Alan";
ThreeVector a(1, 2, 3, name);

What is the code for that constructor? I don't see one that matches, in the code that you've previously posted in this thread. (Forgive me if I somehow managed to skip past it while scrolling through the three pages of this thread...)

Also, what error message did you get?