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

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++.

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.

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?

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.

Originally Posted by StainedBlue

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.

Originally Posted by laserlight

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...

Originally Posted by Programmer_P

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)

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.

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.

So why do you think you need a pointer to ifstream in your class?

Originally Posted by laserlight

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...

Originally Posted by whiteflags

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.

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.

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.

Originally Posted by laserlight

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... )

Originally Posted by Programmer_P

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.

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.

Originally Posted by whiteflags

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...

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.