Calling an object's constructor?

This is a discussion on Calling an object's constructor? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Daved I still think you should use vector. What is the advantages of using vector? I would ...

  1. #16
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Quote Originally Posted by Daved View Post
    I still think you should use vector.
    What is the advantages of using vector? I would still have to declare an assignment operator and a copy assignment operator. Or is is there any other advantage? Btw, do vector copy the array data during assignment? The simplest way can imagine is to use byte* instead of vector (constructors taking adress to the pixels still take void*), and just copy the pointer during assignment, then I don't have to wory about the behaviour of vector either. Else the code
    Code:
    dest_image = mp_image(w/n, h/n);
    would first create an array of pixeldata, then copy the data into a new memory allocation, and loose the reference to the original data when the assignment has finished. All copying of pixeldata shall be done not by assignment, but a separate copy image function.

    Quote Originally Posted by Sander View Post
    Yes, like Daved said. I would assume that your image class also has some method to get at the pixel data (which you had elided for briefness). A reasonable rule of thumb is that if a function can be external to your class (perhaps a friend function, if need be) then it probably should.

    If you follow this rule of thumb, your data types will consolidate faster. This may not sound too important if you're working on a project all by yourself, but in multi-people projects it's very nice if your image.h header file stabilizes early on in the project, and needs infrequent changes.
    That make sense, I should consider using that method instead.
    Come on, you can do it! b( ~_')

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,785
    A vector is good because all of its contents is copied when you try to assign it to another vector.
    If you store pointers in the vector, the pointers are copied.
    If you store the actual data in the vector, the actual data is copied.
    This will make sure you don't have to manage the memory yourself. No need for operator =. No need for copy constructor. The vector should handle it all.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> I would still have to declare an assignment operator and a copy assignment operator.
    Would you? I don't think so.

    The biggest advantage is that it is less error prone. You don't have to write the copy and destruction operations yourself, they are already done (and done right). You don't have to worry about exceptions in your code, because if an exception is thrown the vector cleans up automatically.

    A vector works like a dynamic array you create with new[]. It copies its contents when you copy it. Normally this is what you want. If you want the copy to share the same data (so modifying one changes the other) then you can store pointers in the vector.

  4. #19
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Quote Originally Posted by Elysia View Post
    If you store pointers in the vector, the pointers are copied.
    If you store the actual data in the vector, the actual data is copied.
    That is what I don't want. I need an assignment operator which copies the pointer and not the data, else the original data will leak out after assignment:

    Code:
    existing_object = object_class(...);
    The object created by the object_class(...) should be directly assigned to existing_object.

    Quote Originally Posted by Daved View Post
    >> I would still have to declare an assignment operator and a copy assignment operator.
    Would you? I don't think so.
    I compiled and tried to run the program before I had declared the assignment operator, but I got a message saying the program had terminated with a result indicating an error, when trying to assign, and I assume changing a pointer to a vector wouldn't make it better. When I later declared the operator it worked. But maybe that error was caused by another reason? It might well be so.

    Quote Originally Posted by Daved View Post
    A vector works like a dynamic array you create with new[]. It copies its contents when you copy it. Normally this is what you want. If you want the copy to share the same data (so modifying one changes the other) then you can store pointers in the vector.
    Now you got to explain why I should keep a vector of pointers instead of pixel data? That seems totally unmotivated to me.

    Anyway, it was what I wanted in this case, unless there is some equally simple and flexible solution to the problem I had with using a constructor for an already existing object.
    Come on, you can do it! b( ~_')

  5. #20
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,785
    Quote Originally Posted by TriKri View Post
    That is what I don't want. I need an assignment operator which copies the pointer and not the data, else the original data will leak out after assignment:

    Code:
    existing_object = object_class(...);
    The object created by the object_class(...) should be directly assigned to existing_object.
    It will not leak; the data will be copied to the new object. It's a deep copy we're talking about here.
    However, if you store pointers in the vector, we'd basically have a shallow copy.

    I compiled and tried to run the program before I had declared the assignment operator, but I got a message saying the program had terminated with a result indicating an error, when trying to assign, and I assume changing a pointer to a vector wouldn't make it better. When I later declared the operator it worked. But maybe that error was caused by another reason? It might well be so.
    Do you understand why?
    Because if you create 2 classes, and assign a to b, then both objects would have the same pointer. And when one goes out of scope, it deletes the memory. When the second goes out of scope, it tries to delete the memory, but fails.
    So what you needed was an assignment operator to copy the data to the new instance.
    If you want to copy data like that, all you need to do is make that pointer a vector instead, and it will save you from allocating, freeing and copying the data.
    No assignment operator necessary, nor destructor, nor even copy constructor.

    Now, if you still insist on keeping a pointer (it's more efficient, after all), then the solution would be to use a smart pointer. There's one called shared_ptr, located in std::tr1::shared_ptr, or alternatively, if your compiler does not have TR1 support, boost::shared_ptr (you can download boost for free).
    The shared pointer will keep a countdown of the "shared" memory so it will only be destroyed once the last pointer to it goes out of scope.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> I need an assignment operator which copies the pointer and not the data, else the original
    >> data will leak out after assignment

    Can you explain further what you mean by this, perhaps with code?


    >> I assume changing a pointer to a vector wouldn't make it better.

    It would make it better. That's the whole point. When you store a pointer in your class, the compiler copies the pointer, not what it points to. This is bad because you end up with two pointers pointing to the same spot and both of them getting deleted (or one getting deleted before the other is done using it).

    When you store a vector in your class, the compiler copies the vector, and the vector is already set up to copy the data correctly. You don't have to write the copy functions or destructor because the compiler's version uses the vector and the vector has already done all that same work for you.


    >> Now you got to explain why I should keep a vector of pointers instead of pixel data?

    You probably shouldn't. That was just a general comment about copying versus sharing data.

  7. #22
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Ok, I see your point. I didn't think the destructor would be called when the object went out of scope, hence I thought there would be a leak. So I would probably want to use something like shared pointers (I have thought of similar solutions before), allthough each chunk of pixeldata is ment to be preserved for only one image. If two images refere to the same data, it is only going to be temporary, like in this case.
    Come on, you can do it! b( ~_')

  8. #23
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Then I have another question: How do C++ decide when an object falls out of scope? If an object is created within a function, I suppose it falls out of scope when the function returns. But how about when the object is also returned by the function? If it's returned by reference (using the & indicator), the object will be needed at a later point and hence can't fall out of scope ... so when does it fall out of scope? And what's the practical difference between a function returning a variable of type my_class and a function returning a variable of type my_class&? Does an object returned by a function fall out of scope as fast as it isn't in use any more?

    Thanks
    Come on, you can do it! b( ~_')

  9. #24
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    If you declared the variable in the function, then it ceases to exist when the function ends. If you want to return a reference to it, that's too bad -- it still ceases to exist.

    If you create the variable with new, then it exists until you get rid of it with delete.

  10. #25
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,785
    All variables on the stack is cleaned up when the } for that level is found.
    Code:
    void foo()
    {
        int x;
        {
            int y;
        } // y dies here
    } // x dies here
    Simple. It doesn't matter how many references or pointers or whatever there's to it. When it goes out of scope, it dies. The end.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #26
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> what's the practical difference between a function returning a variable of type my_class and a function returning a variable of type my_class&? <<

    One will make a copy (that might be optimized away), the other will return a reference. If the object you're returning goes out of scope, then the reference will be invalid and you will have problems. If the reference is to an object that doesn't go out of scope (like a global or member variable), then you will avoid the copy but also expose that object to being modified.

  12. #27
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Quote Originally Posted by Daved View Post
    One will make a copy (that might be optimized away), the other will return a reference. If the object you're returning goes out of scope, then the reference will be invalid and you will have problems. If the reference is to an object that doesn't go out of scope (like a global or member variable), then you will avoid the copy but also expose that object to being modified.
    So If I want to assign a returned object to another object, I'd better not return it by reference if it's on the stack, got it.

    Thanks!
    Come on, you can do it! b( ~_')

  13. #28
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    I think I have come up with a feasible solution, inspired of iMalc's suggestion, and the fact that auto_ptr has its internal pointer set to NULL when it's assigned from by another auto_ptr.

    When an mp_image assigns from another mp_image, it sets the pointer inside the other object to NULL, making that object incapable of deleting the pixel data when it moves out of scope. What do you think of that idea?
    Come on, you can do it! b( ~_')

  14. #29
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,931
    When an mp_image assigns from another mp_image, it sets the pointer inside the other object to NULL, making that object incapable of deleting the pixel data when it moves out of scope. What do you think of that idea?
    It may be workable, but then you have the same disadvantages as auto_ptr: your mp_image does not have normal copy semantics, so it cannot be stored in a standard container (and other containers that rely on normal copy semantics).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #30
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Why would I want to enable mp_image:s to be stored in standard containers?
    Come on, you can do it! b( ~_')

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 06-02-2008, 08:09 AM
  2. Replies: 60
    Last Post: 12-20-2005, 10:36 PM
  3. array of objects?
    By *~*~*~* in forum C++ Programming
    Replies: 4
    Last Post: 05-31-2003, 05:57 PM
  4. Calling constructor of the base class of a derived class..
    By CaptainPenguin in forum C++ Programming
    Replies: 5
    Last Post: 02-19-2003, 12:47 PM
  5. Can't find my constructor
    By Nippashish in forum C++ Programming
    Replies: 4
    Last Post: 12-06-2002, 07:17 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21