In article <9vira7$fle4f$1@ID-47792.news.dfncis.de>, Bo-Staffan Lankinen says...
>
>> Of course I could another layer,
>
>There are, for instance, situations when one can't afford to pay the price,
>both in executionspeed and memory footprint, of using an abstract interface.

That's not the only way to break up an oversized class.

>> What do you think?
>
>There are definately situations where fine-grined access control can improve
>the robustness of classes without imposing an unnecessary layer of
>abstraction, which will cost resources both in executionspeed and memory
>footprint. IMO, it violates the fundamental concept of C++, ie. that you
>don't pay for what you don't use, because one is forced to use polymorphism
>when one shouldn't have to.
>
>One could argue that the need of fine-grained access control is a sign of
>bad design, using bloated interfaces. Indeed it can be so but it doesn't
>have to be so and that's a big difference. In my current project, I've a
>concrete example of small classes, representing geometry ie.
>vertices,edges,patches and volumes, that suffer from not having fine-grained
>access control. Each geometry class of dimension N is related to the
>geometry classes with dimension N-1 and N+1, which means the private
>interface is split in three parts, one part for the implementation of the
>class and two parts for interfacing with classes of dimension N-1 and N+1.

That's one way to do what you want to do, with the risks you noted.
However, class<N> might have member classes up, down which befriend
class<N+1> and class <N-1>. These member classes wouldn't have data,
and only have private inline functions that access the part of class<N>
you want exposed to class<N+1> cq class <N-1>.
No objects of these member classes are ever created, and the inline
functions can be trivial forwarding functions. That won't cause
overhead.
This mechanism can be used to provide fine-grain access control at the
"expense" of naming these access methods. I think that's a benefit, not
a real expense.

HTH,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> That's one way to do what you want to do, with the risks you noted.
> However, class<N> might have member classes up, down which befriend
> class<N+1> and class <N-1>. These member classes wouldn't have data,
> and only have private inline functions that access the part of class<N>
> you want exposed to class<N+1> cq class <N-1>.
> No objects of these member classes are ever created, and the inline
> functions can be trivial forwarding functions. That won't cause
> overhead.
> This mechanism can be used to provide fine-grain access control at the
> "expense" of naming these access methods. I think that's a benefit, not
> a real expense.

No, that wouldn't solve the fundamental problem that one want to expose only
a subset of the private interface to another class. The up/down interfaces
still needs to be friend of both class<N> and class<N+1>, ie. it's possible
to inadvertly invoke the private implementation from the member interfaces.
The only safe way, as I see it, to prevent this, would be to create an
abstract interface, make that interface a friend of one of the classes and
let the other class derive from/override that interface.

Bo-Staffan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> That's one way to do what you want to do, with the risks you noted.
> However, class<N> might have member classes up, down which befriend
> class<N+1> and class <N-1>. These member classes wouldn't have data,
> and only have private inline functions that access the part of class<N>
> you want exposed to class<N+1> cq class <N-1>.
> No objects of these member classes are ever created, and the inline
> functions can be trivial forwarding functions. That won't cause
> overhead.
> This mechanism can be used to provide fine-grain access control at the
> "expense" of naming these access methods. I think that's a benefit, not
> a real expense.

Michiel,

Please disregard my previous reply as I now realize that your solution can
indeed give fine-grained access control without using an abstract interface.
Thank you.

Bo-Staffan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]