Is it ANSI or is it compiler dependent?

[Canonical Latin]

#include<iostre am>
int main() {
char buff[3];
std::cin.getlin e(buff,3);
std::cin.getlin e(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

[Leor Zolman]

On 8 May 2004 16:29:08 -0700, ja******@hotmai l.com (Canonical Latin) wrote:

#include<iostr eam>
int main() {
char buff[3];
std::cin.getlin e(buff,3);
std::cin.getlin e(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

[Canonical Latin]

"Leor Zolman" <le**@bdsoft.co m> wrote in message
news:ha******** *************** *********@4ax.c om...

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<iostre am>

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?

[Canonical Latin]

"Canonical Latin" <ja******@hotma il.com> wrote in message
news:7d******** *************** ***@posting.goo gle.com...

#include<iostre am>
int main() {
char buff[3];
std::cin.getlin e(buff,3);
std::cin.getlin e(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().

[Leor Zolman]

On Sun, 09 May 2004 15:04:59 GMT, "Canonical Latin" <ja******@hotma il.com>
wrote:

"Leor Zolman" <le**@bdsoft.co m> wrote in message
news:ha******* *************** **********@4ax. com...

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 inthe

Standard yet.
-leor

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

#include<iostr eam>

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

[Leor Zolman]

On Sun, 09 May 2004 16:22:00 GMT, "Canonical Latin" <ja******@hotma il.com>
wrote:

"Canonical Latin" <ja******@hotma il.com> wrote in message
news:7d******* *************** ****@posting.go ogle.com...

#include<iostre am>
int main() {
char buff[3];
std::cin.getlin e(buff,3);
std::cin.getlin e(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

[Canonical Latin]

"Leor Zolman" <le**@bdsoft.co m> wrote in message
news:94******** *************** *********@4ax.c om...

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

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

[none]

Canonical Latin wrote:> ...

#include<iostre am>

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

[Leor Zolman]

On Sun, 09 May 2004 21:21:58 GMT, "Canonical Latin" <ja******@hotma il.com>
wrote:

"Leor Zolman" <le**@bdsoft.co m> wrote in message
news:94******* *************** **********@4ax. com...

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

[Canonical Latin]

"Leor Zolman" <le**@bdsoft.co m> wrote in message
news:6d******** *************** *********@4ax.c om...

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.