Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Is it ANSI or is it compiler dependent?

Reply
Thread Tools

Is it ANSI or is it compiler dependent?

 
 
Canonical Latin
Guest
Posts: n/a
 
      05-08-2004
#include<iostream>
int main() {
char buff[3];
std::cin.getline(buff,3);
std::cin.getline(buff,3);
std::cout << buff << endl;
}
Run at command prompt and input
1234567
what do you get as output?
Please include your compiler make/version in replies.

The question is: Does ANSI require that ios::failbit to be set after
the first getline() or is it compiler dependent? I expect the output
to be an empty line. I'm particularly interested in complilers that
output '34'.

Thanks in advance
 
Reply With Quote
 
 
 
 
Leor Zolman
Guest
Posts: n/a
 
      05-09-2004
On 8 May 2004 16:29:08 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (Canonical Latin) wrote:

>#include<iostream>
>int main() {
> char buff[3];
> std::cin.getline(buff,3);
> std::cin.getline(buff,3);
> std::cout << buff << endl;


std::cout << buff << std::endl;

>}
>Run at command prompt and input
>1234567
>what do you get as output?
>Please include your compiler make/version in replies.
>
>The question is: Does ANSI require that ios::failbit to be set after
>the first getline() or is it compiler dependent? I expect the output
>to be an empty line. I'm particularly interested in complilers that
>output '34'.
>
>Thanks in advance


Some data points for you:

Comeau/libcomo: 12
Comeau/Dinkumware: (empty line)
MSVC7.1: (empty line)
MSVC6: (empty line)
MSVC6/Dinkumware: (empty line)
CodeWarrior 8: (empty line)
Borland 5.5.1: (empty line)
Borland C++BuilderX: 12
gcc 3.3: (empty line)
Digital Mars: 12
Intel 7/8: (empty line)

I expected "12". Section 27.6.1.3/17 does say that failbit will be set if
the buffer fills up before the trailing delimiter is detected. The output
is consistently 12 if you take away the second getline call, so perhaps
this really boils down to how the different versions of getline behave if
they're called with failbit already set. I suspect they're not obliged to
do any particular thing then, but I haven't located evidence of that in the
Standard yet.
-leor








--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
 
 
 
Canonical Latin
Guest
Posts: n/a
 
      05-09-2004

"Leor Zolman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Some data points for you:
>
> Comeau/libcomo: 12
> Comeau/Dinkumware: (empty line)
> MSVC7.1: (empty line)
> MSVC6: (empty line)
> MSVC6/Dinkumware: (empty line)
> CodeWarrior 8: (empty line)
> Borland 5.5.1: (empty line)
> Borland C++BuilderX: 12
> gcc 3.3: (empty line)
> Digital Mars: 12
> Intel 7/8: (empty line)
>
> I expected "12". Section 27.6.1.3/17 does say that failbit will be set if
> the buffer fills up before the trailing delimiter is detected. The output
> is consistently 12 if you take away the second getline call, so perhaps
> this really boils down to how the different versions of getline behave if
> they're called with failbit already set. I suspect they're not obliged to
> do any particular thing then, but I haven't located evidence of that in

the
> Standard yet.
> -leor
>




Thank you. I know this must've come up before, but if you may solve another
mystery for me



#include<iostream>

void fun(int v[2]) {

std::cout << sizeof(v) << endl; // sizeof(int*) = But this v is not a
type!

}

int main() {

int v[3]={};

std::cout << sizeof(v) << '-'; // 3 * sizeof(int) = OK v is a type.

fun(v);

}



under gcc 3.2 on a 32 bit data/memory machine I get: 12-4

Why does this even compile? Does ANSI say that typed array arg's are to be
ignored?


 
Reply With Quote
 
Canonical Latin
Guest
Posts: n/a
 
      05-09-2004

