On 2016-06-01 07:10, Emil Dotchevski wrote:
... header:
struct foo { int critical_; }; shared_ptr<foo> create_foo(); inline void use_foo_critical( foo * p ) { ++p->critical_; } void use_foo_not_so_critical( foo * );
cpp:
namespace { struct foo_: foo { int not_so_critiral_; }; }
shared_ptr<foo> create_foo() { return shared_ptr<foo>(new foo_); }
void use_foo_not_so_critical( foo * p ) { foo_ * q=static_cast<foo_ *>(p); ++q->not_so_critical_; } ...
Hmm, we probably need to adjust your example (admittedly written in a hurry) -- "foo" needs to be virtual (given we wanted efficiency), static_cast kills all C++ advances in type-safety... So, probably it should better be struct foo_; struct foo { int critical_; shared_ptr<foo_>; }; shared_ptr<foo> create_foo(); Then, when you throw in access restrictions (public/private) as Robert mentioned, those free functions need to be declared friends -- a fix due to initial "design simplification" -- violation of the association between data and behavior. ... And that's where the free-function-based API approach unfortunately seems to begin to start faltering as the beauty of simplicity is gradually fading away. Please do not take it as a criticism. I am just thinking aloud to see how far your approach can take us (how "scalable" it is :-)) and I hope you'll correct me if I veer in the wrong direction.