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

How do I avoid class destructor definition if class constructor is overloaded?
I am using a default constructor and a constructor with two arguments.

When I create an object of the class with no arguments, using the default constructor, I want to avoid the class destructor because it causes a "Program received signal SIGSEGV, Segmentation fault." message when I debug (even though it compiles fine) because in the destructor I call a function which returns the value returned by the ifstream object filestreamInObject->is_open() function, and "filestreamInObject" is not created in the default constructor.

If you need to write a destructor, then you should write it such that it correctly destroys the object, regardless of how the object was validly constructed or modified.

Quote:

---

Originally Posted by laserlight

If you need to write a destructor, then you should write it such that it correctly destroys the object, regardless of how the object was validly constructed or modified.

---

The thing is, in the destructor, I wish to close the file opened in the constructor, before I delete the ifstream object "filestreamInObject". I do this by calling up "isFileOpen" which is a member function of my class which returns the value of the is_open function of my ifstream object, before attempting to close the file.

EDIT: Nevermind. I'll just call ifstream::is_open() directly from my destructor. I don't why I didn't think of that before...

ifilestreams and ofilestreams are closed by their destructors - whatever you're doing, keep that in mind.

It's not clear what you are asking, and even if you think you have it solved, you might still be doing the wrong thing and leaving yourself open to more bugs a little later on. Can you please post some code to illustrate your question?

It sounds like you have a pointer to an ifstream as a member. Having a pointer to an ifstream as a member is most often the wrong thing to do. Normally one would just have an instance of an ifstream as the member, in which case you would most likely not even need a destructor.

Is this advice sounding oddly familiar?
Seriously, you need to have a pretty compelling reason to use a raw pointer to anything, as a member of a class in properly written C++ code.

Quote:

---

Originally Posted by iMalc

It's not clear what you are asking, and even if you think you have it solved, you might still be doing the wrong thing and leaving yourself open to more bugs a little later on. Can you please post some code to illustrate your question?

It sounds like you have a pointer to an ifstream as a member. Having a pointer to an ifstream as a member is most often the wrong thing to do. Normally one would just have an instance of an ifstream as the member, in which case you would most likely not even need a destructor.

---

Yes, that is correct. I'm using a pointer, which I create a 'new' ifstream object from in the constructor, because I need to access various functions of the same object from different functions of my class.

Quote:

---

Is this advice sounding oddly familiar?
Seriously, you need to have a pretty compelling reason to use a raw pointer to anything, as a member of a class in properly written C++ code.

---

Yeah, it sounds vaguely familiar... :)
But I still think I have a pretty good reason to use a pointer instead of an ifstream instance.

I'll post some example code in a minute...

Oh, and I need to mention I ended up commenting out my destructor, because I copied its code to a cleanUp() function which I call from the object of my class which uses the argument constructor, after I get done with it. That way there is no conflict with the object that uses the default (no-argument) constructor.

Might not be the best solution, but it works...

Quote:

---

Originally Posted by Programmer_P

But I still think I have a pretty good reason to use a pointer instead of an ifstream instance.

---

Why do you think so?

Note that std::istream objects, and thus std::ifstream objects, are not copyable. This has ramifications on the copy behaviour of the objects of your class.

Quote:

---

Originally Posted by Programmer_P

Oh, and I need to mention I ended up commenting out my destructor, because I copied its code to a cleanUp() function which I call from the object of my class which uses the argument constructor, after I get done with it. That way there is no conflict with the object that uses the default (no-argument) constructor.

---

No, you're doing it the wrong way. Now, you have just created a situation where you need to remember to call this cleanUp() function, even in the face of exceptions. Furthermore, you need to remember when not to call it. Complicated, no?

Quote:

---

Originally Posted by laserlight

Why do you think so?

Note that std::istream objects, and thus std::ifstream objects, are not copyable. This has ramifications on the copy behaviour of the objects of your class.

---

That is fine, because I'm not trying to copy any ifstream object. I am using the same ifstream object created on the heap across multiple functions of my class.

Quote:

---

No, you're doing it the wrong way. Now, you have just created a situation where you need to remember to call this cleanUp() function, even in the face of exceptions. Furthermore, you need to remember when not to call it. Complicated, no?

---

Yeah...I realize that. However, seeing as my class is not abstract enough to re-use anywhere, most likely, and I wrote it to solve a specific problem, and there are only two objects of this class which I create (one using the default constructor, and the other using the argument constructor), and I called the cleanup function on the argument constructor, and I am 100% positive that I did that right, I don't think its a problem... ;)

