Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Error with ifstream and exceptions

Reply
Thread Tools

Error with ifstream and exceptions

 
 
James Kanze
Guest
Posts: n/a
 
      02-09-2011
On Feb 8, 8:31 pm, Marco <(E-Mail Removed)> wrote:
> On 2011-02-08 James Kanze <(E-Mail Removed)> wrote:


[...]
> > But with regards to just writing "hello" to a file, it all
> > depends. Unix is very line oriented in its text handling,
> > and the editor I normally use (vim, both in Windows and in
> > Unix) is incapable of writing a file without a final
> > newline.


> I use vim, too. That vim isn't capable of writing text files
> without final newline makes me think of the reason. In general
> vim isn't wrong. Maybe a text file has to have a final newline
> by definition. But that's just a guess, I don't know.


Well, the reason vim can't do it is probably because vi
couldn't, and the reason vi couldn't is because it didn't
represent the end of line internally; the internal buffer was
a much older equivalent of std::vector<std::string>, with each
line in a separate string, without the newline (which was added
when writing the file).

The standard (C, but C++ defines its IO in terms of C) does say
that it is undefined behavior if the last character output to
a text file is not '\n'. But this wasn't specified until long
after vi was written.

--
James Kanze
 
Reply With Quote
 
 
 
 
Joe Greer
Guest
Posts: n/a
 
      02-09-2011
James Kanze <(E-Mail Removed)> wrote in
news:2f19a70f-712d-4d0a-af29-af9b2ed3ce62
@n16g2000prc.googlegroups.com:

>
> You didn't. Obviously, opinions as to when to use exceptions
> vary, but in fact, my response was very oriented to you, the
> context of your posting, and you're apparent programming

level
> in C++; Ian probably summed it up best with his response to

me:
> you don't use exceptions for a missing file unless the fact

that
> it is missing is somehow exceptional. (Which of course begs

the
> point as to what is exceptional, but in a short program which
> reads a more or less random file, the fact that the file

isn't
> there could hardly be considered exceptional.)


The rule of thumb I tend to use for exceptions isn't whether or
not they
are "exceptional" it's answering the question "Do I want stack
unwinding
here?" Sometimes the answer depends on where I expect to handle
the
error. In the case of things like file io, I almost always
want to
handle the at the caller, so file io tends to use a return
value and not
an exception. Now... That isn't to say that after I have
cleaned up the
current mess, I wouldn't turn around a throw an exception to
unwind my
way to a higher level. My point is that exceptions are good
for
triggering stack unwinding. If that isn't what you want, then
use a
return code of some sort.

joe
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      02-10-2011
On Feb 9, 6:26 pm, Joe Greer <(E-Mail Removed)> wrote:
> James Kanze <(E-Mail Removed)> wrote in
> news:2f19a70f-712d-4d0a-af29-af9b2ed3ce62
> @n16g2000prc.googlegroups.com:
> > You didn't. Obviously, opinions as to when to use
> > exceptions vary, but in fact, my response was very oriented
> > to you, the context of your posting, and you're apparent
> > programming level in C++; Ian probably summed it up best
> > with his response to me: you don't use exceptions for
> > a missing file unless the fact that it is missing is somehow
> > exceptional. (Which of course begs the point as to what is
> > exceptional, but in a short program which reads a more or
> > less random file, the fact that the file isn't there could
> > hardly be considered exceptional.)


> The rule of thumb I tend to use for exceptions isn't whether
> or not they are "exceptional" it's answering the question "Do
> I want stack unwinding here?" Sometimes the answer depends on
> where I expect to handle the error. In the case of things
> like file io, I almost always want to handle the at the
> caller, so file io tends to use a return value and not an
> exception. Now... That isn't to say that after I have cleaned
> up the current mess, I wouldn't turn around a throw an
> exception to unwind my way to a higher level. My point is
> that exceptions are good for triggering stack unwinding. If
> that isn't what you want, then use a return code of some sort.