"Canonical Latin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> #include<iostream>
> int main() {
> char buff[3];
> std::cin.getline(buff,3);
> std::cin.getline(buff,3);
> std::cout << buff << endl;
> }
> Run at command prompt and input
> 1234567
> what do you get as output?
> Please include your compiler make/version in replies.
>
> I expect the output to be an empty line.


The reason I think it is reasonable for buff[0]='\0' after the second
getline() is that then the character count is zero indicating that nothing
was read. This behavior is backward compatible with C getlen().


 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-09-2004
On Sun, 09 May 2004 15:04:59 GMT, "Canonical Latin" <(E-Mail Removed)>
wrote:

>
>"Leor Zolman" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>> Some data points for you:
>>
>> Comeau/libcomo: 12
>> Comeau/Dinkumware: (empty line)
>> MSVC7.1: (empty line)
>> MSVC6: (empty line)
>> MSVC6/Dinkumware: (empty line)
>> CodeWarrior 8: (empty line)
>> Borland 5.5.1: (empty line)
>> Borland C++BuilderX: 12
>> gcc 3.3: (empty line)
>> Digital Mars: 12
>> Intel 7/8: (empty line)
>>
>> I expected "12". Section 27.6.1.3/17 does say that failbit will be set if
>> the buffer fills up before the trailing delimiter is detected. The output
>> is consistently 12 if you take away the second getline call, so perhaps
>> this really boils down to how the different versions of getline behave if
>> they're called with failbit already set. I suspect they're not obliged to
>> do any particular thing then, but I haven't located evidence of that in

>the
>> Standard yet.
>> -leor
>>

>
>
>
>Thank you. I know this must've come up before, but if you may solve another
>mystery for me
>
>
>
>#include<iostream>
>
>void fun(int v[2]) {
>
> std::cout << sizeof(v) << endl; // sizeof(int*) = But this v is not a
>type!


First of all, it didn't compile, because again you neglected to put std::
in front of endl.

Once that's fixed...what do you mean when you say "v is not a type"? Of
course it isn't, it is the name of some data. Just as it is below in
main(). In both cases you're asking what the storage is of the object
referred to by the name "v". Above it is a pointer to int, as you've
indicated, and below it is an array of 3 ints. Recall there are two forms
of sizeof:
sizeof expression
sizeof (type)
(And it is OK to put the expression in parens, if you prefer, but it is not
OK to leave out the parens in the 2nd case). You've used the first form in
both cases.

If you still have a question, let us know...
-leor

>
>}
>
>int main() {
>
> int v[3]={};
>
> std::cout << sizeof(v) << '-'; // 3 * sizeof(int) = OK v is a type.
>
> fun(v);
>
>}
>
>
>
>under gcc 3.2 on a 32 bit data/memory machine I get: 12-4
>
>Why does this even compile? Does ANSI say that typed array arg's are to be
>ignored?



>


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-09-2004
On Sun, 09 May 2004 16:22:00 GMT, "Canonical Latin" <(E-Mail Removed)>
wrote:

>
>"Canonical Latin" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed). com...
>> #include<iostream>
>> int main() {
>> char buff[3];
>> std::cin.getline(buff,3);
>> std::cin.getline(buff,3);
>> std::cout << buff << endl;
>> }
>> Run at command prompt and input
>> 1234567
>> what do you get as output?
>> Please include your compiler make/version in replies.
>>
>> I expect the output to be an empty line.

>
>The reason I think it is reasonable for buff[0]='\0' after the second
>getline() is that then the character count is zero indicating that nothing
>was read. This behavior is backward compatible with C getlen().


Unfortunately (or fortunately, depending upon your point of view),
reasonability doesn't necessarily count for much. It seems just as
"reasonable" to me for getline to do absolutely nothing if failbit is
already set as it is for it to put a NUL into the first position of the
buffer. Well, in fact it actually seems a bit /more/ reasonable for it to
do nothing, for consistency with the way extractors don't alter their
operand if the stream is broken;
cin >> i; // doesn't alter i if it can't extract

BTW, what the heck is "C getlen()" ?
-leor