Oh, and the object of my class that uses the default constructor, doesn't do anything with any ifstream object. All I'm using the default constructor object for is calling up the help() function of the class, which returns a string message detailing proper usage of the program.

What I find confusing is if your class is handling file IO, why does the default constructor not do anything with the file IO pointer, while the other constructor does?

This makes no sense.

Also, avoiding the destructor because one of your constructors seg faults is not a good reason to avoid calling the destructor. If your class needs a destructor, it always needs one, not just in certain cases.

Quote:

---

Originally Posted by StainedBlue

What I find confusing is if your class is handling file IO, why does the default constructor not do anything with the file IO pointer, while the other constructor does?

---

Because the default constructor is not there to do anything with files or anything related. Like I just mentioned, I create an object using the default constructor for the sole purpose of calling up a help() function of the class. That is all I use the default constructor for, so it doesn't need to do anything with filestreams.

Quote:

---

This makes no sense.

---

Yes, it does, and I just explained it. :)

Quote:

---

Also, avoiding the destructor because one of your constructors seg faults is not a good reason to avoid calling the destructor. If your class needs a destructor, it always needs one, not just in certain cases.

---

No, it doesn't. Not when I use the default constructor, because no objects are created by the default constructor. The argument constructor is the one that creates objects on the heap, hence the need for the destructor (now replaced with a "cleanUp()" function)...

Quote:

---

Originally Posted by Programmer_P

Yeah...I realize that. However, seeing as my class is not abstract enough to re-use anywhere, most likely, and I wrote it to solve a specific problem, and there are only two objects of this class which I create (one using the default constructor, and the other using the argument constructor), and I called the cleanup function on the argument constructor, and I am 100% positive that I did that right, I don't think its a problem...

---

Well, it is your code, so it is your choice. In my opinion, this defect in your design is quite serious, even if you believe that the code is throw-away code. You would do well to document the problem very clearly so that the class really never ever gets reused without being fixed. Even then...

Quote:

---

Originally Posted by Programmer_P

That is fine, because I'm not trying to copy any ifstream object. I am using the same ifstream object created on the heap across multiple functions of my class.

---

I think I understand your idea now: basically, this class is a sham. You would be better off just writing the whole thing procedurally, because that is essentially what you are doing. You are not thinking in terms of objects, and thus are not concerned with their lifetimes. The constructors do not conceptually construct objects of the class: they are just a means for you to be able to call functions via a particular syntax. The destructor does not conceptually destroy objects of the class: it is just fluff.

Quote:

---

Originally Posted by laserlight

Well, it is your code, so it is your choice. In my opinion, this defect in your design is quite serious, even if you believe that the code is throw-away code. You would do well to document the problem very clearly so that the class really never ever gets reused without being fixed. Even then...

---

First of all, though I plan on sharing the code for the purpose of others being able to compile and use the program, I don't expect the class to ever be re-used for anything, though anyone is welcome to edit the source code if they want, of course.
But the program is for a specific purpose (i.e. to get the string names of enum values), and the program will achieve that purpose and cleanup after itself. What more do I need out of the program?

Quote:

---

I think I understand your idea now: basically, this class is a sham.

---

That is a matter of opinion...

Quote:

---

You would be better off just writing the whole thing procedurally, because that is essentially what you are doing.

---

Another opinion...

Quote:

---

You are not thinking in terms of objects, and thus are not concerned with their lifetimes.

---

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.

Quote:

---

The constructors do not conceptually construct objects of the class: they are just a means for you to be able to call functions via a particular syntax.

---

Correction: The default constructor doesn't, but the argument constructor does.

Quote:

---

The destructor does not conceptually destroy objects of the class: it is just fluff.

---

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.

Quote:

---

Because the default constructor is not there to do anything with files or anything related. Like I just mentioned, I create an object using the default constructor for the sole purpose of calling up a help() function of the class. That is all I use the default constructor for, so it doesn't need to do anything with filestreams.

---

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.

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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)

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.

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

Quote:

---

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

Quote:

---

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.

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.

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.

Quote:

---

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

Quote:

---

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.

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

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

Quote:

---

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

Quote:

---

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

Quote:

---

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

Quote:

---

Originally Posted by Programmer_P

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.

---

I believe that this has already been pointed out to you: your class does not model one thing and model it well.

Quote:

---

Originally Posted by Programmer_P

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.

---

Maybe that is true. But you are new to C++ programming, right? So this is effectively practice, isn't it? If so, then you should be practicing good habits, not bad habits under the assumption that maintenance is unnecessary, because in the real world, such assumptions often prove unwarranted.

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.

Quote:

---

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.

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.

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

---

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

Quote:

---

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.