Where the error is to be handled is probably a more precise
criteria than "exceptional". Generally, there are three
possible reasons for using exceptions:

-- the error can't possibly be handled locally; some stack
unwinding will be necessary,

-- you're in a constructor, and you don't want the object to
exist if the error occurs, and

-- you're in some sort of overloaded operator, where return
codes are impossible.

Any time one of these is true, you should use an exception.

--
James Kanze
 
Reply With Quote
 
Marco
Guest
Posts: n/a
 
      02-10-2011
On 2011-02-10 James Kanze <(E-Mail Removed)> wrote:

> Where the error is to be handled is probably a more precise
> criteria than "exceptional". Generally, there are three
> possible reasons for using exceptions:
>
> -- the error can't possibly be handled locally; some stack
> unwinding will be necessary,
>
> -- you're in a constructor, and you don't want the object to
> exist if the error occurs, and
>
> -- you're in some sort of overloaded operator, where return
> codes are impossible.
>
> Any time one of these is true, you should use an exception.


Thanks for the explanation.


Marco

 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      02-10-2011
Paul <(E-Mail Removed)> wrote:
> Why are they neither C++ not standard?
> This code is valid C++ and standard compliant C++ code:
>
> __try
> {
> // guarded body of code
> }
> __except (filter-expression)
> {
> // exception-handler block
> }
>
>
> The above code may be implementation specific but that does not mean it's
> not C++ code, as you have ridiculously stated.


You don't seem to understand what "standard" means. It's that document
they published in 1998 (and revised in 2003).

"Implementation specific" extension means by definition non-standard.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-10-2011

"Juha Nieminen" <(E-Mail Removed)> wrote in message
news:4d5425f6$0$2853$(E-Mail Removed)...
> Paul <(E-Mail Removed)> wrote:
>> Why are they neither C++ not standard?
>> This code is valid C++ and standard compliant C++ code:
>>
>> __try
>> {
>> // guarded body of code
>> }
>> __except (filter-expression)
>> {
>> // exception-handler block
>> }
>>
>>
>> The above code may be implementation specific but that does not mean it's
>> not C++ code, as you have ridiculously stated.

>
> You don't seem to understand what "standard" means. It's that document
> they published in 1998 (and revised in 2003).
>
> "Implementation specific" extension means by definition non-standard.
>

'That document' defines the language and to say something is non-standard
implies it does not not comply with the rules of the language, as defined in
the ISO document/s.

It does not make sense to say a piece of code is non standard, with your
inerpretation that 'standard' means that ISO document. This is like saying
'that code is not the ISO document'.

You can however say that code is not standard using the word 'standard' as
defined in the english language. Meaning something along the lines of 'it is
not of the norm'.

Additionally you say that *by definition* implementation specific code is
non standard well the standard I am looking at says:
"1.3.10 [defns.impl.defined]
implementation-defined behavior
behavior, for a well-formed program construct and correct data, that depends
on the implementation and
that each implementation documents"

Additionally the code itself *IS* standard code, it may invoke non standard
behaviour but the code complies with the rules of the ISO standard.

Lets say I make a function called myFunction. Are you saying this is non
standard because the behaviour is not defined in the ISO Document? In that
case almost all code is non standard in your mind, so what difference does
it make if it standard or non standard?







 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      02-11-2011
Paul <(E-Mail Removed)> wrote:
>> You don't seem to understand what "standard" means. It's that document
>> they published in 1998 (and revised in 2003).
>>
>> "Implementation specific" extension means by definition non-standard.
>>

> 'That document' defines the language and to say something is non-standard
> implies it does not not comply with the rules of the language, as defined in
> the ISO document/s.
>
> It does not make sense to say a piece of code is non standard, with your
> inerpretation that 'standard' means that ISO document. This is like saying
> 'that code is not the ISO document'.


