hello group,

whats a good design for a loader of different grafic-files. have the
loader-class (fstream) and a texture-class (internal format/RGBA, always
the same). now i want different grafic-files (.bmp, .pcx, other very
simple gfx) loaded for the texture-class.

is there a "filter" design approach?
should i give some functor object for each gfx-format, that acts on the
pic-data?
is it best done via a class hirarchy?

thanks a lot & hand, chris

Chris Forone wrote:
> whats a good design for a loader of different grafic-files. have the
> loader-class (fstream) and a texture-class (internal format/RGBA, always
> the same). now i want different grafic-files (.bmp, .pcx, other very
> simple gfx) loaded for the texture-class.
>
> is there a "filter" design approach?

There probably is.

> should i give some functor object for each gfx-format, that acts on the
> pic-data?
> is it best done via a class hirarchy?

This looks like a good fit for the 'comp.software.patterns' or the
'comp.programming' newsgroup, or even 'comp.object'. I couldn't find
anything specific for C++ in your inquiry. Admittedly, you have the
word "functor" there, which is somewhat specific to the language feature
related to overloading of the operator(), but I don't yet see the point
of using operator() there. I can just as well be a member function
(method). I don't insist you post to those newsgroups, just consider it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov schrieb:
> Chris Forone wrote:
>> whats a good design for a loader of different grafic-files. have the
>> loader-class (fstream) and a texture-class (internal format/RGBA,
>> always the same). now i want different grafic-files (.bmp, .pcx, other
>> very simple gfx) loaded for the texture-class.
>>
>> is there a "filter" design approach?
>
> There probably is.
>
>> should i give some functor object for each gfx-format, that acts on
>> the pic-data?
>> is it best done via a class hirarchy?
>
> This looks like a good fit for the 'comp.software.patterns' or the
> 'comp.programming' newsgroup, or even 'comp.object'. I couldn't find
> anything specific for C++ in your inquiry. Admittedly, you have the
> word "functor" there, which is somewhat specific to the language feature
> related to overloading of the operator(), but I don't yet see the point
> of using operator() there. I can just as well be a member function
> (method). I don't insist you post to those newsgroups, just consider it.
>
> V

Thanx, chris