Structures to Classes

[Albatross]

...it has been ten days since the last post on this thread.

I still think that there is a bit of redundancy in this whole situation.

-Albatross

[blackcoder41]

Don't think too much, the language is already design there's no way of changing it now. If you think it's redundant then choose your preferred style and stick with it. class or struct, typename or class.

[Galik]

The fact is that structs are identical to classes except the default access.

However, what I see is that people tend to use structs when they need an aggregate data type and classes for complex data objects.

What I mean is struct is often used to represent a record in exactly the same way it is used in C.

struct address
{
    std::string house;
    std::string line1;
    std::string line2;
    std::string city;
};

Whereas if functions were going to be added a class would have been used instead.

The OP may have been referring to the fact that using an open struct to access the member variables can be more efficient that going through access functions.

Although, for simple access functions, any overhead can, in reality, be optimised away.

So there is often a distinct difference in the way struct and class are used even though they are physically (almost) identical.

I personally do not use structs in this way for any speed advantage because I don't believe there is any/much.

However I think it is good to use struct for aggregate data when it doesn't not make sense to hide it behind a function interface.

[chrisname]

I agree with Galik. When writing C++, I use structs pretty much exactly as I do in C. In C++ I use classes like they were intended.

[moorecm]

I often use struct for functors just to save typing the line "public:". As for public members like a C struct, I have never once found a time where I thought that was a better idea than writing the proper encapsulation. It seems like a lazy way out to me...

[Galik]

@moorecm

Actually I think its a genuine concept with a rightful place in object orientation. Sometimes it makes sense to hide data, other times it does not.

Using struct the 'C' way is a natural extension of basic types. So as long as they are treated as basic types (rather than as lazy objects) they have their logical place.

I agree that you COULD use public access for laziness. But that's a different thing.

Here is an example:

class address
{
    std::string house;
    std::string line1;
    std::string line2;
    std::string city;
public:
    void set_house(const std::string& h) { house = h; }
    void set_line1(const std::string& l1) { line1 = l1; }
    void set_line2(const std::string& l2) { line2 = l2; }
    void set_city(const std::string& c) { city = c; }

    std::string get_house() const { return house; }
    std::string get_line1() const { return line2; }
    std::string get_line2() const { return line2; }
    std::string get_city() const { return city; }
};

In this example there is no processing required internally for an 'address'. It has no internal implementation state that needs to be hidden from the client programmer. If the member variable change then so will the function interface.

In these cases I don't feel it makes much sense to use redundant access functions.

Data hiding is important when the internal data is independent of the interface. But when the internal data and the interface are identical then I see no benefit in hiding the data behind the interface. Changing one will inevitable force a change in the other. So the benefits of data hiding are lost.

[helios]

I have never once found a time where I thought that was a better idea than writing the proper encapsulation. It seems like a lazy way out to me.

Oh, so you're that guy who's been writing all those useless getters and setters. Ah been waiting a looong time fer this day. Yer days are numbered.

[firedraco]

It's only important if you actually need to encapsulate the data...for example, std::pair does not have getters and setters.

[moorecm]

My claim is based on the fact that if you do not need to encapsulate the members [now], you might someday.

std::pair is a good counterexample, though. It's implementation is not going to change anytime soon.

[jsmith]

One reason for needing encapsulation is if you suddenly need to synchronize access to the members.

It's a tradeoff, really. Not writing accessors up front means potentially having to change the API later.
Writing them up front when they aren't strictly needed is just syntactic red tape. Pick your poison.

[S6k9GNh0]

Seriously, its 1) Better for abstraction, 2) better for future management, and 3) gives the developer more control about how the user uses his library.

[Disch]

+1 firedraco

The thing is getters and setters really don't make any sense sometimes. And putting in there just because "it's better encapsulation" is a bad move, IMO.

It's all about what's reasonable for the given situation.

[helios]

IMO, if you're going to encapsulate, then at least go all the way and just make classes with opaque pointers. There! Perfect encapsulation. All the user knows about the class comes through its interface. Otherwise, it's not about encapsulation but about data integrity.

[S6k9GNh0]

It's not just encapsulation for fuck sake. What if the developer didn't want you to set the variable? Without documentation, he could easy provide a GetVariable function and not a SetVariable function making it obviously inconvenient to change the variable for a reason. What if a variable's value is based on another variables? Well, he can do that through the abstract implementation without even bothering you and you can assume that it works without worry. What if you have the class setup to allow public access and then you realize you may need one of these conditions or something else that would be more convenient if the variable was accessed indirectly?

And why the hell does it matter? Most Set and Get functions give the same timing due to inlining and are just as convenient as public access. It does require the user to make sure he is allowed to change or fetch the variable though which I think should be done anyways. There is a reason why almost every C++ book brings this matter up in favor of the Set and Get functions.

[helios]

It's not just encapsulation for fuck sake.

Calm down.

What if the developer didn't want you to set the variable?

What if a variable's value is based on another variables?

That's data integrity.

[Albatross]

Aren't we going a bit far with this discussion? It seems to be going nowhere, it looks like it's on the brink of flames, and I don't see why we needed to revive it after 10 days of inactivity...

-Albatross