"Non-standard" is basically a shortcut for "doesn't comply with the C++
standard", referring to the document. You are nitpicking about wording.

> You can however say that code is not standard using the word 'standard' as
> defined in the english language. Meaning something along the lines of 'it is
> not of the norm'.


No. When talking about C++ in particular, "non-standard" specifically
refers to not complying with the official standard document. "Norm" would
imply some kind of informal agreement or custom.

> Additionally you say that *by definition* implementation specific code is
> non standard


No. What I said is that an implementation-specific *extension* is by
definition non-standard. Clearly something like "__try {...}" is such
an extension (unless you have a #define macro earlier in the code that
would substitute it for something else).

> well the standard I am looking at says:
> "1.3.10 [defns.impl.defined]
> implementation-defined behavior
> behavior, for a well-formed program construct and correct data, that depends
> on the implementation and
> that each implementation documents"


Implementation-defined behavior and an implementation-specific extension
are two different things. "__try {...}" is clearly of the former type.
It's not something that the standard defines, but leaves the behavior up
to the compiler. (Unless you can show me where "__try" is defined in the
standard. I might have missed it.)

> Additionally the code itself *IS* standard code, it may invoke non standard
> behaviour but the code complies with the rules of the ISO standard.


It conforms to the standard only if you have a preprocessor macro that
substitutes "__try" and "__catch" with something valid. All by themselves
they aren't defined by the standard.

They might compile with some compiler, but that doesn't make them
standard. In that case they would be an implementation-specific extension.

> Lets say I make a function called myFunction. Are you saying this is non
> standard because the behaviour is not defined in the ISO Document?


The standard clearly defines function declarations and how they are
written. Does the standard define the "__try {...} __catch {...}"
syntax?

By your logic you could write Haskell inside a C++ function, and
if the compiler has an extension that understands and compiles it, that
makes it "standard".
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-11-2011

"Juha Nieminen" <(E-Mail Removed)> wrote in message
news:4d54eded$0$2855$(E-Mail Removed)...
> Paul <(E-Mail Removed)> wrote:
>>> You don't seem to understand what "standard" means. It's that document
>>> they published in 1998 (and revised in 2003).
>>>
>>> "Implementation specific" extension means by definition non-standard.
>>>

>> 'That document' defines the language and to say something is non-standard
>> implies it does not not comply with the rules of the language, as defined
>> in
>> the ISO document/s.
>>
>> It does not make sense to say a piece of code is non standard, with your
>> inerpretation that 'standard' means that ISO document. This is like
>> saying
>> 'that code is not the ISO document'.

>
> "Non-standard" is basically a shortcut for "doesn't comply with the C++
> standard", referring to the document. You are nitpicking about wording.
>
>> You can however say that code is not standard using the word 'standard'
>> as
>> defined in the english language. Meaning something along the lines of 'it
>> is
>> not of the norm'.

>
> No. When talking about C++ in particular, "non-standard" specifically
> refers to not complying with the official standard document. "Norm" would
> imply some kind of informal agreement or custom.
>
>> Additionally you say that *by definition* implementation specific code is
>> non standard

>
> No. What I said is that an implementation-specific *extension* is by
> definition non-standard. Clearly something like "__try {...}" is such
> an extension (unless you have a #define macro earlier in the code that
> would substitute it for something else).
>
>> well the standard I am looking at says:
>> "1.3.10 [defns.impl.defined]
>> implementation-defined behavior
>> behavior, for a well-formed program construct and correct data, that
>> depends
>> on the implementation and
>> that each implementation documents"

>
> Implementation-defined behavior and an implementation-specific extension
> are two different things. "__try {...}" is clearly of the former type.
> It's not something that the standard defines, but leaves the behavior up
> to the compiler. (Unless you can show me where "__try" is defined in the
> standard. I might have missed it.)
>


