Question

I have a bunch of classes in a CUDA project that are mostly glorified structs and are dependent on each other by composition:

class A {
    public:
        typedef boost::shared_ptr<A> Ptr;
        A(uint n_elements) { ... // allocate element_indices };
        DeviceVector<int>::iterator get_element_indices();
    private:
        DeviceVector<int> element_indices;
}

class B {
    public:
        B(uint n_elements) { 
            ... // initialize members
        };
        A::Ptr get_a();
        DevicePointer<int>::iterator get_other_stuff();
    private:
        A::Ptr a;
        DeviceVector<int> other_stuff;
}

DeviceVector is just a wrapper around thrust::device_vectors and the ::iterator can be cast to a raw device pointer. This is needed, as custom kernels are called and require handles to device memory.

Now, I do care about encapsulation, but

• raw pointers to the data have to be exposed, so the classes using A and B can run custom kernels on the GPU
• a default constructor is not desired, device memory should be allocated automatically –> shared_ptr<T>
• only very few methods on A and B are required

So, one could make life much simpler by simply using structs

struct A {
    void initialize(uint n_elements);
    DeviceVector<int> element_indices;
}

struct B {
    void initialize(uint n_elements);
    A a;
    DeviceVector<int> other_stuff;
}

I’m wondering whether I’m correct that in the sense of encapsulation this is practically equivalent. If so, is there anything that is wrong with the whole concept and might bite at some point?

Answer 1

It’s a trade off.

Using value structs can be a beautifully simple way to group a bunch of data together. They can be very kludgy if you start tacking on a lot of helper routines and rely on them beyond their intended use. Be strict with yourself about when and how to use them and they are fine. Having zero methods on these objects is a good way to make this obvious to yourself.

You may have some set of classes that you use to solve a problem, I’ll call it a module. Having value structs within the module are easy to reason about. Outside of the module you have to hope for good behavior. You don’t have strict interfaces on them, so you have to hope the compiler will warn you about misuse.

Given that statement, I think they are more appropriate in anonymous or detail namespaces. If they end up in public interfaces, people tend to adding sugar to them. Delete the sugar or refactor it into a first class object with an interface.

I think they are more appropriate as const objects. The problem you fall into is that you are (trying to) maintain the invariance of this “object” everywhere that its used for its entire lifetime. If a different level of abstraction wants them with slight mutations, make a copy. The named parameter idiom is good for this.

Domain Driven Design gives thoughtful, thorough treatment on the subject. It characterizes it a more practical sense of how to understand and facilitate design.

Clean Code also discusses the topic, though from a different perspective. It is more of a morality book.

Both are awesome books and generally recommend outside of this topic.