returning reference

This is a discussion on returning reference within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by medievalelks
Don't do it. Why do you want to return a reference to your private data? If ...

Don't do it. Why do you want to return a reference to your private data? If your object is really a POD, make it a struct.

I'd also revisit the design. If you have a bunch of classes passing around and operating on a data struct, you may want encapsulate that data in an object with real behavior.

Im a little confused about your post.. How else am I supposed to share the options across the different classes in my program? I thought this is the right approach towards that kind of problems in c++.

I think the design I mentioned is good because in case options change, I dont have to change the data in each class separetly (if each class holds the options it needs).

Im a little confused about your post.. How else am I supposed to shared the options across the different classes in my program? I thought this is the right approach towards that kind of problems in c++.

I think the design I mentioned is good because in case options change, I dont have to change the data in each class separetly (if each class holds the options it needs).

It's hard to tell without a more concrete example. What are these "options"? Are these program-wide settings that you are managing with the options class? If so, how are they initialized?

The way I've handled this is to create a singleton that manages all program settings, which are read from a text file and stored in a std::map. Clients of the class fetch object values by calling a getString() or getDouble() member function on the singleton, which returns the value of the setting or option.

It's hard to tell without a more concrete example. What are these "options"? Are these program-wide settings that you are managing with the options class? If so, how are they initialized?

The way I've handled this is to create a singleton that manages all program settings, which are read from a text file and stored in a std::map. Clients of the class fetch object values by calling a getString() or getDouble() member function on the singleton, which returns the value of the setting or option.

I dont like singleton design approach because I want to be more object oriented - to be able to have multi-session program (different options for same tasks).

I dont like singleton design approach because I want to be more object oriented - to be able to have multi-session program (different options for same tasks).

What is not OO about singletons?

Anyway, that solution is out since you want multiple instances of the options. In any event, I would hide options behind a queryable interface so you don't have multiple objects fiddling with what is essentially a POD. So instead of checking if options.FullScreen is true in different places, have them call OptionInterface.isFullscreen().

I like my own class member function interface better. It essentially makes it possible to use class members as PODs, yet they are object oriented in sense that you can wrap functionality in function calls. Essentially, it's like set/get.
I posted it on the 1st page.