Where is your proof that the standard condemns this code as non C++?
I posted a quote that show the standard endorses this and you say that this
is not implementation defined behaviour , but implementation extensions.
What crap. If the standard said something negative about impl-def-behavior
you wouldn't be saying that.


>> Additionally the code itself *IS* standard code, it may invoke non
>> standard
>> behaviour but the code complies with the rules of the ISO standard.

>
> It conforms to the standard only if you have a preprocessor macro that
> substitutes "__try" and "__catch" with something valid. All by themselves
> they aren't defined by the standard.
>
> They might compile with some compiler, but that doesn't make them
> standard. In that case they would be an implementation-specific extension.
>

This is implementation defined behaviour and the standard endorses this.

If I have a random piece of steel pipe that is not specified in the ISO
standard for steel pipes. This does not mean that my pipe is not a piece of
steel pipe.
It is not a standard piece of pipe but it is nonetheless still a piece of
steel pipe.

Just becuase something is not standard does not automatically imply it is
sub-standard. And it certainly doesn't imply it is not what it is, in this
case the code is C++ code. You can't say this is not C++ code because it is
not defined in the standard.

>> Lets say I make a function called myFunction. Are you saying this is non
>> standard because the behaviour is not defined in the ISO Document?

>
> The standard clearly defines function declarations and how they are
> written. Does the standard define the "__try {...} __catch {...}"
> syntax?
>

The standard doesnt define it becuase it is implementaion defined. This
doesn't mean it is wrong or that it's not C++.


> By your logic you could write Haskell inside a C++ function, and
> if the compiler has an extension that understands and compiles it, that
> makes it "standard".


I'm not saying it is *standard* , I am quite clear that it is
implementation specific.
But so what if its not defined in the standard, this does not mean it is not
valid C++, and it certainly doesn't automatically imply it's sub-standard.

Your argument is that it is not defined in the C++ standard therefore it's
not C++. This is simply incorrect.
If this was the case there would be hundred of libraries and extensions in
the wild that were sub-standard, non-C++ code.




 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      02-11-2011
Paul <(E-Mail Removed)> wrote:
> Where is your proof that the standard condemns this code as non C++?


The standard doesn't need to go through every possible combination of
possible syntax errors and condemn them as "non C++".

If a syntax is not valid as defined by the standard, but still compiles,
it's by definition a non-standard extension in that specific compiler.

> I posted a quote that show the standard endorses this and you say that this
> is not implementation defined behaviour , but implementation extensions.
> What crap. If the standard said something negative about impl-def-behavior
> you wouldn't be saying that.


That paragraph makes no sense.

"Implementation-defined behavior" and "an implementation-speficic
extension" are two completely different and independent things. You
are committing a fallacy of equivocation.

For example, the value of "sizeof(int)" is implementation-defined.
"typeof(expression)" is an example of a compiler extension (in this case
a gcc extension). The former is standard-compliant, the latter isn't.

>> They might compile with some compiler, but that doesn't make them
>> standard. In that case they would be an implementation-specific extension.
>>

> This is implementation defined behaviour and the standard endorses this.


"Implementation-defined behavior" and "implementation-specific
extension" are two completely different things.

> I'm not saying it is *standard* , I am quite clear that it is
> implementation specific.


You are not saying it's standard, but when I say it's not standard,
you object. You are making no sense.

> But so what if its not defined in the standard, this does not mean it is not
> valid C++, and it certainly doesn't automatically imply it's sub-standard.


So your definition of "valid C++" is that if some compiler accepts it,
it's "valid C++".

I suppose that makes, for example, Objective-C "valid C++" because gcc
can compile Objective-C inside C++ source code.

Of course don't expect eg. Visual C++ to support a program written like
that, but hey, it's still "valid C++".

> Your argument is that it is not defined in the C++ standard therefore it's
> not C++. This is simply incorrect.
> If this was the case there would be hundred of libraries and extensions in
> the wild that were sub-standard, non-C++ code.


