Please coment solution (Was: Design problem...)

Discussion in 'C++' started by SpOiLeR, Feb 18, 2005.

  1. SpOiLeR

    SpOiLeR Guest

    > I have 4 different text file formats which basically
    > contain same data differently formated. I have class ParsedData which
    > handles data from this files. I also have 4 parses which can read from
    > files into ParsedData. Parsers should never be called explicitly (they
    > should only be called from ParsedData ctor). What is the best way to
    > protect those parsers?


    Well, If someone is still interested, this is what I did. Coments are
    welcome...

    Before, I've had something like this:

    class ParsedData
    {
    public:
    ParsedData (const FileInfo& f_in);
    // FileInfo is declared elsewhere and contains some data about
    // file to be parsed...
    ~ParsedData ();

    /* Set/Acess interface to data members */

    private:
    /* Few data members */
    FileInfo fi;

    void parser1 ();
    void parser_helper11 ();
    void parser_helper12 ();
    void parser_helper13 ();
    // ... Another 3 parsers similary declared
    };

    ParsedData::parsedData (const FileInfo& fi_in) : fi(fi_in)
    {
    if (condition1) parser1();
    else if (condition2) parser2();
    else if (condition3) parser3();
    else parser4 ();
    }

    Now I have this:

    class ParsedData {
    public:
    ParsedData (const FileInfo& f_in);
    ~ParsedData

    /* Set/Acess interface to data members */
    private:
    /* Few data members */
    FileInfo fi;
    };

    ParsedData::parsedData (const FileInfo& fi_in) : fi(fi_in), ...
    // Initialization of all ParsedData members
    {
    if (cond1) parser1 par(this);
    else if (cond2) parser2 par(this);
    else if (cond3) parser3 par(this);
    else parser4 par(this);

    par.read();
    }

    class BasicParser // Comon interace to all parsers
    {
    public:
    BasicParser (ParsedData *rv) : p(rv) {}
    virtual ~BasicParser ();

    int read ();
    int write ();

    private:
    ParsedData *p;
    };

    clas ParserOne : public BasicParser
    {
    ...

    Each ParserX recieves pointer to ParsedData object and imediatelly parses
    file into it. Info about path/file is included in ParsedData object...
    Also, all parsers are in subnamespace of ParsedData namespace. I achieved
    clearing up of ParsedData interface which was primarily my goal.
     
    SpOiLeR, Feb 18, 2005
    #1
    1. Advertising

  2. "SpOiLeR" <request@no_spam.org> wrote...
    >> I have 4 different text file formats which basically
    >> contain same data differently formated. I have class ParsedData which
    >> handles data from this files. I also have 4 parses which can read from
    >> files into ParsedData. Parsers should never be called explicitly (they
    >> should only be called from ParsedData ctor). What is the best way to
    >> protect those parsers?

    >
    > Well, If someone is still interested, this is what I did. Coments are
    > welcome...


    I don't want to spoil your triumph, yet a reply is in order.

    >
    > Before, I've had something like this:
    >
    > [...]
    > Now I have this:
    >
    > class ParsedData {
    > public:
    > ParsedData (const FileInfo& f_in);
    > ~ParsedData
    >
    > /* Set/Acess interface to data members */
    > private:
    > /* Few data members */
    > FileInfo fi;
    > };
    >
    > ParsedData::parsedData (const FileInfo& fi_in) : fi(fi_in), ...
    > // Initialization of all ParsedData members
    > {
    > if (cond1) parser1 par(this);
    > else if (cond2) parser2 par(this);
    > else if (cond3) parser3 par(this);
    > else parser4 par(this);
    >
    > par.read();


    Now, this is not C++. At least not the C++ I know. If you meant to
    initialise 'par' differently based on conditions, you still have to
    declare it _before_ the first 'if' so that it would be around after
    the last 'else'.

    > }
    >
    > class BasicParser // Comon interace to all parsers
    > {
    > public:
    > BasicParser (ParsedData *rv) : p(rv) {}
    > virtual ~BasicParser ();
    >
    > int read ();
    > int write ();


    Is there a reason why those are not virtual? If they are supposed to
    be virtual, shouldn't they also be pure?

    >
    > private:
    > ParsedData *p;
    > };
    >
    > clas ParserOne : public BasicParser
    > {
    > ...
    >
    > Each ParserX recieves pointer to ParsedData object and imediatelly parses
    > file into it. Info about path/file is included in ParsedData object...


    And so every parser (either by itself or through the BasicParser) has to
    know how to get to the inner ParsedData contents. So, to achieve that you
    need to either have them all declared "friends" (which was what you tried
    to avoid in the first place), or have extensive interface that ParsedData
    publishes, and _everybody_ is free to use [gasp!]...

    > Also, all parsers are in subnamespace of ParsedData namespace. I achieved
    > clearing up of ParsedData interface which was primarily my goal.


    Sounds good. The idea is that you should end up with a solution that
    works [for you]. I don't see a working solution as of yet, but I will
    gladly take your word for it.

    V
     
    Victor Bazarov, Feb 19, 2005
    #2
    1. Advertising

  3. SpOiLeR

    SpOiLeR Guest

    On Fri, 18 Feb 2005 19:48:04 -0500, Victor Bazarov wrote:
    >
    > I don't want to spoil your triumph, yet a reply is in order.
    >


    What triumph?

    >> {
    >> if (cond1) parser1 par(this);
    >> else if (cond2) parser2 par(this);
    >> else if (cond3) parser3 par(this);
    >> else parser4 par(this);
    >>
    >> par.read();

    >
    > Now, this is not C++. At least not the C++ I know. If you meant to
    > initialise 'par' differently based on conditions, you still have to
    > declare it _before_ the first 'if' so that it would be around after
    > the last 'else'.
    >

    True, I was giving simplified example, not the real code.

    >> class BasicParser // Comon interace to all parsers
    >> {
    >> public:
    >> BasicParser (ParsedData *rv) : p(rv) {}
    >> virtual ~BasicParser ();
    >>
    >> int read ();
    >> int write ();

    >
    > Is there a reason why those are not virtual? If they are supposed to
    > be virtual, shouldn't they also be pure?
    >


    The are both pure virtual (in fact there are four methods in interface of
    BasicParser and all four are pure virtuals). Again, this is not real code
    pasted form my IDE. I'm sorry for confusion.

    >> private:
    >> ParsedData *p;
    >> };
    >>
    >> clas ParserOne : public BasicParser
    >> {
    >> ...
    >>
    >> Each ParserX recieves pointer to ParsedData object and imediatelly parses
    >> file into it. Info about path/file is included in ParsedData object...

    >
    > And so every parser (either by itself or through the BasicParser) has to
    > know how to get to the inner ParsedData contents. So, to achieve that you
    > need to either have them all declared "friends" (which was what you tried
    > to avoid in the first place), or have extensive interface that ParsedData
    > publishes, and _everybody_ is free to use [gasp!]...
    >


    I did the friends part. This seemed safer and cleaner than big, messy
    interface to ParsedData. Any ideas of problems that can arise? I see none,
    that's why I asked for comments.

    >I don't see a working solution as of yet, but I will
    >gladly take your word for it.


    Are you beeing ironic?
     
    SpOiLeR, Feb 19, 2005
    #3
  4. "SpOiLeR" <request@no_spam.org> wrote...
    > On Fri, 18 Feb 2005 19:48:04 -0500, Victor Bazarov wrote:
    > [...]
    >>I don't see a working solution as of yet, but I will
    >>gladly take your word for it.

    >
    > Are you beeing ironic?


    A little. You wrote that you had a solution and you didn't
    even post "real code". That's why I said that I'd take your
    word for it. Whatever you posted didn't look like anything
    qualifying as "a solution".

    Never mind. Let's move on, shall we?
     
    Victor Bazarov, Feb 19, 2005
    #4
  5. SpOiLeR

    SpOiLeR Guest

    On Sat, 19 Feb 2005 12:32:37 -0500, Victor Bazarov wrote:

    > "SpOiLeR" <request@no_spam.org> wrote...
    >> On Fri, 18 Feb 2005 19:48:04 -0500, Victor Bazarov wrote:
    >> [...]
    >>>I don't see a working solution as of yet, but I will
    >>>gladly take your word for it.

    >>
    >> Are you beeing ironic?

    >
    > A little. You wrote that you had a solution and you didn't
    > even post "real code".


    Thought it would be easier to read if I post only important parts. Once
    more, sorry for confusion.

    > That's why I said that I'd take your
    > word for it. Whatever you posted didn't look like anything
    > qualifying as "a solution".
    >
    > Never mind. Let's move on, shall we?


    Sure... Thanks for your time...
     
    SpOiLeR, Feb 19, 2005
    #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. KK
    Replies:
    2
    Views:
    646
    Big Brian
    Oct 14, 2003
  2. Andrew Francis
    Replies:
    0
    Views:
    435
    Andrew Francis
    Jun 28, 2006
  3. =?Utf-8?B?Y2FzaGRlc2ttYWM=?=

    Solution file not in the solution folder

    =?Utf-8?B?Y2FzaGRlc2ttYWM=?=, Sep 12, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    1,127
    Laurent Bugnion
    Sep 12, 2006
  4. , India
    Replies:
    17
    Views:
    1,093
    James Kanze
    Oct 1, 2007
  5. Replies:
    8
    Views:
    523
Loading...

Share This Page