pure virtual function with unspecified parameters?

Discussion in 'C++' started by Markus Dehmann, Nov 27, 2007.

  1. I have an abstract base class called Data. It has a pure virtual
    function

    virtual void write(std::eek:stream& out) =0;

    which writes the internal data to a stream. Now the problem is that
    this is not appropriate for some implementations of the class. Some
    implementations have an internal representation that they should
    rather write into several separate files. So for those, something like
    this would be more appropriate:

    void write(const std::string& outputDirectoryName);

    What would be a good design for the abstract base class in this case?
    It seems like it should require some kind of write function, but with
    flexible parameter lists for different implementations.

    Certainly we don't want to deal with void pointers:

    write(void* toWhatever) = 0;

    that the implementation classes would cast and use however they like
    because void pointers are evil.

    A template also doesn't work:

    template<class T>
    virtual void write(T& out) = 0;

    because you can't template a virtual function. And it would seem like
    overkill to template the whole class on this output parameter; after
    all it's just a little write function within a much larger class.

    What would be a good design in this case?

    Thanks!
    Markus
     
    Markus Dehmann, Nov 27, 2007
    #1
    1. Advertising

  2. Markus Dehmann wrote:
    > I have an abstract base class called Data. It has a pure virtual
    > function
    >
    > virtual void write(std::eek:stream& out) =0;
    >
    > which writes the internal data to a stream. Now the problem is that
    > this is not appropriate for some implementations of the class. Some
    > implementations have an internal representation that they should
    > rather write into several separate files. So for those, something like
    > this would be more appropriate:
    >
    > void write(const std::string& outputDirectoryName);
    >
    > What would be a good design for the abstract base class in this case?


    struct OutputDestBase { virtual ~OutputDestBase() {} };

    void write(OutputDestBase const& where) = 0;

    Now, make every class have its own corresponding member class that will
    derive from 'OutputDestBase' and have the contents known to the owning
    class alone, which will permit static_cast (or dynamic_cast if you prefer
    to have error-checking) to that derived member class before extracting
    any necessary information from it.

    > It seems like it should require some kind of write function, but with
    > flexible parameter lists for different implementations.
    >
    > Certainly we don't want to deal with void pointers:
    >
    > write(void* toWhatever) = 0;
    >
    > that the implementation classes would cast and use however they like
    > because void pointers are evil.
    >
    > A template also doesn't work:
    >
    > template<class T>
    > virtual void write(T& out) = 0;
    >
    > because you can't template a virtual function. And it would seem like
    > overkill to template the whole class on this output parameter; after
    > all it's just a little write function within a much larger class.
    >
    > What would be a good design in this case?


    You're close. Keep digging in the same direction.

    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, Nov 27, 2007
    #2
    1. Advertising

  3. * Markus Dehmann:
    > I have an abstract base class called Data. It has a pure virtual
    > function
    >
    > virtual void write(std::eek:stream& out) =0;
    >
    > which writes the internal data to a stream. Now the problem is that
    > this is not appropriate for some implementations of the class. Some
    > implementations have an internal representation that they should
    > rather write into several separate files. So for those, something like
    > this would be more appropriate:
    >
    > void write(const std::string& outputDirectoryName);
    >
    > What would be a good design for the abstract base class in this case?
    > It seems like it should require some kind of write function, but with
    > flexible parameter lists for different implementations.
    >
    > Certainly we don't want to deal with void pointers:
    >
    > write(void* toWhatever) = 0;
    >
    > that the implementation classes would cast and use however they like
    > because void pointers are evil.
    >
    > A template also doesn't work:
    >
    > template<class T>
    > virtual void write(T& out) = 0;
    >
    > because you can't template a virtual function. And it would seem like
    > overkill to template the whole class on this output parameter; after
    > all it's just a little write function within a much larger class.
    >
    > What would be a good design in this case?


    The point of std::eek:stream as an abstract streaming interface is to
    separate the data generation from the particulars of where that data
    ends up (if anywhere) -- file, http-connection, zip, memory buffer...

    So you have the right idea in the abstract Data class.

    Just provide more specific additional interfaces lower in the hierarchy,
    and implement the streaming-to-std::eek:stream as e.g. XML representation.

    If this is impossible, then you have a design error, derived classes
    that /are not/ substitutible for the abstract base class, and then you
    need to redesign (it does sound as if you have committed the grave sin
    of introducing an UBC, a Universal Base Class, the ultimate horror, oten
    reflected in meaningless names such as "Data" or "Manager" or "Object").

    Above all, think about the knowledge and responsibility distribution of
    the system: divide knowledge and responsibility in a clean manner.


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 27, 2007
    #3
  4. * Victor Bazarov:
    > Markus Dehmann wrote:
    >> I have an abstract base class called Data. It has a pure virtual
    >> function
    >>
    >> virtual void write(std::eek:stream& out) =0;
    >>
    >> which writes the internal data to a stream. Now the problem is that
    >> this is not appropriate for some implementations of the class. Some
    >> implementations have an internal representation that they should
    >> rather write into several separate files. So for those, something like
    >> this would be more appropriate:
    >>
    >> void write(const std::string& outputDirectoryName);
    >>
    >> What would be a good design for the abstract base class in this case?

    >
    > struct OutputDestBase { virtual ~OutputDestBase() {} };
    >
    > void write(OutputDestBase const& where) = 0;
    >
    > Now, make every class have its own corresponding member class that will
    > derive from 'OutputDestBase' and have the contents known to the owning
    > class alone, which will permit static_cast (or dynamic_cast if you prefer
    > to have error-checking) to that derived member class before extracting
    > any necessary information from it.


    Ouch.

    Necessity of casting, except for interfacing to low level C style code,
    is generally symptomatic of bad design.


    [snip]
    > You're close. Keep digging in the same direction.


    Separation of concerns is a good design guideline, but the current
    direction is opposite.

    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 27, 2007
    #4
  5. On Nov 27, 10:55 am, Markus Dehmann <> wrote:
    > I have an abstract base class called Data. It has a pure virtual
    > function
    >
    > virtual void write(std::eek:stream& out) =0;
    >
    > which writes the internal data to a stream. Now the problem is that
    > this is not appropriate for some implementations of the class. Some
    > implementations have an internal representation that they should
    > rather write into several separate files. So for those, something like
    > this would be more appropriate:
    >
    > void write(const std::string& outputDirectoryName);
    >
    > What would be a good design for the abstract base class in this case?
    > It seems like it should require some kind of write function, but with
    > flexible parameter lists for different implementations.
    >
    > Certainly we don't want to deal with void pointers:
    >
    > write(void* toWhatever) = 0;
    >
    > that the implementation classes would cast and use however they like
    > because void pointers are evil.
    >
    > A template also doesn't work:
    >
    > template<class T>
    > virtual void write(T& out) = 0;
    >
    > because you can't template a virtual function. And it would seem like
    > overkill to template the whole class on this output parameter; after
    > all it's just a little write function within a much larger class.
    >
    > What would be a good design in this case?


    Thanks for all your answers and the lateness of this reply.

    After reading up on Design Patterns, it seems to me that the Visitor
    pattern would fit perfectly here and solve my problem. You all were
    concerned about separation of responsibilities. So, just adding a

    void accept(const Visitor& v){
    v.visit(this);
    }

    should be fine and keep the class small. Then, different
    implementations can define their own WriteVisitor version, like this:

    class WriteVisitor : public Visitor {
    void visit(const MyData& d){
    // write by calling the appropriate functions specific to MyData
    }
    };

    Markus

    P.S.: Before getting the Visitor idea, I "solved" the problem by just
    adding a

    void write(const std::string& name);

    function. Some implementations can write to a stream (e.g. to cout if
    name=="-"), others can write to a directory of that name, etc.
     
    Markus Dehmann, Dec 7, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. IK
    Replies:
    2
    Views:
    639
    hemraj
    Jul 23, 2004
  2. Alex

    pure virtual parameters

    Alex, Jul 14, 2005, in forum: C++
    Replies:
    3
    Views:
    422
    Phlip
    Jul 14, 2005
  3. John Goche
    Replies:
    10
    Views:
    797
    Marcus Kwok
    Dec 8, 2006
  4. Replies:
    7
    Views:
    613
    James Kanze
    May 2, 2007
  5. a
    Replies:
    7
    Views:
    383
    dasjotre
    Jun 28, 2007
Loading...

Share This Page