Compatible codes for both Visual Studio 2005 and gcc

Discussion in 'C++' started by Alexander Dong Back Kim, Sep 23, 2007.

  1. Dear all,

    I'm doing an experimental thing that the codes I wrote can be compiled
    by both VS2005 and gcc. I saw somewhere on the web that I can use
    compiler's pre-defined value something life "_cplusplus_" or
    "_win32_". My question is is there any way that I can make codes that
    can be compiled by the both beautiful compilers? Any comments or
    suggestions would be much appreciated.

    regards,
     
    Alexander Dong Back Kim, Sep 23, 2007
    #1
    1. Advertising

  2. * Alexander Dong Back Kim:
    >
    > I'm doing an experimental thing that the codes I wrote can be compiled
    > by both VS2005 and gcc. I saw somewhere on the web that I can use
    > compiler's pre-defined value something life "_cplusplus_" or
    > "_win32_". My question is is there any way that I can make codes that
    > can be compiled by the both beautiful compilers? Any comments or
    > suggestions would be much appreciated.


    Both compilers accept most of standard C++.

    In addition g++ and other Windows C++ compilers accept many Visual C++
    language extensions, and provide headers for most of the core Windows API.

    In practice there should therefore be no problem for beginner's
    programs. You can however run into problems if you try to use
    system-specific libraries that a particular compiler doesn't provide.
    E.g., AFAIK current MingW g++ doesn't provide an interface to Windows'
    GDI+ API, so if you try to use GDI+, you'll have to create some wrapper
    of your own -- but that's a Windows programming question, not C++.

    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, Sep 23, 2007
    #2
    1. Advertising

  3. Alexander Dong Back Kim

    Phlip Guest

    Alexander Dong Back Kim wrote:

    > I'm doing an experimental thing that the codes I wrote can be compiled
    > by both VS2005 and gcc. I saw somewhere on the web that I can use
    > compiler's pre-defined value something life "_cplusplus_" or
    > "_win32_". My question is is there any way that I can make codes that
    > can be compiled by the both beautiful compilers? Any comments or
    > suggestions would be much appreciated.


    I would do that by installing CygWin, to get a complete bash environment,
    with its GCC. Then I'd use UnitTest++ to write lots of unit tests, and I'd
    configure some scripts and Makefiles to compile and run all the tests each
    time I changed the code. I always configure these scripts to trigger
    automatically when I save the files in my editor. That reduces development
    to generally making a few edits, saving the files, waiting for a positive
    message in another window, and making more edits. All without mouse abuse,
    or leaving the editor, or manual testing.

    BTW this newsgroup is not qualified to discuss any of these things, beyond
    their trivial overview. Each has its own forums where you'll get the best
    answers.

    Then use #ifdef WIN32 to flag the compiler-specific stuff, but it's best to
    put that into separate libraries. That, plus the unit tests, help keep your
    code decoupled.

    --
    Phlip
    http://www.oreilly.com/catalog/9780596510657/
    "Test Driven Ajax (on Rails)"
    assert_xpath, assert_javascript, & assert_ajax
     
    Phlip, Sep 23, 2007
    #3
  4. Alexander Dong Back Kim

    James Kanze Guest

    On Sep 23, 7:16 pm, "Phlip" <> wrote:
    > Alexander Dong Back Kim wrote:


    > > I'm doing an experimental thing that the codes I wrote can be compiled
    > > by both VS2005 and gcc. I saw somewhere on the web that I can use
    > > compiler's pre-defined value something life "_cplusplus_" or
    > > "_win32_". My question is is there any way that I can make codes that
    > > can be compiled by the both beautiful compilers? Any comments or
    > > suggestions would be much appreciated.


    > I would do that by installing CygWin, to get a complete bash environment,
    > with its GCC.


    There are at least three "Unix-like" environments for Windows:
    CygWin, UWin and MSys. From experience, I'd avoid CygWin. MSys
    is probably the lightest weight, and the best solution for
    someone only using it for compatibility issues, UWin gives a
    more completely Unix look-and-feel, but doesn't integrate into
    Windows as well. And CygWin is just a disaster on all levels.

    But I'm not sure that that's the question (and if it was, it
    wouldn't really be relevant here). The question is how to write
    compatible C++, which will compile with both
    compilers---presumably VC++ under Windows, and g++ under Linux
    or Unix. The answer, of course, is to write standard C++, and
    to avoid the system specific API's, encapsulating them when you
    must use them.

    > Then I'd use UnitTest++ to write lots of unit tests, and I'd
    > configure some scripts and Makefiles to compile and run all
    > the tests each time I changed the code.


    That's a different problem. I certainly can't imagine anyone
    writing makefiles which didn't run the unit tests automatically
    before making the component visible to other components. But
    how to do this is more a problem of how to write portable
    makefiles. It's a problem which isn't really on topic here, but
    I might add that I've yet to find a solution, other than
    installing the same make (GNU make) everywhere.

    > I always configure these scripts to trigger automatically when
    > I save the files in my editor.


    You mean you can't save partially edits? I tend to save any
    time I've written two or three lines of code; long before I've
    gotten anything which will compile. (Save early, save often, as
    the man said.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Sep 23, 2007
    #4
  5. On Sep 24, 5:56 am, James Kanze <> wrote:
    > On Sep 23, 7:16 pm, "Phlip" <> wrote:
    >
    > > Alexander Dong Back Kim wrote:
    > > > I'm doing an experimental thing that the codes I wrote can be compiled
    > > > by both VS2005 and gcc. I saw somewhere on the web that I can use
    > > > compiler's pre-defined value something life "_cplusplus_" or
    > > > "_win32_". My question is is there any way that I can make codes that
    > > > can be compiled by the both beautiful compilers? Any comments or
    > > > suggestions would be much appreciated.

    > > I would do that by installing CygWin, to get a complete bash environment,
    > > with its GCC.

    >
    > There are at least three "Unix-like" environments for Windows:
    > CygWin, UWin and MSys. From experience, I'd avoid CygWin. MSys
    > is probably the lightest weight, and the best solution for
    > someone only using it for compatibility issues, UWin gives a
    > more completely Unix look-and-feel, but doesn't integrate into
    > Windows as well. And CygWin is just a disaster on all levels.
    >
    > But I'm not sure that that's the question (and if it was, it
    > wouldn't really be relevant here). The question is how to write
    > compatible C++, which will compile with both
    > compilers---presumably VC++ under Windows, and g++ under Linux
    > or Unix. The answer, of course, is to write standard C++, and
    > to avoid the system specific API's, encapsulating them when you
    > must use them.
    >
    > > Then I'd use UnitTest++ to write lots of unit tests, and I'd
    > > configure some scripts and Makefiles to compile and run all
    > > the tests each time I changed the code.

    >
    > That's a different problem. I certainly can't imagine anyone
    > writing makefiles which didn't run the unit tests automatically
    > before making the component visible to other components. But
    > how to do this is more a problem of how to write portable
    > makefiles. It's a problem which isn't really on topic here, but
    > I might add that I've yet to find a solution, other than
    > installing the same make (GNU make) everywhere.
    >
    > > I always configure these scripts to trigger automatically when
    > > I save the files in my editor.

    >
    > You mean you can't save partially edits? I tend to save any
    > time I've written two or three lines of code; long before I've
    > gotten anything which will compile. (Save early, save often, as
    > the man said.)
    >
    > --
    > James Kanze (GABI Software) email:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    Hi James,

    That was an excellent answer for me. Thanks. Although I haven't got
    the answer that I wanna hear, I realized something that my approach is
    meaningless. BTW, thanks for all responding my question =)

    Cheers,
     
    Alexander Dong Back Kim, Sep 23, 2007
    #5
  6. Alexander Dong Back Kim

    Phlip Guest

    James Kanze wrote:

    > > I always configure these scripts to trigger automatically when I save
    > > the files in my editor.


    > You mean you can't save partially edits? I tend to save any time I've
    > written two or three lines of code; long before I've gotten anything which
    > will compile. (Save early, save often, as the man said.)


    The goal is saving and testing as often as possible, and correctly
    predicting the result of each test run. I expect you could correctly predict
    a syntax error diagnostic if that's what's coming...

    (Nice long-term slow-burn discussion though... for various definitions of
    "nice";)

    --
    Phlip
     
    Phlip, Sep 24, 2007
    #6
  7. Alexander Dong Back Kim

    Ian Collins Guest

    James Kanze wrote:
    > On Sep 23, 7:16 pm, "Phlip" <> wrote:


    >> I always configure these scripts to trigger automatically when
    >> I save the files in my editor.

    >
    > You mean you can't save partially edits?


    That all depends on your definition of often...

    > I tend to save any
    > time I've written two or three lines of code; long before I've
    > gotten anything which will compile. (Save early, save often, as
    > the man said.)
    >

    Sound's like a M$ word users mantra :)

    --
    Ian Collins.
     
    Ian Collins, Sep 24, 2007
    #7
  8. Alexander Dong Back Kim

    James Kanze Guest

    On Sep 24, 3:59 am, "Phlip" <> wrote:
    > James Kanze wrote:
    > > > I always configure these scripts to trigger automatically when I save
    > > > the files in my editor.

    > > You mean you can't save partially edits? I tend to save any time I've
    > > written two or three lines of code; long before I've gotten anything which
    > > will compile. (Save early, save often, as the man said.)


    > The goal is saving and testing as often as possible, and
    > correctly predicting the result of each test run. I expect you
    > could correctly predict a syntax error diagnostic if that's
    > what's coming...


    The thought actually occurred to me after posting that you do
    know why your saving; e.g. whether you're saving just to be
    sure, or because you've finished some particular micro-step in
    the development process. And of course, it's not too difficult
    to just ignore the errors in the first case.

    It also occured to me that most modern editors take frequent
    snapshots, detect crashes, and offer the possibility of
    restoring from the last snapshot, so the "save early, save
    often" rule might be a bit outdated (but if you've programmed
    for any length of time on older systems, it does become an
    ingrained habit).

    And of course, the two editors I know (vim and emacs) both allow
    you to define new commands, so you could also define two "save"
    sequences, one which triggers the make, and one which doesn't.
    In fact, that's exactly how I work in vim: the command ":make"
    triggers the save with recompilation (and my makefiles do invoke
    the unit tests, unless I specifically invoke them with a target
    that doesn't), whereas ":w" doesn't---as I said above, because
    of extensive experience on unreliable systems, I tend to invoke
    ":w" every ten or fifteen keystrokes.

    And not really related to this thread, but... Since you seem to
    use unit tests even more intensively than I do, how do you
    handle the case where the full unit tests take minutes, or even
    hours? I have the case in some of my UTF-8 code, where for
    practical reasons related to the internal implementation, I want
    to hit at least one character in every block of 64 before
    releasing the code for other components to use. On one of the
    machines I use, this results in a unit test of several hours,
    and of course, in my personal iterations, internal to the
    component, I probably don't need to be this thorough: one
    character of each length would suffice, with a few added limit
    cases. So how do you handle a case like this? Because it's
    driving me up the wall.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Sep 24, 2007
    #8
  9. Alexander Dong Back Kim

    James Kanze Guest

    On Sep 24, 5:09 am, Ian Collins <> wrote:
    > James Kanze wrote:


    [...]
    > > I tend to save any
    > > time I've written two or three lines of code; long before I've
    > > gotten anything which will compile. (Save early, save often, as
    > > the man said.)


    > Sound's like a M$ word users mantra :)


    Never used MS Word. But vi or ed, on older Unix (version 7)...
    Not to mention the systems I worked on before Unix came around.
    And vi under MS-DOS.

    It's now become an automatism; every ten or fifteen keystrokes:
    ":w". Even though vim (and emacs) saves snapshots, which allow
    for semi-automatic recovery.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Sep 24, 2007
    #9
  10. Alexander Dong Back Kim

    Ian Collins Guest

    James Kanze wrote:
    >
    > And not really related to this thread, but... Since you seem to
    > use unit tests even more intensively than I do, how do you
    > handle the case where the full unit tests take minutes, or even
    > hours? I have the case in some of my UTF-8 code, where for
    > practical reasons related to the internal implementation, I want
    > to hit at least one character in every block of 64 before
    > releasing the code for other components to use. On one of the
    > machines I use, this results in a unit test of several hours,
    > and of course, in my personal iterations, internal to the
    > component, I probably don't need to be this thorough: one
    > character of each length would suffice, with a few added limit
    > cases. So how do you handle a case like this? Because it's
    > driving me up the wall.
    >

    TDD probably wouldn't result in unit tests that of that nature, that
    sounds more like a higher level test. TDD tests drive the design, so
    they tend to be short logic proving tests, stepping through a sequence
    of events.

    For example, I've just add an all modules failed flag to a system, to
    add this I used the following simple tests:

    testHaveAllRegisteredModulesFailedFalseWithNoModules();
    testHaveAllRegisteredModulesFailedFalseWithGoodModules();
    testHaveAllRegisteredModulesFailedFalseWithOneGoodAndOneBadModule();
    testHaveAllRegisteredModulesFailedTrueWithAllBadModules();

    The application has 1100 tests which run in about 50 seconds
    (unoptimised) on my machine. If the test time gets above 60 seconds, we
    profile and optimise.

    The test framework (CppUnit) makes it easy to run tests for one module,
    witch we usually do if we are only working in one area.

    --
    Ian Collins.
     
    Ian Collins, Sep 24, 2007
    #10
  11. Alexander Dong Back Kim

    James Kanze Guest

    On Sep 24, 11:31 am, Ian Collins <> wrote:
    > James Kanze wrote:


    > > And not really related to this thread, but... Since you seem to
    > > use unit tests even more intensively than I do, how do you
    > > handle the case where the full unit tests take minutes, or even
    > > hours? I have the case in some of my UTF-8 code, where for
    > > practical reasons related to the internal implementation, I want
    > > to hit at least one character in every block of 64 before
    > > releasing the code for other components to use. On one of the
    > > machines I use, this results in a unit test of several hours,
    > > and of course, in my personal iterations, internal to the
    > > component, I probably don't need to be this thorough: one
    > > character of each length would suffice, with a few added limit
    > > cases. So how do you handle a case like this? Because it's
    > > driving me up the wall.


    > TDD probably wouldn't result in unit tests that of that nature, that
    > sounds more like a higher level test.


    It's really rather irrelevant what TDD would result in, since I
    don't use it. I do use extensive unit tests, and I want them to
    be as complete as possible. Testing every Unicode value is
    perhaps a little too exhaustive, but the implementation works in
    blocks of 64 characters, and testing one in each block isn't
    that excessive. For unit tests which are only run when the
    component is exported (which shouldn't be that often). But it
    still takes too much time for the iterative phase of
    development.

    > TDD tests drive the design, so they tend to be short logic
    > proving tests, stepping through a sequence of events.


    If you're claiming that TDD uses incomplete tests, that doesn't
    address my issue. Of course, all tests are incomplete, in one
    way or another. (Although in this case, I almost could do
    exhaustive testing---there are only about a million possible
    inputs. But it would take too much time on most of the target
    platforms.)

    Perhaps a different question would be: what is the minimum test
    set which would give me a reasonable amount of assurance. The
    problem is expanding my SetOfCharacter class (see
    http://kanze.james.neuf.fr/doc/en/Text/html/index.html) to
    support UTF-8. Where the current version takes a char/unsigned
    char/int as argument, the new one has a template function taking
    two iterators and a function taking a special type UTF8Char,
    which encapsulates a single UTF8Char. In the current version, I
    check every bit in the resulting set. I'm currently doing this
    in the UTF-8 version as well, and that's what's expensive.

    (It would actually be interesting to see how TDD handles this
    sort of problem. The original "requirement" from the user is
    simple: do the same thing as the existing class, but handle
    UTF-8. Of course, that means that it doesn't do the same thing,
    so some refining is necessary. I came up with something which
    replaced e.g.:
    //! Adds a character to the set.
    //!
    //! \param ch
    //! The character to be added.
    //!
    //! \post
    //! <tt>contains( ch )</code>
    //
    -----------------------------------------------------------------------
    void add( char ch ) ;

    //! Adds a character to the set.
    //!
    //! \param ch
    //! The character to be added.
    //!
    //! \post
    //! <tt>contains( ch )</code>
    //
    -----------------------------------------------------------------------
    void add( unsigned char ch ) ;

    //! Adds a character to the set.
    //!
    //! \param ch
    //! The character to be added.
    //!
    //! \pre
    //! <tt>ch >= 0 && ch <= UCHAR_MAX</tt>
    //!
    //! \post
    //! <tt>contains( ch )</code>
    //
    -----------------------------------------------------------------------
    void add( int ch ) ;

    //! Adds all of the characters from a string to the set.
    //!
    //! \param s
    //! A string containing the characters to be added.
    //!
    //! \post
    //! \code
    //! for ( int i = 0 ; i < s.size() ; ++ i )
    //! contains( s[ i ] ) ;
    //! \endcode
    //
    -----------------------------------------------------------------------
    void add( std::string const& s ) ;

    //! Adds all of the characters in a sequence to the set.
    //!
    //! \param begin
    //! Begin iterator of the characters to be added.
    //!
    //! \param end
    //! End iterator of the characters to be added.
    //!
    //! \post
    //! \code
    //! while ( begin != end )
    //! contains( *begin ++ ) ;
    //! \endcode
    //
    -----------------------------------------------------------------------
    template< typename FwdIter >
    void add( FwdIter begin, FwdIter end ) ;

    //! Adds all of the characters in the domain from the set.
    //!
    //! \post
    //! For all <tt>ch</tt> in the domain:
    //! <tt>contains(&nbsp;ch&nbsp;)</tt>.
    //
    -----------------------------------------------------------------------
    void add() ;
    with:
    //! Adds one or more characters to the set.
    //!
    //! \param begin
    //! Iterator designating the first byte of the first
    //! character.
    //!
    //! \param end
    //! Iterator designating one past the last byte of the
    //! available characters.
    //!
    //! \param maxCharCount
    //! The maximum number of characters to be processed in
    //! the sequence. By default, this is <tt>INT_MAX</tt>
    //! (practically speaking: infinity), which means that the
    //! sequence will be processed completely, as a string.
    //! It is possible, however, to limit the number of
    //! characters processed; by specifying <tt>1</tt>, for
    //! example, the constructed set will consist only of the
    //! single character at the start of the sequence.
    //!
    //! \post
    //! For all characters <tt>ch</tt>: <tt>contains(ch)</tt>
    //! is <tt>true</tt> if <tt>ch</tt> is one of the first
    //! <tt>maxCharCount</tt> characters in the sequence.
    //
    -----------------------------------------------------------------------
    template< typename FwdIter >
    void add(
    FwdIter begin,
    FwdIter end,
    size_t maxCharCount =
    infinity ) ;
    void add( UTF8Char const& ch ) ;

    (You'll note that the second function isn't documented. It was
    originally meant to be private, used by the public function.
    But it turned out that it was generally useful, so I moved it up
    to public. It is, of course, where all of the actual behavior
    is situated, since I definitely don't want any real behavior,
    which might need corrections, in a template.)

    What kind of tests would you write that would generate design
    here? And what kind of tests are necessary to ensure that the
    results really are correct; i.e. that any character that was
    previously a member of the set is a member after this function,
    and that any character in the sequence which was passed in is
    also a member of the set after the function. And that any
    character which wasn't in either isn't in the results. An
    exhaustive test is, quite clearly, impossible. (There are
    roughly 2^1000000 different possible initial values for set, and
    the sequence passed as an argument is conceptually limited only
    by the size of the memory.) So what do you have to test to 1)
    define a design, and 2) be relatively sure that if the test
    passes, you haven't accidentally introduced any new errors?

    > For example, I've just add an all modules failed flag to a
    > system, to add this I used the following simple tests:


    > testHaveAllRegisteredModulesFailedFalseWithNoModules();
    > testHaveAllRegisteredModulesFailedFalseWithGoodModules();
    > testHaveAllRegisteredModulesFailedFalseWithOneGoodAndOneBadModule();
    > testHaveAllRegisteredModulesFailedTrueWithAllBadModules();


    > The application has 1100 tests which run in about 50 seconds
    > (unoptimised) on my machine. If the test time gets above 60
    > seconds, we profile and optimise.


    I've actually done some profiling, and have doubled the speed.
    On one of my machines, that meant that it went from six hours,
    to three. Obviously, I'm testing too much (and maybe not enough
    as well).

    > The test framework (CppUnit) makes it easy to run tests for
    > one module, witch we usually do if we are only working in one
    > area.


    This is a single, very low level module.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Sep 24, 2007
    #11
  12. On Sep 24, 11:42 pm, James Kanze <> wrote:
    > On Sep 24, 11:31 am, Ian Collins <> wrote:
    >
    >
    >
    > > James Kanze wrote:
    > > > And not really related to this thread, but... Since you seem to
    > > > use unit tests even more intensively than I do, how do you
    > > > handle the case where the full unit tests take minutes, or even
    > > > hours? I have the case in some of my UTF-8 code, where for
    > > > practical reasons related to the internal implementation, I want
    > > > to hit at least one character in every block of 64 before
    > > > releasing the code for other components to use. On one of the
    > > > machines I use, this results in a unit test of several hours,
    > > > and of course, in my personal iterations, internal to the
    > > > component, I probably don't need to be this thorough: one
    > > > character of each length would suffice, with a few added limit
    > > > cases. So how do you handle a case like this? Because it's
    > > > driving me up the wall.

    > > TDD probably wouldn't result in unit tests that of that nature, that
    > > sounds more like a higher level test.

    >
    > It's really rather irrelevant what TDD would result in, since I
    > don't use it. I do use extensive unit tests, and I want them to
    > be as complete as possible. Testing every Unicode value is
    > perhaps a little too exhaustive, but the implementation works in
    > blocks of 64 characters, and testing one in each block isn't
    > that excessive. For unit tests which are only run when the
    > component is exported (which shouldn't be that often). But it
    > still takes too much time for the iterative phase of
    > development.
    >
    > > TDD tests drive the design, so they tend to be short logic
    > > proving tests, stepping through a sequence of events.

    >
    > If you're claiming that TDD uses incomplete tests, that doesn't
    > address my issue. Of course, all tests are incomplete, in one
    > way or another. (Although in this case, I almost could do
    > exhaustive testing---there are only about a million possible
    > inputs. But it would take too much time on most of the target
    > platforms.)
    >
    > Perhaps a different question would be: what is the minimum test
    > set which would give me a reasonable amount of assurance. The
    > problem is expanding my SetOfCharacter class (seehttp://kanze.james.neuf.fr/doc/en/Text/html/index.html) to
    > support UTF-8. Where the current version takes a char/unsigned
    > char/int as argument, the new one has a template function taking
    > two iterators and a function taking a special type UTF8Char,
    > which encapsulates a single UTF8Char. In the current version, I
    > check every bit in the resulting set. I'm currently doing this
    > in the UTF-8 version as well, and that's what's expensive.
    >
    > (It would actually be interesting to see how TDD handles this
    > sort of problem. The original "requirement" from the user is
    > simple: do the same thing as the existing class, but handle
    > UTF-8. Of course, that means that it doesn't do the same thing,
    > so some refining is necessary. I came up with something which
    > replaced e.g.:
    > //! Adds a character to the set.
    > //!
    > //! \param ch
    > //! The character to be added.
    > //!
    > //! \post
    > //! <tt>contains( ch )</code>
    > //
    > -----------------------------------------------------------------------
    > void add( char ch ) ;
    >
    > //! Adds a character to the set.
    > //!
    > //! \param ch
    > //! The character to be added.
    > //!
    > //! \post
    > //! <tt>contains( ch )</code>
    > //
    > -----------------------------------------------------------------------
    > void add( unsigned char ch ) ;
    >
    > //! Adds a character to the set.
    > //!
    > //! \param ch
    > //! The character to be added.
    > //!
    > //! \pre
    > //! <tt>ch >= 0 && ch <= UCHAR_MAX</tt>
    > //!
    > //! \post
    > //! <tt>contains( ch )</code>
    > //
    > -----------------------------------------------------------------------
    > void add( int ch ) ;
    >
    > //! Adds all of the characters from a string to the set.
    > //!
    > //! \param s
    > //! A string containing the characters to be added.
    > //!
    > //! \post
    > //! \code
    > //! for ( int i = 0 ; i < s.size() ; ++ i )
    > //! contains( s[ i ] ) ;
    > //! \endcode
    > //
    > -----------------------------------------------------------------------
    > void add( std::string const& s ) ;
    >
    > //! Adds all of the characters in a sequence to the set.
    > //!
    > //! \param begin
    > //! Begin iterator of the characters to be added.
    > //!
    > //! \param end
    > //! End iterator of the characters to be added.
    > //!
    > //! \post
    > //! \code
    > //! while ( begin != end )
    > //! contains( *begin ++ ) ;
    > //! \endcode
    > //
    > -----------------------------------------------------------------------
    > template< typename FwdIter >
    > void add( FwdIter begin, FwdIter end ) ;
    >
    > //! Adds all of the characters in the domain from the set.
    > //!
    > //! \post
    > //! For all <tt>ch</tt> in the domain:
    > //! <tt>contains(&nbsp;ch&nbsp;)</tt>.
    > //
    > -----------------------------------------------------------------------
    > void add() ;
    > with:
    > //! Adds one or more characters to the set.
    > //!
    > //! \param begin
    > //! Iterator designating the first byte of the first
    > //! character.
    > //!
    > //! \param end
    > //! Iterator designating one past the last byte of the
    > //! available characters.
    > //!
    > //! \param maxCharCount
    > //! The maximum number of characters to be processed in
    > //! the sequence. By default, this is <tt>INT_MAX</tt>
    > //! (practically speaking: infinity), which means that the
    > //! sequence will be processed completely, as a string.
    > //! It is possible, however, to limit the number of
    > //! characters processed; by specifying <tt>1</tt>, for
    > //! example, the constructed set will consist only of the
    > //! single character at the start of the sequence.
    > //!
    > //! \post
    > //! For all characters <tt>ch</tt>: <tt>contains(ch)</tt>
    > //! is <tt>true</tt> if <tt>ch</tt> is one of the first
    > //! <tt>maxCharCount</tt> characters in the sequence.
    > //
    > -----------------------------------------------------------------------
    > template< typename FwdIter >
    > void add(
    > FwdIter begin,
    > FwdIter end,
    > size_t maxCharCount =
    > infinity ) ;
    > void add( UTF8Char const& ch ) ;
    >
    > (You'll note that the second function isn't documented. It was
    > originally meant to be private, used by the public function.
    > But it turned out that it was generally useful, so I moved it up
    > to public. It is, of course, where all of the actual behavior
    > is situated, since I definitely don't want any real behavior,
    > which might need corrections, in a template.)
    >
    > What kind of tests would you write that would generate design
    > here? And what kind of tests are necessary to ensure that the
    > results really are correct; i.e. that any character that was
    > previously a member of the set is a member after this function,
    > and that any character in the sequence which was passed in is
    > also a member of the set after the function. And that any
    > character which wasn't in either isn't in the results. An
    > exhaustive test is, quite clearly, impossible. (There are
    > roughly 2^1000000 different possible initial values for set, and
    > the sequence passed as an argument is conceptually limited only
    > by the size of the memory.) So what do you have to test to 1)
    > define a design, and 2) be relatively sure that if the test
    > passes, you haven't accidentally introduced any new errors?
    >
    > > For example, I've just add an all modules failed flag to a
    > > system, to add this I used the following simple tests:
    > > testHaveAllRegisteredModulesFailedFalseWithNoModules();
    > > testHaveAllRegisteredModulesFailedFalseWithGoodModules();
    > > testHaveAllRegisteredModulesFailedFalseWithOneGoodAndOneBadModule();
    > > testHaveAllRegisteredModulesFailedTrueWithAllBadModules();
    > > The application has 1100 tests which run in about 50 seconds
    > > (unoptimised) on my machine. If the test time gets above 60
    > > seconds, we profile and optimise.

    >
    > I've actually done some profiling, and have doubled the speed.
    > On one of my machines, that meant that it went from six hours,
    > to three. Obviously, I'm testing too much (and maybe not enough
    > as well).
    >
    > > The test framework (CppUnit) makes it easy to run tests for
    > > one module, witch we usually do if we are only working in one
    > > area.

    >
    > This is a single, very low level module.
    >
    > --
    > James Kanze (GABI Software) email:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    hum... I really don't get it =) what a world! too many wonderful
    expertises =)
     
    Alexander Dong Back Kim, Sep 24, 2007
    #12
  13. Alexander Dong Back Kim

    Ian Collins Guest

    James Kanze wrote:
    > On Sep 24, 11:31 am, Ian Collins <> wrote:
    >> James Kanze wrote:

    >
    >>> And not really related to this thread, but... Since you seem to
    >>> use unit tests even more intensively than I do, how do you
    >>> handle the case where the full unit tests take minutes, or even
    >>> hours? I have the case in some of my UTF-8 code, where for
    >>> practical reasons related to the internal implementation, I want
    >>> to hit at least one character in every block of 64 before
    >>> releasing the code for other components to use. On one of the
    >>> machines I use, this results in a unit test of several hours,
    >>> and of course, in my personal iterations, internal to the
    >>> component, I probably don't need to be this thorough: one
    >>> character of each length would suffice, with a few added limit
    >>> cases. So how do you handle a case like this? Because it's
    >>> driving me up the wall.

    >
    >> TDD probably wouldn't result in unit tests that of that nature, that
    >> sounds more like a higher level test.

    >
    > It's really rather irrelevant what TDD would result in, since I
    > don't use it. I do use extensive unit tests, and I want them to
    > be as complete as possible. Testing every Unicode value is
    > perhaps a little too exhaustive, but the implementation works in
    > blocks of 64 characters, and testing one in each block isn't
    > that excessive. For unit tests which are only run when the
    > component is exported (which shouldn't be that often). But it
    > still takes too much time for the iterative phase of
    > development.
    >

    Are you testing something that can fail more than once? If you
    deliberately break something, how many tests fail?

    It's difficult to comment without knowing your problem domain, but from
    my experience, TDD tests tend to be more concise than tests added after
    the fact.

    >> TDD tests drive the design, so they tend to be short logic
    >> proving tests, stepping through a sequence of events.

    >
    > If you're claiming that TDD uses incomplete tests, that doesn't
    > address my issue. Of course, all tests are incomplete, in one
    > way or another.


    Exactly. No one would claim that TDD tests are the be all and end all
    of testing. Anyone using TDD will also be using black box automated
    acceptance tests. TDD tests are written to drive the design and to
    verify the code still works as designed after each refactor.

    --
    Ian Collins.
     
    Ian Collins, Sep 24, 2007
    #13
    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. Thirumalai
    Replies:
    0
    Views:
    674
    Thirumalai
    May 22, 2006
  2. rockdale
    Replies:
    1
    Views:
    621
    Juan T. Llibre
    Aug 23, 2006
  3. Replies:
    2
    Views:
    2,839
    Malcolm
    Aug 20, 2005
  4. Nathan Sokalski
    Replies:
    1
    Views:
    978
    Alexey Smirnov
    Oct 12, 2008
  5. Replies:
    3
    Views:
    218
    Mike Brind
    Oct 16, 2007
Loading...

Share This Page