Thread: How do I avoid class destructor definition if class constructor is overloaded?

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Programmer_P
    That is a matter of opinion...
    Of course, but I am providing the opinion as someone with experience in C++.

    Quote Originally Posted by Programmer_P
    Actually, I was thinking in terms of objects. I was thinking in terms of only two objects of the class, one using the default constructor, the other using the argument constructor. And the lifetimes of the objects of the class, in this case, are not all that important. I basically create them in int main(), use them for their intended purpose, then let them fall off the stack once they go out of scope.
    Yes, and that's my point. These objects are not important. If they are not important, why create these objects? Why write this class when you can just write the functions directly? The class keyword (or struct, for that matter) does not magically add value to your program.

    Quote Originally Posted by Programmer_P
    Correction: The default constructor doesn't, but the argument constructor does.
    A constructor always creates an object of the class. But notice that I say that conceptually, the constructors of your class do not create objects of the class. This is confirmed by the nonsensical statement that "the default constructor doesn't".

    See, what you are talking about are not the objects of the class. You are talking about the members of the class. So, your claim that you were "thinking in terms of only two objects of the class" is suspect. Rather, you are just creating two objects of the class, but thinking in procedural terms. Therefore, these objects distract one from understanding the code, instead of enhancing the maintainability of the code. So why bother with this class when it does not add value to the code?

    Quote Originally Posted by Programmer_P
    Like already mentioned at least two times already, I no longer have a destructor. I have a cleanUp() function which is there to delete all "new" objects created in the argument constructor.
    No, you still have a destructor. In the absence of a user declared destructor, the compiler generates one for the class.
    Last edited by laserlight; 06-01-2010 at 11:29 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by StainedBlue View Post
    Look, I'm just trying to give you helpful criticism. I'm sorry, the class makes no sense. If you're coming from a Java background, I can understand the need to put *everything* in a class, but it just doesn't make sense, and this is why...

    If I have a class called FileOps, it should encapsulate only what is necessary for file operations. It's constructor, private members, and member functions should deal with file operations. Nothing else.

    If a user needs "help", then that is a completely separate matter, and doesn't belong in the FileOps class. Obviously you understand what I'm telling you --look to the very problems that you're having with your constructors/destructor! It's right there in front of you.

    The design of your class simply makes no sense, period.
    And I appreciate the helpful criticism.
    The purpose of using a class to begin with was to make use of the same objects across multiple functions, and to centralize the core of my program into one module, which int main() then uses and handles all the rest of the program logic.
    Yes, I know it makes more sense to have a class containing functions for one purpose alone, then having functions like "help()" for example. I don't know why I added that to the class. I guess its because I wanted all functions called by int main in the same class "CconvertEnumToStrings".

    Anyway, I understand there are other ways of doing things.

  3. #18
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by laserlight View Post
    Of course, but I am providing the opinion as someone with experience in C++.
    Yep, I know this. I'm certainly not disputing that fact...
    Yes, and that's my point. These objects are not important. If they are not important, why create these objects? Why write this class when you can just write the functions directly? The class keyword (or struct, for that matter) does not magically add value to your program.
    The purpose of using a class instead of global functions, like mentioned in my last post, is so I can use the same objects across multiple functions.
    A constructor always creates an object of the class. But notice that I say that conceptually, the constructors of your class do not create objects of the class. This is confirmed by the nonsensical statement that "the default constructor doesn't".
    I know this. I was talking about the internal objects of the class. The default constructor doesn't create any internal heap objects in the class.
    Obviously, we're talking about two different things here. You were talking about objects of the class, and I thought you meant objects internal to the class, hence the correction...
    See, what you are talking about are not the objects of the class. You are talking about the members of the class.
    Exactly. Obviously you were talking about the other one though...
    My bad.
    So, your claim that you were "thinking in terms of only two objects of the class" is suspect. Rather, you are just creating two objects of the class, but thinking in procedural terms. Therefore, these objects distract one from understanding the code, instead of enhancing the maintainability of the code. So why bother with this class when it does not add value to the code?
    I already answered that question, and it does add value to the code, despite what you think without having even seen the code.
    No, you still have a destructor. In the absence of a user declared destructor, the compiler generates one for the class.
    Yes, but that destructor wont do squat without any 'new' objects to delete...
    Last edited by Programmer_P; 06-01-2010 at 11:42 AM.

  4. #19
    ...and never returned. StainedBlue's Avatar
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by Programmer_P View Post
    I guess its because I wanted all functions called by int main in the same class "CconvertEnumToStrings".
    A *namespace* might provide better encapsulation for such a collection of classes/functions, not a class.

    Whether you know it or not, you're trying to follow MVC architecture here, which is a good thing. However, I think you're a little confused by what the role of a C++ class is.

    Seriously, if you've programmed in C# or Java, then classes as models/views/controllers makes perfect sense, in C++, not so much, or at least you need to adapt to how c++ programs are structured, which tends to be more *procedural* (as laserlight pointed out), then C#/Java programs (at least syntactically anyway)
    goto( comeFrom() );

  5. #20
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Programmer_P
    The purpose of using a class instead of global functions, like mentioned in my last post, is so I can use the same objects across multiple functions.
    You can pass those objects (by reference, if necessary) to the functions that need them.

    Quote Originally Posted by StainedBlue
    A *namespace* might provide better encapsulation for such a collection of classes/functions, not a class.
    I agree, though it is more like grouping than encapsulation.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #21
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    So why do you think you need a pointer to ifstream in your class?

  7. #22
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by laserlight View Post
    You can pass those objects (by reference, if necessary) to the functions that need them.
    Yes, but I prefer my method, because I don't have to worry about so many different function parameters, and so I can use the same exact names across multiple functions. It seems more natural to me, somehow...

  8. #23
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by whiteflags View Post
    So why do you think you need a pointer to ifstream in your class?
    I already answered that question in an earlier post.
    But I'll answer it again, I suppose: I'm using a pointer because I'm using the same ifstream object across multiple functions of my class.

  9. #24
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Programmer_P
    Yes, but I prefer my method, because I don't have to worry about so many different function parameters, and so I can use the same exact names across multiple functions. It seems more natural to me, somehow...
    If you have to worry about "so many different function parameters", then that could be a hint that you should be creating a class that models one thing and models it well. This way, your functions can then operate on an object of this class. But this is different from just lumping things as members of a class out of perceived convenience.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #25
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Yeah but that's hardly a good reason since you're using a class. In the first place, a regular object can be a private member of your class. Everything in the class can access that member. You don't even need to use a parameter. (Ugh, you're like esbo...)

    I can't think of any reason you would need the indirection at all.

  11. #26
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by laserlight View Post
    If you have to worry about "so many different function parameters", then that could be a hint that you should be creating a class that models one thing and models it well. This way, your functions can then operate on an object of this class. But this is different from just lumping things as members of a class out of perceived convenience.
    Yes, but the possible advantage of doing what you suggested is outweighed by the ability of having all code other than int main centralized in one class, as opposed to several different classes (each probably separated in their own file), when there is no real need to have it that way.

    Why go to more work then I have to?

    (And yes, nothing says I will do things this way with all programs I write... )

  12. #27
    ...and never returned. StainedBlue's Avatar
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by Programmer_P View Post
    I already answered that question in an earlier post.
    But I'll answer it again, I suppose: I'm using a pointer because I'm using the same ifstream object across multiple functions of my class.
    That's really not a good reason to store a pointer. Why not just an instance? Your member functions across the class will have access to the object whether it's an instance or a pointer. In your case, the pointer just complicates the implementation, it doesn't do you any good.
    goto( comeFrom() );

  13. #28
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Programmer_P
    Yes, but the potentional advantage of doing what you suggested is outweighed by the ability of having all code other than int main centralized in one class, as opposed to several different classes (each probably separated in their own file), when there is no real need to have it that way.
    This leads to tight coupling, making maintainance more difficult. It is not an advantage.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #29
    Programming Ninja In-T...
    Join Date
    May 2009
    Posts
    827
    Quote Originally Posted by whiteflags View Post
    Yeah but that's hardly a good reason since you're using a class. In the first place, a regular object can be a private member of your class. Everything in the class can access that member. You don't even need to use a parameter. (Ugh, you're like esbo...)

    I can't think of any reason you would need the indirection at all.
    If I use a regular object, it will go out of scope after the first function that uses it is called. Thus, I wont be able to access that same object across multiple functions, and call different methods of it. Hence, why i use a ifstream pointer which is pointed at a "new" object of ifstream...

  15. #30
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Programmer_P
    If I use a regular object, it will go out of scope after the first function that uses it is called.
    That is not true if the object is a member of the class. It is also not true for what I am suggesting: the object is passed by reference to the function, thus it does not go out of scope in that function.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Whats the best way to control a global class?
    By parad0x13 in forum C++ Programming
    Replies: 3
    Last Post: 11-12-2009, 05:17 PM
  2. deriving classes
    By l2u in forum C++ Programming
    Replies: 12
    Last Post: 01-15-2007, 05:01 PM
  3. Warnings, warnings, warnings?
    By spentdome in forum C Programming
    Replies: 25
    Last Post: 05-27-2002, 06:49 PM
  4. gcc problem
    By bjdea1 in forum Linux Programming
    Replies: 13
    Last Post: 04-29-2002, 06:51 PM
  5. Difficulty superclassing EDIT window class
    By cDir in forum Windows Programming
    Replies: 7
    Last Post: 02-21-2002, 05:06 PM