If a library conforms to the specification of the C++ standard, then it
is standard-compliant (but not part of the C++ standard).

A compiler extension is by definition non-standard.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-11-2011

"Juha Nieminen" <(E-Mail Removed)> wrote in message
news:4d5526a5$0$2836$(E-Mail Removed)...
> Paul <(E-Mail Removed)> wrote:
>> Where is your proof that the standard condemns this code as non C++?

>
> The standard doesn't need to go through every possible combination of
> possible syntax errors and condemn them as "non C++".
>
> If a syntax is not valid as defined by the standard, but still compiles,
> it's by definition a non-standard extension in that specific compiler.
>
>> I posted a quote that show the standard endorses this and you say that
>> this
>> is not implementation defined behaviour , but implementation extensions.
>> What crap. If the standard said something negative about
>> impl-def-behavior
>> you wouldn't be saying that.

>
> That paragraph makes no sense.
>
> "Implementation-defined behavior" and "an implementation-speficic
> extension" are two completely different and independent things. You
> are committing a fallacy of equivocation.
>
> For example, the value of "sizeof(int)" is implementation-defined.
> "typeof(expression)" is an example of a compiler extension (in this case
> a gcc extension). The former is standard-compliant, the latter isn't.
>
>>> They might compile with some compiler, but that doesn't make them
>>> standard. In that case they would be an implementation-specific
>>> extension.
>>>

>> This is implementation defined behaviour and the standard endorses this.

>
> "Implementation-defined behavior" and "implementation-specific
> extension" are two completely different things.
>
>> I'm not saying it is *standard* , I am quite clear that it is
>> implementation specific.

>
> You are not saying it's standard, but when I say it's not standard,
> you object. You are making no sense.
>


You loosely use the term non-standard to mean 2 different things:
1) Not defined in the C++ standard.
2) Not compliant with the C++ standard

If you want to get nitpicky about terms these 2 things do not mean the same.
You are being nitpicky about the term implementation specific yet use the
term non-standard very loosely to mean two different things. It is this
inconsistenty in your argument I object to.


>> But so what if its not defined in the standard, this does not mean it is
>> not
>> valid C++, and it certainly doesn't automatically imply it's
>> sub-standard.

>
> So your definition of "valid C++" is that if some compiler accepts it,
> it's "valid C++".
>

If its a well formed program that does not break the rules defined in the
standard why shouldn't it be valid C++?
Why should it be classified as invalid?

> I suppose that makes, for example, Objective-C "valid C++" because gcc
> can compile Objective-C inside C++ source code.
>
> Of course don't expect eg. Visual C++ to support a program written like
> that, but hey, it's still "valid C++".
>
>> Your argument is that it is not defined in the C++ standard therefore
>> it's
>> not C++. This is simply incorrect.
>> If this was the case there would be hundred of libraries and extensions
>> in
>> the wild that were sub-standard, non-C++ code.

>
> If a library conforms to the specification of the C++ standard, then it
> is standard-compliant (but not part of the C++ standard).
>
> A compiler extension is by definition non-standard.
>

You can say the same for an implementaion specific extension as you did for
a library:
If an IS-extension conforms to the specification then it is standard
compliant, but not part of the standard.

You were clear in the above example of a library but now what do you mean,
do you mean it is not-complaint with the standard or it is not-defined by
the standard?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Exceptions - How do you make it work like built-in exceptions? Lie Python 3 01-14-2008 06:45 PM
Exceptions + Performance on path without exceptions gratch06@gmail.com C++ 3 04-16-2007 08:52 PM
Checked exceptions vs unchecked exceptions Ahmed Moustafa Java 5 07-14-2004 01:46 PM
Custom exceptions -- inherit from exceptions.Exception? Paul Miller Python 3 11-12-2003 09:24 AM
error passing ifstream. why? Giulio C++ 2 06-24-2003 09:19 PM



Advertisments