Thread: Defining char arrays as string literals

Originally Posted by Programmer_P

And can't you only define (and/or declare) objects inside int main (which would exist in the main source code file)?

No, you can define them in other functions as well (including member functions), or if they are to have static storage duration, outside of functions too.

Originally Posted by Programmer_P

The whole point I'm getting at here is I want to define my member variables inside the same file as the class, and so in this particular case, the same file which will store "edit_menu_options_class" which will be separate from main.cpp.

I think that instead of "define" you want to "initialise" in the sense of providing an initial value other than garbage.

Originally Posted by Programmer_P

Ok, so would something like this work?

Yes (other than the global main function), but why is the member variable protected instead of private? You also do not need to explicitly define the destructor. You should use the initialisation list in the constructor, e.g.,

Code:

edit_menu_options_class::edit_menu_options_class() : undo("Undo") {}

As for the global main function... it depends on what you are trying to do. Obviously attempting to print a variable that has not even been declared will not work.

Originally Posted by Programmer_P

I made it protected because I plan to have the stuff that option actually does in a derived class of edit_menu_options_class.

That sounds like you are using public inheritance to reuse an implementation rather than to allow the derived class to be used by an existing implementation (i.e., to make use of polymorphism). It is not necessarily wrong, but it is not likely to be a good solution either.

Originally Posted by laserlight

That sounds like you are using public inheritance to reuse an implementation rather than to allow the derived class to be used by an existing implementation (i.e., to make use of polymorphism). It is not necessarily wrong, but it is not likely to be a good solution either.

Huh? How did you draw that conclusion?
If I understand inheritance right, the stuff that a parent class has will be passed on to the derived class, not the other way around...
SO, in that sense, I would say I'm creating something in the parent class (i.e. edit_menu_options_class), namely an array called "undo", and I'm passing it on to the class that inherits it, which is what will actually perform actions with that thing. At least, that's the way I thought of it...

And no, I haven't posted the code that will do that!

Originally Posted by Programmer_P

If I understand inheritance right, the stuff that a parent class has will be passed on to the derived class, not the other way around...

Yes, but the key is in exactly what is the "stuff". Appropriate use of inheritance is typically tied to polymorphism, in which case the "stuff" that is "passed on" is the interface, not the implementation (or at least not only the implementation).

Originally Posted by laserlight

Yes, but the key is in exactly what is the "stuff". Appropriate use of inheritance is typically tied to polymorphism, in which case the "stuff" that is "passed on" is the interface, not the implementation (or at least not only the implementation).

Well, I guess I need you to explain more clearly what you mean by "interface" and "implementation" (more so the latter than the former)...
When I think of "implementation", I think of something being used, or "implemented" for whatever purpose. SO, in that sense, I really don't see what's wrong with implementing something in a derived class that exists in the parent class, and that's really what I'm doing anyway.
In my mind, at least, the "undo" array/string will be declared in the parent class edit_menu_options_class, and then passed on to a derived class of that one, where it will actually be used, or "implemented".
As for the interface, I would say "Undo" would qualify as part of the "interface" of my program, since its supposed to be a visible option in the Edit menu, and something the user interacts with.

Originally Posted by Programmer_P

Because I'm lazy, and that stuff is complicated!

And using arrays has made your life so much simpler ...

Seriously, learn std::string. It takes about five minutes, and is far, far easier to use than raw arrays.

Originally Posted by Programmer_P

Well, I guess I need you to explain more clearly what you mean by "interface" and "implementation" (more so the latter than the former)...

Refer to Stroustrup's glossary:

interface - a set of declarations that defines how a part of a program can be accessed. The public members and the friends of a class defines that class' interface for other code to use. A class without data members defines a pure interface. The protected members provide an additional interface for use by members of derived classes. See also: abstract class.

Consequently, "implementation" refers to the code that is behind the interface, i.e., what makes the interface concretely usable.

Originally Posted by Programmer_P

When I think of "implementation", I think of something being used, or "implemented" for whatever purpose. SO, in that sense, I really don't see what's wrong with implementing something in a derived class that exists in the parent class, and that's really what I'm doing anyway.
In my mind, at least, the "undo" array/string will be declared in the parent class edit_menu_options_class, and then passed on to a derived class of that one, where it will actually be used, or "implemented".

To implement is not to use. (For example, did you implement the operating system that you are using?) To implement is to construct, to build, to turn the abstract into the concrete. Thus, you are not implementing the member variable in the derived class. You are directly making use of an inherited member variable.

Originally Posted by Programmer_P

As for the interface, I would say "Undo" would qualify as part of the "interface" of my program, since its supposed to be a visible option in the Edit menu, and something the user interacts with.

I am talking about the class' interface, not the user interface.

Let me put it as a series of questions: what are the member functions of edit_menu_class and edit_menu_options_class? Which of these member functions are virtual functions? Are any of these virtual functions pure virtual? Does edit_menu_options_class have a virtual destructor?