>


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
Canonical Latin
Guest
Posts: n/a
 
      05-09-2004

"Leor Zolman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> If you still have a question, let us know...
> -leor


LOL. A simple "I don't know" would have been shorter


 
Reply With Quote
 
none
Guest
Posts: n/a
 
      05-09-2004
Canonical Latin wrote:> ...
> #include<iostream>
>
> void fun(int v[2]) {
>
> std::cout << sizeof(v) << endl; // sizeof(int*)


Yes, it shall output size of 'int*', since declaration 'int v[2]' is
equivalent to 'int* v' in this context.
> But this v is not a type!


Huh? So what? 'sizeof' works with expressions just like it works with types.
> int main() {
>
> int v[3]={};
>
> std::cout << sizeof(v) << '-'; // 3 * sizeof(int)


As expected.
> OK v is a type.


No, 'v' is a name of an object of array type.
> fun(v);
>
> }
>
>
>
> under gcc 3.2 on a 32 bit data/memory machine I get: 12-4
>
> Why does this even compile?


Why shouldn't it compile?
> Does ANSI say that typed array arg's are to be
> ignored?


ANSI says that function parameters of array type are automatically
replaced with parameters of pointer type.
--
Best regards,
Andrey Tarasevich


 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-10-2004
On Sun, 09 May 2004 21:21:58 GMT, "Canonical Latin" <(E-Mail Removed)>
wrote:

>
>"Leor Zolman" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>> If you still have a question, let us know...
>> -leor

>
>LOL. A simple "I don't know" would have been shorter


I was in fact trying to answer the question. The way you used the word
"type", however, led me to believe I needed to clarify the distinction
between type and object in the context of using the sizeof operator. If
that in itself didn't answer your question, I was inviting you to rephrase
it so I could understand what you meant. In what way would "I don't know"
have been a better answer?
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
Canonical Latin
Guest
Posts: n/a
 
      05-10-2004

"Leor Zolman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> I was in fact trying to answer the question. The way you used the word
> "type", however, led me to believe I needed to clarify the distinction
> between type and object in the context of using the sizeof operator. If
> that in itself didn't answer your question, I was inviting you to rephrase
> it so I could understand what you meant.


Sorry. I had assumed the use of word 'type' was clear in the context of my
question. But here is a more carefully 'worded' version.

int v[3];
int w[3][3];

Granted that v is a variable with certain storage type. But v is also a
variable of type int[3] and w is a of type int[3][3].

void fun1(int v[2]) {}
void fun2(int v[2][3]) {}
void fun3(int v[2][2]) {}
int main() {
int v[3]={};
int w[3][3]={};
fun1(v);
fun2(w);
fun3(w);
}

It is a mystery to me why fun3(w) produces a compile error while the others
don't. For some reason the first dimension of an array is ignored when doing
type checking--as if v had the type int[] and w the type int[][3]. I used
sizeof operator to note that indeed v has the same storage requirement as
type int[2] in the main() which implies that at least here the compiler
acknowledges that v is indeed of type int[2] and not of type int[]. But then
later it treats it as int[] despite the specified type.

You can also check this by noting that fun(int v[3]) and fun(int v[4])
cannot be overloaded (since the compiler sees them as type int[]) but the
fun(int v[3][3]) and fun(int v[4][4]) can be overloaded.

I realize that you don't need the size of the first dimension of an array
for index computation while you need the rest. But surely this is a
different issue than type checking.



 
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
pre-ansi to ansi c++ conversion? Frank Iannarilli C++ 2 07-21-2009 11:05 PM
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C Programming 11 04-28-2008 03:00 AM
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C++ 1 04-24-2008 06:44 PM
Help with Constant Define--Compiler Issue with ANSI or my compiler or me? No Spam C Programming 7 01-04-2005 01:37 AM
Typed arrays (was: Is it ANSI or is it compiler dependent?) Canonical Latin C++ 19 05-12-2004 08:47 PM



Advertisments