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

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

This is where you are mistaken - class members have class scope, meaning that the ifstream will be alive as long as the object is alive. It helps to understand the rules of scope in a C++ way when you build your class.

Hey Programmer_P do you own any books on this topic, object oriented programming?

Originally Posted by laserlight

This leads to tight coupling, making maintainance more difficult. It is not an advantage.

Ok, let's go at it from a different angle...
First of all, this class that we're all talking about is a very simple class, and has only a few simple functions. It contains functions for doing things like opening a file, checking to see if a file is opened, checking for enums in files, retrieving various elements of the enum (such as the enum name, all the enum values in a vector of strings), etc.

This is pretty basic stuff here...

By the time I get done debugging it (which I'm very close to right now, btw), everything should work as intended and "maintenance" wont be necessary. Which leads me to another point...rather than sitting here, typing up arguments directed at y'all, I can be completing my program, which I will now proceed to go do.

Originally Posted by whiteflags

This is where you are mistaken - class members have class scope, meaning that the ifstream will be alive as long as the object is alive. It helps to understand the rules of scope in a C++ way when you build your class.

You're right. I had read that before of course, but had forgotten it.
Thanks for the correction. I now know I don't need to use pointers at all, and hence no destructor or "cleanUp" function.

Hey Programmer_P do you own any books on this topic, object oriented programming?

Not on OOP, specifically, but I do have books which talk about it.
So I at least have a basic understanding of what OOP is. But, yeah, its definitely a topic which I will need to study more of...

Yeah but you basically admit that you're using something for the sake of it. I'm really surprised that if this code is so unimportant to you, you wont take the opportunity to listen to our advice, and develop good habits. Asking us for advice and arguing about it -- when nobody is wrong except in your OPINION -- is disrespectful.

All this "basic" stuff is just as basic if you didn't use your own class and did it procedurally; you're just defaulting to your OPINION and arguing ours.

So take your opinions and shove them, because you're guilty too, and let's continue with the day.

Both of you are right.
I don't why it always ends up like this...

I guess its because I enjoy arguing, and it helps me think.

Anyway, y'all have a nice life too.

Originally Posted by StainedBlue

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.

Ahh..I see you answered that one too. Sorry I didn't read that post sooner.
Yep, I now know that using pointers instead of instances is pointless, and I already edited my code.

Thanks guys.

Originally Posted by iMalc

Feel free to post a snippet of the class from your header file in future as it can save some time if we can simply show how it could be done instead rather than trying to describe how you could/should do it.

Yes, I will do that next time.

Anyway I think you're being nudged well towards the path of writing good C++ code. It's a long road, but we'll try to keep you on it.
Remember that it's also perfectly okay to post code as you start coding something, to see if others think your approach is a good one. You don't have to wait until you get into difficulties. At times doing this can be surprisingly useful, and I think you'll find that by doing this it will show that you're more open to suggestions and people wont feel the need to try hard to get across their opinion (myself included).

Right. That's good advice, and will I do my best to follow it.
For the record, I did end up separating my code into multiple class models. I have a class called "CfileOperations" for handling the file stuff, and I have a class "CenumOperations" for handling the enum strings stuff. CenumOperations inherits from CfileOperations, and I pass off to the parent class's constructor the input filepath and output filepath. I then have a class called "CconvertEnumToStrings" (the same class that originally contained nearly all my code, but not anymore) which inherits from CenumOperations and passes off the input filepath and output filepath to its parent class's constructor.
That way, I can create an object of "CconvertEnumToStrings" in int main, and through that one object, have access to all my functions (though, technically, I did that already).
Oh, and I put my help() function outside of any class and in the same source file as int main, like advised.
So, as you can see, I did follow the advice I received...

Originally Posted by StainedBlue

can you post your code? I for one would love to take a look at this...

I will post the whole program source code when I get done with it.
I'm almost done too. I just have to finish debugging this one function, and add the support for Windows-style input filepaths (currently I'm only supporting Linux-style), then it should be finished.