Catching exceptions

Discussion in 'C++' started by magnus.moraberg@gmail.com, May 11, 2009.

  1. Guest

    Hi,

    I have the following incomplete code -

    File file;
    file.open(filePath);

    try
    {
    someOneElsesApi::startComplexProcessingOfFile(file);
    std::cout << "The file is now processed" << std::endl;
    }
    catch exception(/* all exceptions */)
    {
    std::cout << "The file didn't process because: " << std::endl;
    }

    startComplexProcessingOfFile() can throw a whole range of different
    exceptions.

    How do I catch them and inform the user in a useful manner. In python,
    there is a base exception class which can be used for this purpose. C#
    has inner exceptions which I also found quite useful.

    Thanks for your help,
    , May 11, 2009
    #1
    1. Advertising

  2. wrote:
    > Hi,
    >
    > I have the following incomplete code -
    >
    > File file;
    > file.open(filePath);
    >
    > try
    > {
    > someOneElsesApi::startComplexProcessingOfFile(file);
    > std::cout << "The file is now processed" << std::endl;
    > }
    > catch exception(/* all exceptions */)
    > {
    > std::cout << "The file didn't process because: " << std::endl;
    > }
    >
    > startComplexProcessingOfFile() can throw a whole range of different
    > exceptions.
    >
    > How do I catch them and inform the user in a useful manner. In python,
    > there is a base exception class which can be used for this purpose. C#
    > has inner exceptions which I also found quite useful.


    You can use:
    catch(...)
    but it will catch all exceptions, and you will not know which one is caught.

    It is better to create all catch cases, and act accordingly. After all,
    you should know which exceptions are thrown, and what can be done for each.

    Something like:

    try
    {
    f(); // throws an exception
    }
    catch ( const exception1 &e )
    {
    // do 1
    }
    catch ( const exception2 &e )
    {
    // do 2
    }
    catch ( ... )
    {
    // ?
    }
    Vladimir Jovic, May 11, 2009
    #2
    1. Advertising

  3. * :
    >
    > I have the following incomplete code -
    >
    > File file;
    > file.open(filePath);
    >
    > try
    > {
    > someOneElsesApi::startComplexProcessingOfFile(file);
    > std::cout << "The file is now processed" << std::endl;
    > }
    > catch exception(/* all exceptions */)
    > {
    > std::cout << "The file didn't process because: " << std::endl;
    > }
    >
    > startComplexProcessingOfFile() can throw a whole range of different
    > exceptions.
    >
    > How do I catch them and inform the user in a useful manner. In python,
    > there is a base exception class which can be used for this purpose. C#
    > has inner exceptions which I also found quite useful.


    If the exceptions are all derived from some base class T (e.g. std::exception),
    just do

    try
    {
    // Whatever.
    }
    catch( std::exception const& x )
    {
    std::cerr << "!" << x.what() << std::endl;
    }

    If the exceptions are of unrelated types then you can do

    try
    {
    // Whatever.
    }
    catch( ... )
    {
    std::cerr << "!" << exceptionText() << std::endl;
    }

    where exceptionText is a routine that you have defined tailored to the exception
    types you expect, e.g. like

    std::string exceptionText()
    {
    try
    {
    throw;
    }
    catch( A const& a )
    {
    return exceptionTextFrom( a );
    }
    catch( B const& b )
    {
    return exceptionTextFrom( b )
    }
    catch( C const& c )
    {
    return exceptionTextFrom( c );
    }
    catch( std::exception const& x )
    {
    return x.what();
    }
    catch( ... )
    {
    return "Uknown exception";
    }
    }

    where exceptionTextFrom might be a routine that you define, or just direct code
    to access the exception object's message.

    For anything but the smallest program it is however generally a bad idea to
    present the message carried by an exception to the user as a main message. It's
    probably not adapted to the context it appears in. It's probably about internal
    technical details that the user doesn't care about and doesn't have access to.
    It's probably expressed in a technical terminology/jargon that the user doesn't
    understand. It may even be in a national language that user doesn't understand.
    Exception information is generally for programmers (e.g. log it).

    Cheers & hth,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
    Alf P. Steinbach, May 11, 2009
    #3
  4. Jorgen Grahn Guest

    On Mon, 11 May 2009 01:52:15 -0700 (PDT), <> wrote:
    > Hi,
    >
    > I have the following incomplete code -
    >
    > File file;
    > file.open(filePath);
    >
    > try
    > {
    > someOneElsesApi::startComplexProcessingOfFile(file);
    > std::cout << "The file is now processed" << std::endl;


    Do you use std::endl here because you explicitly want flushing of cout
    at this point, or because you mistakenly think \n is not portable?

    > }
    > catch exception(/* all exceptions */)
    > {
    > std::cout << "The file didn't process because: " << std::endl;
    > }
    >
    > startComplexProcessingOfFile() can throw a whole range of different
    > exceptions.
    >
    > How do I catch them and inform the user in a useful manner. In python,
    > there is a base exception class which can be used for this purpose.


    Not really. As far as I know, Python is like C++; you can throw any
    object. And even if there *was* such an Exception class, you would
    want to catch IOError in this case, to be able to tell the user
    something meaningful like "failed because 'foo.txt' is read
    protected".

    Returning to C++ ... if someOneElsesApi::startComplexProcessingOfFile()
    can throw "a whole range of different exceptions" and you have to care
    about more than two or three of them, I'd argue that it is broken.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, May 11, 2009
    #4
  5. James Kanze Guest

    On May 11, 10:43 pm, Jorgen Grahn <> wrote:
    > On Mon, 11 May 2009 01:52:15 -0700 (PDT),
    > <> wrote:


    > > I have the following incomplete code -


    > > File file;
    > > file.open(filePath);


    > > try
    > > {
    > > someOneElsesApi::startComplexProcessingOfFile(file);
    > > std::cout << "The file is now processed" << std::endl;


    > Do you use std::endl here because you explicitly want flushing
    > of cout at this point, or because you mistakenly think \n is
    > not portable?


    Or most likely, because it is the standard way of terminating a
    line. (Standard in the sense of "usual or default practice".)
    At least from what he's posted, there's no reason to assume that
    the flush is causing a performance problem, so there's no reason
    to not use std::endl.

    --
    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, May 12, 2009
    #5
  6. * James Kanze:
    > On May 11, 10:43 pm, Jorgen Grahn <> wrote:
    >> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
    >> <> wrote:

    >
    >>> I have the following incomplete code -

    >
    >>> File file;
    >>> file.open(filePath);

    >
    >>> try
    >>> {
    >>> someOneElsesApi::startComplexProcessingOfFile(file);
    >>> std::cout << "The file is now processed" << std::endl;

    >
    >> Do you use std::endl here because you explicitly want flushing
    >> of cout at this point, or because you mistakenly think \n is
    >> not portable?

    >
    > Or most likely, because it is the standard way of terminating a
    > line. (Standard in the sense of "usual or default practice".)
    > At least from what he's posted, there's no reason to assume that
    > the flush is causing a performance problem, so there's no reason
    > to not use std::endl.


    It's also debatable whether

    #include <iostream>
    int main() { std::cout << "Bah\n"; }

    is guaranteed to produce any output at all.

    I don't know (though I suspect answer is "no") and don't care, but anyone
    recommending not using endl and criticizing others for using it should know and
    be able to back it up with some quote from the standard.


    Cheers,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
    Alf P. Steinbach, May 12, 2009
    #6
  7. Jerry Coffin Guest

    In article <guban1$ci9$>, says...

    [ ... ]

    > It's also debatable whether
    >
    > #include <iostream>
    > int main() { std::cout << "Bah\n"; }
    >
    > is guaranteed to produce any output at all.
    >
    > I don't know (though I suspect answer is "no") and don't care, but anyone
    > recommending not using endl and criticizing others for using it should know and
    > be able to back it up with some quote from the standard.


    I don't see how there's any room for debate at all. See [lib.ios::Init]
    (27.4.2.1.6). std::ios_base::Init is a class that (acts like it) keeps a
    reference count to ensure that cin, cout, cerr, and clog (and wide
    variants) are created once in a program that uses them, and flushed
    before the program exits.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, May 12, 2009
    #7
  8. * Jerry Coffin:
    > In article <guban1$ci9$>, says...
    >
    > [ ... ]
    >
    >> It's also debatable whether
    >>
    >> #include <iostream>
    >> int main() { std::cout << "Bah\n"; }
    >>
    >> is guaranteed to produce any output at all.
    >>
    >> I don't know (though I suspect answer is "no") and don't care, but anyone
    >> recommending not using endl and criticizing others for using it should know and
    >> be able to back it up with some quote from the standard.

    >
    > I don't see how there's any room for debate at all. See [lib.ios::Init]
    > (27.4.2.1.6). std::ios_base::Init is a class that (acts like it) keeps a
    > reference count to ensure that cin, cout, cerr, and clog (and wide
    > variants) are created once in a program that uses them, and flushed
    > before the program exits.


    Of course, you can provide a quote or reference to the place the standard
    guarantees the creation of at least one such object?

    And, what about e.g. an ofstream?


    Cheers & hth.,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
    Alf P. Steinbach, May 12, 2009
    #8
  9. Jerry Coffin Guest

    In article <guc9qa$5mg$>, says...

    [ ... ]

    > Of course, you can provide a quote or reference to the place the standard
    > guarantees the creation of at least one such object?


    Sort of, in 27.3/2. That's what actually creates cin, cout, etc. -- so
    without it, the problem isn't going to be lack of output from the
    program -- it's going to be extra output from the linker saying your
    program has undefined externals, and then you'll get no executable at
    all.

    > And, what about e.g. an ofstream?


    What about it? Do you mean: "Is all output that has been written to an
    fstream required to be written to the external file?" If so, the answer
    is basically yes. ~std::basic_filebuf() calls close() (§27.8.1.2/3).
    Close flushes the output by calling overflow(EOF) if a put area exists
    (§27.8.1.3/6). Of course, this assumes normal exit -- if the program
    exits via abort() (for one example) buffers aren't flushed.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, May 12, 2009
    #9
  10. James Kanze Guest

    On May 12, 10:04 am, "Alf P. Steinbach" <> wrote:
    > * James Kanze:
    > > On May 11, 10:43 pm, Jorgen Grahn <> wrote:
    > >> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
    > >> <> wrote:


    > >>> I have the following incomplete code -


    > >>> File file;
    > >>> file.open(filePath);


    > >>> try
    > >>> {
    > >>> someOneElsesApi::startComplexProcessingOfFile(file);
    > >>> std::cout << "The file is now processed" << std::endl;


    > >> Do you use std::endl here because you explicitly want flushing
    > >> of cout at this point, or because you mistakenly think \n is
    > >> not portable?


    > > Or most likely, because it is the standard way of terminating a
    > > line. (Standard in the sense of "usual or default practice".)
    > > At least from what he's posted, there's no reason to assume that
    > > the flush is causing a performance problem, so there's no reason
    > > to not use std::endl.


    > It's also debatable whether


    > #include <iostream>
    > int main() { std::cout << "Bah\n"; }


    > is guaranteed to produce any output at all.


    Since when? The standard guarantees that flush will be called
    on all of the standard stream objects during a clean shutdown.
    (There may be problems if you output to std::cout in the
    destructor of a static object. The stream is guaranteed not to
    be destructed, but you might have to manually ensure the flush
    to ensure that data is actually output.)

    Of course, one of my major arguments for using std::endl instead
    of '\n', by default, is that, like it or not, not all shutdowns
    are clean. And debugging is a lot easier if the output is
    actually indicative of how far the program has gotten.

    > I don't know (though I suspect answer is "no") and don't care,
    > but anyone recommending not using endl and criticizing others
    > for using it should know and be able to back it up with some
    > quote from the standard.


    It's more an engineering issue than a standards one. Basically,
    std::endl is the "standard" way of terminating a line (standard
    in the sense of "usual" or "accepted practice", not in the sense
    of ISO/IEC 14882); replacing it with '\n' is an optimization.
    Which shouldn't be undertaken prematurely.

    --
    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, May 13, 2009
    #10
  11. * Jerry Coffin:
    > In article <guc9qa$5mg$>, says...
    >
    > [ ... ]
    >
    >> Of course, you can provide a quote or reference to the place the standard
    >> guarantees the creation of at least one such object?

    >
    > Sort of, in 27.3/2.


    Thanks, I think that's the sought for guarantee as far as the in-practice is
    concerned, because it clearly demonstrates the intent.


    > That's what actually creates cin, cout, etc. -- so
    > without it, the problem isn't going to be lack of output from the
    > program -- it's going to be extra output from the linker saying your
    > program has undefined externals, and then you'll get no executable at
    > all.


    Sorry, no. There is an implication that placement new is used, since cout is a
    reference, so whether or not an Init object is ever created won't affect the
    things the linker sees. The question was more like whether the standard
    somewhere requires the use of the Init mechanism, and it seems 27.3/2 is it.


    >> And, what about e.g. an ofstream?

    >
    > What about it? Do you mean: "Is all output that has been written to an
    > fstream required to be written to the external file?" If so, the answer
    > is basically yes. ~std::basic_filebuf() calls close() (§27.8.1.2/3).
    > Close flushes the output by calling overflow(EOF) if a put area exists
    > (§27.8.1.3/6). Of course, this assumes normal exit -- if the program
    > exits via abort() (for one example) buffers aren't flushed.


    Thanks again. In summary, the relevant references are 27.3/2, 27.8.1.2/3 and
    27.8.1.3/6. And although the formal is a bit lacking, as a matter of practice it
    seems there's no danger from "\n" (instead of endl) for a normal execution.


    Cheers,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
    Alf P. Steinbach, May 13, 2009
    #11
  12. * James Kanze:
    > On May 12, 10:04 am, "Alf P. Steinbach" <> wrote:
    >> * James Kanze:
    >>> On May 11, 10:43 pm, Jorgen Grahn <> wrote:
    >>>> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
    >>>> <> wrote:

    >
    >>>>> I have the following incomplete code -

    >
    >>>>> File file;
    >>>>> file.open(filePath);

    >
    >>>>> try
    >>>>> {
    >>>>> someOneElsesApi::startComplexProcessingOfFile(file);
    >>>>> std::cout << "The file is now processed" << std::endl;

    >
    >>>> Do you use std::endl here because you explicitly want flushing
    >>>> of cout at this point, or because you mistakenly think \n is
    >>>> not portable?

    >
    >>> Or most likely, because it is the standard way of terminating a
    >>> line. (Standard in the sense of "usual or default practice".)
    >>> At least from what he's posted, there's no reason to assume that
    >>> the flush is causing a performance problem, so there's no reason
    >>> to not use std::endl.

    >
    >> It's also debatable whether

    >
    >> #include <iostream>
    >> int main() { std::cout << "Bah\n"; }

    >
    >> is guaranteed to produce any output at all.

    >
    > Since when?


    That would be late 1998. :)

    Before the standardization it was even worse.

    E.g. Scott Meyers discovered that the actual workings and guarantees about
    buffering, endl etc., in the draft standard, were so vague and counter intuitive
    that he had to omit an item about preferentially using "\n" in Effective C++.


    > The standard guarantees that flush will be called
    > on all of the standard stream objects during a clean shutdown.
    > (There may be problems if you output to std::cout in the
    > destructor of a static object. The stream is guaranteed not to
    > be destructed, but you might have to manually ensure the flush
    > to ensure that data is actually output.)


    I've yet to see that formal guarantee demonstrated.

    It seems that it's in the class of "the standard guarantees that <iostream> is
    enough to use cout, << etc." (oops, we forgot to actually state that!), which
    you helped to have fixed in C++0x.

    However, else-thread Jerry refers to 27.3/2, and as a matter of practicality to
    me that is convincing enough about the standard's authors' *intention*, namely
    that the standard is intended to require initialization of the standard iostream
    objects via the basic_ios::Init mechanism, which in turn provides flushing
    guarantees.


    > Of course, one of my major arguments for using std::endl instead
    > of '\n', by default, is that, like it or not, not all shutdowns
    > are clean. And debugging is a lot easier if the output is
    > actually indicative of how far the program has gotten.
    >
    >> I don't know (though I suspect answer is "no") and don't care,
    >> but anyone recommending not using endl and criticizing others
    >> for using it should know and be able to back it up with some
    >> quote from the standard.

    >
    > It's more an engineering issue than a standards one. Basically,
    > std::endl is the "standard" way of terminating a line (standard
    > in the sense of "usual" or "accepted practice", not in the sense
    > of ISO/IEC 14882); replacing it with '\n' is an optimization.
    > Which shouldn't be undertaken prematurely.


    I agree with this. :)


    Cheers,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
    Alf P. Steinbach, May 13, 2009
    #12
  13. Jerry Coffin Guest

    In article <gue8rq$lb9$>, says...
    > * Jerry Coffin:
    > > In article <guc9qa$5mg$>, says...
    > >
    > > [ ... ]
    > >
    > >> Of course, you can provide a quote or reference to the place the standard
    > >> guarantees the creation of at least one such object?

    > >
    > > Sort of, in 27.3/2.

    >
    > Thanks, I think that's the sought for guarantee as far as the in-practice is
    > concerned, because it clearly demonstrates the intent.


    Right -- AFAIK, there's nothing that says the implementation shall
    create an object of type std::ios_base::Init.

    [ ... ]

    > Thanks again. In summary, the relevant references are 27.3/2, 27.8.1.2/3 and
    > 27.8.1.3/6. And although the formal is a bit lacking, as a matter of practice it
    > seems there's no danger from "\n" (instead of endl) for a normal execution.


    Yes, I think that's a reasonable summary.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, May 13, 2009
    #13
  14. James Kanze Guest

    On May 13, 12:50 am, Jerry Coffin <> wrote:
    > In article <guc9qa$>, says...


    > [ ... ]


    > > Of course, you can provide a quote or reference to the place
    > > the standard guarantees the creation of at least one such
    > > object?


    > Sort of, in 27.3/2. That's what actually creates cin, cout,
    > etc. -- so without it, the problem isn't going to be lack of
    > output from the program -- it's going to be extra output from
    > the linker saying your program has undefined externals, and
    > then you'll get no executable at all.


    That's what triggers the construction of cin, cout, etc. It's
    not what defines the symbols.

    For various reasons, an implementation must do some sort of
    funny stuff with the standard stream objects: they can't be
    simply variables at namespace scope, with the given type, unless
    the implementation has some mechanism to ensure that they are
    constructed before (or during) the construction of the first
    ios_base::Init object, and that thy are the very last object to
    be destructed. Thus, g++ declares them as raw memory
    (char[ sizeof( ostream ) ], etc., using a compiler extension to
    ensure alignment); ios_base::Init uses placement new to
    construct them. (I suspect that this is probably the most
    widespread solution.)

    And if you try outputting before any ios_base::Init objects are
    constructed, you really do get undefined behavior. According to
    §27.3: "The objects are constructed and the associations are
    established at some time prior to or during the first time an
    object of class ios_base::Init is constructed, and in any case
    before the body of main begins execution." But Alf is right
    that there is no guarantee that any ios_base::Init objects are
    ever constructed, and thus, that the streams will ever be
    flushed. I'm sure this is a defect; I'll raise the issue in
    comp.std.c++.

    (In practice, all of the compilers I know ensure the
    construction before main by simply defining an instance of
    ios_base::Init somewhere in the library, where it will be
    constructed before main. Also, for a variety of historical
    reasons, all of the implementations I know define a static
    instance of ios_base::Init in <iostream>, so as soone as you
    include <iostream>, you've got an instance of ios_base::Init.)

    > > And, what about e.g. an ofstream?


    > What about it? Do you mean: "Is all output that has been
    > written to an fstream required to be written to the external
    > file?" If so, the answer is basically yes.
    > ~std::basic_filebuf() calls close() (§27.8.1.2/3). Close
    > flushes the output by calling overflow(EOF) if a put area
    > exists (§27.8.1.3/6). Of course, this assumes normal exit --
    > if the program exits via abort() (for one example) buffers
    > aren't flushed.


    Also, if you do something like:
    std::eek:stream* p = new std::eek:fstream( "filename" ) ;
    and never delete p, the buffers won't be flushed. Or if you do
    something like:

    int
    main()
    {
    std::eek:fstream out( "filename" ) ;
    // ...
    exit( 0 ) ;
    }

    In general, however, I would consider it an error to output to a
    file without explicitly closing it, then testing the error
    status, and reporting a write error somehow. For command line
    programs, the return status should be EXIT_FAILURE, or some
    implementation specific value which represents failure, in such
    cases, probably with an error message on cerr. For a GUI, I'd
    expect some sort of pop-up error message. For a server,
    whatever the server is supposed to do in case of a serious
    error---under Unix, syslog, and maybe an email to someone.

    --
    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, May 14, 2009
    #14
  15. James Kanze Guest

    On May 13, 12:54 pm, "Alf P. Steinbach" <> wrote:
    > * James Kanze:


    [...]
    > > The standard guarantees that flush will be called on all of
    > > the standard stream objects during a clean shutdown. (There
    > > may be problems if you output to std::cout in the destructor
    > > of a static object. The stream is guaranteed not to be
    > > destructed, but you might have to manually ensure the flush
    > > to ensure that data is actually output.)


    > I've yet to see that formal guarantee demonstrated.


    On rereading, I think you're right. The formal guarantee is
    only present if there is at least one instance of ios_base::Init
    is destructed. I'm pretty sure that this is a defect, however.

    In practice, every implementation I know defines a static
    instance of ios_base::Init in <iostream>. So any program which
    includes <iostream> will construct an instance of this object.
    This was required by the ULS specification of <iostream.h>, but
    somehow got lost when <iostream.h> got split into a number of
    different headers.

    > It seems that it's in the class of "the standard guarantees
    > that <iostream> is enough to use cout, << etc." (oops, we
    > forgot to actually state that!), which you helped to have
    > fixed in C++0x.


    (Actually, I don't think that it was the intent that <iostream>
    suffice for using cout, etc. But since that's what all
    implementations do, people have come to expect it.)

    Yes. C++0x also guarantees that if <iostream> is included, the
    standard objects will be constructed before any variables at
    namespace scope which follow the include. The usual way of
    achieving this is to declare a static instance of ios_base::Init
    in <iostream>, which would also guarantee the flush. But the
    standard doesn't require this.

    > However, else-thread Jerry refers to 27.3/2, and as a matter
    > of practicality to me that is convincing enough about the
    > standard's authors' *intention*, namely that the standard is
    > intended to require initialization of the standard iostream
    > objects via the basic_ios::Init mechanism, which in turn
    > provides flushing guarantees.


    I don't know what the actual intentions were, but I do know what
    implementations do today, and what users expect. Practically
    speaking, any implementation which doesn't do what is expected
    will be considered wrong by the users, regardless of what it
    can argue from the standard.

    (My proposal concerning <iostream>, for example, wasn't based on
    what the original intentions were, nor on what I thought they
    should be, but on what implementations actually do and users
    actually expect.)

    --
    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, May 14, 2009
    #15
    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. Marina
    Replies:
    2
    Views:
    464
    Marina
    Jul 8, 2003
  2. Amil Hanish
    Replies:
    0
    Views:
    536
    Amil Hanish
    Apr 13, 2006
  3. Adam Maass
    Replies:
    5
    Views:
    387
    Sudsy
    Jul 22, 2003
  4. Mike Schilling
    Replies:
    2
    Views:
    341
    Mike Schilling
    Jul 16, 2003
  5. Mick
    Replies:
    0
    Views:
    412
Loading...

Share This Page