 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Thu Apr 27, 2006 5:06 pm Post subject: vc 6.0's bug????? |
 |
|
===================================== MODERATOR'S COMMENT:
I'm approving this for an odd reason. This question isn't quite
on-topic because it doesn't directly deal with the C++ standard,
but many of the possible answers to the question do directly
deal with the C++ standard. Let's make sure to keep followups
focused appropriately.
------=_Part_4136_31897272.1146154564994
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
approve<br>comment<br>I'm approving this for an odd reason. This question i=
sn't quite <br>on-topic because it doesn't directly deal with the C++ stand=
ard,<br>but many of the possible answers to the question do directly <br>
deal with the C++ standard. Let's make sure to keep followups <br>focused a=
ppropriately.<br>
------=_Part_4136_31897272.1146154564994--
===================================== END OF MODERATOR'S COMMENT
In vc 6.0:
#include <iostream>
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
why?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
loufoque
Guest
|
| Posted: Fri Apr 28, 2006 2:06 am Post subject: Re: vc 6.0's bug????? |
|
|
fisker0303 (AT) 126 (DOT) com wrote :
Be aware that Microsoft Visual Studio 6.0 is totally outdated and has
pretty bad support of Standard C++.
Yet, your problem isn't related to that fact at all : this is not a bug.
| Quote: | a = (a + b) - (b = a);
|
That line is undefined behaviour.
C++ doesn't specify in which order the operations should be done.
a could contain 20 if a+b is computed first and 10 if b=a is computed first.
| Quote: | Release output : a=20,b=10
Debug output: a=10,b=10
why?
|
When invoking undefined behaviour you shouldn't expect something well
defined.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Alf P. Steinbach
Guest
|
| Posted: Fri Apr 28, 2006 2:06 am Post subject: Re: vc 6.0's bug????? |
|
|
First, re moderation policy:
| Quote: | ===================================== MODERATOR'S COMMENT:
I'm approving this for an odd reason. This question isn't quite
on-topic because it doesn't directly deal with the C++ standard,
but many of the possible answers to the question do directly
deal with the C++ standard. Let's make sure to keep followups
focused appropriately.
------=_Part_4136_31897272.1146154564994
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
approve<br>comment<br>I'm approving this for an odd reason. This question i=
sn't quite <br>on-topic because it doesn't directly deal with the C++ stand=
ard,<br>but many of the possible answers to the question do directly <br
deal with the C++ standard. Let's make sure to keep followups <br>focused a=
ppropriately.<br
------=_Part_4136_31897272.1146154564994--
===================================== END OF MODERATOR'S COMMENT
|
I suggest that the group's FAQ and/or moderation guidelines should
include, in addition to the FAQ's current reference to RFC 1855:
* preferentially don't post with quoted printable encoding (QP is for
e-mail, not news),
* preferentially don't post HTML, and
* preferentially don't post multi-part messages.
But as evidently happened here, such settings can be applied by mistake,
or via too "helpful" software. Is it perhaps possible to automatically
detect & reject "Content-Type: text/html" and
"Content-Transfer-Encoding: quoted-printable"?
* fisker0303 (AT) 126 (DOT) com:
| Quote: | In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
why?
|
Why you get that output: C++ does not generally guarantee the evaluation
order of an expression (the built-in boolean operators are exceptions),
and so (as I see it) the expression has unspecified effect: either 'b=a'
is evaluated before 'a+b', or after, at the compiler's discretion.
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse. But the examples in
the standard, para §5/4, say "unspecified" where the normative text says
"undefined", so there was evidently some confusion back in 1998. That
has already been fixed; Tom Widmer once directed me to <url:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#351>.
I think the intention had to be that also in the case above the effect
should be undefined, so I think that §5/4 should either be fixed to
include the case above as undefined behavior, or be changed to yield
well defined, deterministic behavior.
Why it is like that: once, very long ago, say, around 1972, computers
were really slow. So /a constant factor/ of improved efficiency
mattered a lot; even a marginal improvement could be crucial. And the
computers were also rather primitive, so much so that the compiler's
detailed machine code optimization of expressions directly influenced
efficiency at this level (the hardware didn't do predictive and parallel
execution and such things). So, the more freedom the compiler had to
reorder things in a then "optimal" way, the better for efficiency.
So in C++, for historical reasons, we pay the price, again and again,
but except possibly in embedded systems don't ever get the goods --
they no longer exist, in practice.
Today it seems the 80 to 90% consensus is that deterministic evaluation,
that you can always predict at the "as-if" level which operations will
be executed in which order, matters much much more than whatever
now-really-marginal-if-any improvement of efficiency can be had via free
reordering of expressions. At a slightly more abstract level, namely
reordering of statement execution order under "as-if" rules, as I
understand it it's also desirable for multi-threaded programming. E.g.,
Sutter and Alexandrescu (I think it was) once wrote an article about why
the double-locking pattern isn't supported by current C++.
The problems, as I see them, are that (1) changing the standard in this
respect would probably break a lot of existing code, and (2) it might
-- I don't know -- be problematic for embedded systems programming.
One solution to problem (1) is to say, so what, let's break that code
(after all, it's probably maintained using some old compiler that won't
be upgraded precisely to keep the code working); that was done in 1998.
Another solution to (1) is to e.g. define a macro symbol that specifies
the old unpredictable behavior, say, __UNPREDICTABLE__ (or, after the
marketing department has had its say, __ULTRA_EFFICIENT__), so that for
new compilers, deterministic behavior is by default. This solution has
the advantage of keeping C++ as a practical efficient-enough language
for embedded systems programming, if that actually is a problem. I.e.,
it also solves the hypothetical problem (2).
--
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?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
ThosRTanner
Guest
|
| Posted: Fri Apr 28, 2006 3:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Alf P. Steinbach wrote:
<snip>
| Quote: |
The problems, as I see them, are that (1) changing the standard in this
respect would probably break a lot of existing code, and (2) it might
-- I don't know -- be problematic for embedded systems programming.
One solution to problem (1) is to say, so what, let's break that code
(after all, it's probably maintained using some old compiler that won't
be upgraded precisely to keep the code working); that was done in 1998.
Another solution to (1) is to e.g. define a macro symbol that specifies
the old unpredictable behavior, say, __UNPREDICTABLE__ (or, after the
marketing department has had its say, __ULTRA_EFFICIENT__), so that for
new compilers, deterministic behavior is by default. This solution has
the advantage of keeping C++ as a practical efficient-enough language
for embedded systems programming, if that actually is a problem. I.e.,
it also solves the hypothetical problem (2).
|
As far as embedded systems go, when I was programming for them,
(a) Never changed the compiler without thorough testing - we had a
certain amount of code that was written to get round compiler optimiser
bugs!
(b) Any UB was a no-no because our code had to run on multiple targets,
even though embedded.
(c) If the compiler was provably not fast enough, rewrite the code in
assembler.
(d) Most code was developed with debugging switched on and then it was
switched off for release testing. A change in behaviour at that point
would be considered unhelpful to say the least.
Which probably means that the most likely people to be affected are
those that:
1) Use only 1 compiler
2) Continually upgrade it
3) Require maximal optimisation
I think the __UNPREDICTABLE__ macro should require that when set, it
diagnosed code which might behave differently if it wasn't set.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Momchil Velikov
Guest
|
| Posted: Fri Apr 28, 2006 3:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Alf P. Steinbach wrote:
| Quote: | * fisker0303 (AT) 126 (DOT) com:
In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse.
|
The behavior is *undefined*, because the expression "a = (a + b) - (b =
a);"
violates "5. Expressions" [#4]:
"... Furthermore, the prior value shall be accessed only to determine
the value to be stored. The requirements of this paragraph shall
be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
kmarkw65@yahoo.com
Guest
|
| Posted: Fri Apr 28, 2006 4:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Alf P. Steinbach wrote:
| Quote: | * fisker0303 (AT) 126 (DOT) com:
In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
why?
Why you get that output: C++ does not generally guarantee the evaluation
order of an expression (the built-in boolean operators are exceptions),
and so (as I see it) the expression has unspecified effect: either 'b=a'
is evaluated before 'a+b', or after, at the compiler's discretion.
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse.
|
It makes no difference. Its already undefined. The prior value of b
*could* be used (depending on the ordering of subexpressions). If it is
used, then its certainly not to determine the value stored. So, (modulo
the non-normative examples in 5/4), the behavior is undefined.
Mark Williams
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Fri Apr 28, 2006 7:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Momchil Velikov wrote:
| Quote: | Alf P. Steinbach wrote:
* fisker0303 (AT) 126 (DOT) com:
In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse.
The behavior is *undefined*, because the expression "a = (a + b) - (b =
a);"
violates "5. Expressions" [#4]:
"... Furthermore, the prior value shall be accessed only to determine
the value to be stored. The requirements of this paragraph shall
be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined."
|
No, the behavior is merely unspecified - not undefined. In other words,
the variable "a" is certain to have either the value 20 or the value 10
after the expression is evaluated.
The expression would have to store a value in either "a" or "b" more
than once for it to have undefined behavior.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Guest
|
| Posted: Sat Apr 29, 2006 4:03 am Post subject: Re: vc 6.0's bug????? |
|
|
Thanks a lot.I got it.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
kmarkw65@yahoo.com
Guest
|
| Posted: Sat Apr 29, 2006 9:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Greg Herlihy wrote:
| Quote: | Momchil Velikov wrote:
The behavior is *undefined*, because the expression "a = (a + b) - (b =
a);"
violates "5. Expressions" [#4]:
"... Furthermore, the prior value shall be accessed only to determine
the value to be stored. The requirements of this paragraph shall
be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined."
No, the behavior is merely unspecified - not undefined. In other words,
the variable "a" is certain to have either the value 20 or the value 10
after the expression is evaluated.
The expression would have to store a value in either "a" or "b" more
than once for it to have undefined behavior.
|
That is, indeed, one of the many, many things that invoke undefined
behavior; but the fact that this code doesnt do that is not sufficient
to make its behavior defined.
In fact, since the code violates the "shall" in 5/4 (which you quoted
above), it *does* invoke undefined behavior.
Mark Williams
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
James Dennett
Guest
|
| Posted: Sun Apr 30, 2006 1:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
Greg Herlihy wrote:
| Quote: | Momchil Velikov wrote:
Alf P. Steinbach wrote:
* fisker0303 (AT) 126 (DOT) com:
In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse.
The behavior is *undefined*, because the expression "a = (a + b) - (b =
a);"
violates "5. Expressions" [#4]:
"... Furthermore, the prior value shall be accessed only to determine
the value to be stored. The requirements of this paragraph shall
be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined."
No, the behavior is merely unspecified - not undefined. In other words,
the variable "a" is certain to have either the value 20 or the value 10
after the expression is evaluated.
The expression would have to store a value in either "a" or "b" more
than once for it to have undefined behavior.
|
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
-- James
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Sun Apr 30, 2006 8:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
James Dennett wrote:
| Quote: | Greg Herlihy wrote:
Momchil Velikov wrote:
Alf P. Steinbach wrote:
* fisker0303 (AT) 126 (DOT) com:
In vc 6.0:
#include <iostream
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a=20,b=10
Debug output: a=10,b=10
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse.
The behavior is *undefined*, because the expression "a = (a + b) - (b =
a);"
violates "5. Expressions" [#4]:
"... Furthermore, the prior value shall be accessed only to determine
the value to be stored. The requirements of this paragraph shall
be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined."
No, the behavior is merely unspecified - not undefined. In other words,
the variable "a" is certain to have either the value 20 or the value 10
after the expression is evaluated.
The expression would have to store a value in either "a" or "b" more
than once for it to have undefined behavior.
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
|
In that case, evaluating this expression:
a = b = 0;
must also lead to undefined behavior - because it too reads from b "for
a purpose other than that to determine the value to be stored". And
yet this kind of expression appears so frequently in C++ programs that
it is difficult to imagine that its behavior is, in fact, undefined.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Alf P. Steinbach
Guest
|
| Posted: Mon May 01, 2006 1:06 am Post subject: Re: vc 6.0's bug????? |
|
|
* Greg Herlihy:
| Quote: | James Dennett wrote:
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
In that case, evaluating this expression:
a = b = 0;
must also lead to undefined behavior - because it too reads from b "for
a purpose other than that to determine the value to be stored". And
yet this kind of expression appears so frequently in C++ programs that
it is difficult to imagine that its behavior is, in fact, undefined.
|
This may not count as a read from b, but rather the result of the
assignment operator.
It may be that my opinion re unspecified versus undefined, expressed
earlier in the thread, needs some revision...
But I think, with the standard that unclear, to the point of confusing
the original authors so that they gave examples contradicting the
normative text, it needs fixing. E.g., if the intention is that any
expression where different possible evaluation orders of scalar value
operations can yield different results, is undefined behavior, then I
think that should be stated, and not expressed in terms of more
primitive concepts, like a compiled version that must be disassemblied
and analyzed. But better yet: deterministic, well-defined behavior. ;-)
--
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?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Niklas Matthies
Guest
|
| Posted: Mon May 01, 2006 1:06 am Post subject: Re: vc 6.0's bug????? |
|
|
On 2006-04-30 18:40, Greg Herlihy wrote:
| Quote: | James Dennett wrote:
:
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
In that case, evaluating this expression:
a = b = 0;
must also lead to undefined behavior - because it too reads from b
"for a purpose other than that to determine the value to be stored".
|
FWIW, at least in C this expression doesn't read from b.
-- Niklas Matthies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Victor Bazarov
Guest
|
| Posted: Mon May 01, 2006 2:06 am Post subject: Re: vc 6.0's bug????? |
|
|
Niklas Matthies wrote:
| Quote: | On 2006-04-30 18:40, Greg Herlihy wrote:
James Dennett wrote:
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
In that case, evaluating this expression:
a = b = 0;
must also lead to undefined behavior - because it too reads from b
"for a purpose other than that to determine the value to be stored".
FWIW, at least in C this expression doesn't read from b.
|
What if 'b' is declared 'volatile'? What if the type of 'b' is not
one of built-ins?
V
--
Please remove capital As from my address when replying by mail
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Niklas Matthies
Guest
|
| Posted: Mon May 01, 2006 3:06 pm Post subject: Re: vc 6.0's bug????? |
|
|
On 2006-05-01 01:50, Victor Bazarov wrote:
| Quote: | Niklas Matthies wrote:
On 2006-04-30 18:40, Greg Herlihy wrote:
James Dennett wrote:
It writes to b, and also reads from it for a purpose other
than that to determine the value to be stored. By the quote
above, the behavior is undefined. It is *not* necessary for
there to be two writes to an object between sequence points
for there to be undefined behavior (though it is sufficient).
In that case, evaluating this expression:
a = b = 0;
must also lead to undefined behavior - because it too reads from b
"for a purpose other than that to determine the value to be stored".
FWIW, at least in C this expression doesn't read from b.
What if 'b' is declared 'volatile'?
|
The value of an assignment expression is defined to be the same value
that the left operand will have after the assignment, period. It's
independent from when the side effect of updating the stored value of
the left operand actually occurs. One way to see it is that the value
to be assigned (i.e. after conversion) is duplicated: one copy becomes
the result of the assignment expression while the other one is stored
in the left operand.
I'm not sure whether an implementation that implements this behavior
by performing an actual read on a volatile left operand would be
conforming. The fact that assignment expressions are not lvalues in C
could be taken as an argument against it.
| Quote: | What if the type of 'b' is not one of built-ins?
|
Doesn't make a difference (in C).
-- Niklas Matthies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
