comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Good way to write integer overflow checks? - 14 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/1363de0ff88836cd?hl=en
* C and C++ - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0c5cd0246395d2ed?hl=en
* Template to add members to a class - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/4093d20b1f2e8f1a?hl=en
* Better way to specify return type in obscure case involving Visual C++ bug? -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e05fdec4855ecfb4?hl=en
* Reference is not an object. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/76b508a8b70ab612?hl=en
* WHAT DOES ISLAM SAY ABOUT TERRORISM ????????????????? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6bd3b1012d72d85b?hl=en
==============================================================================
TOPIC: Good way to write integer overflow checks?
http://groups.google.com/group/comp.lang.c++/t/1363de0ff88836cd?hl=en
==============================================================================
== 1 of 14 ==
Date: Mon, Nov 11 2013 4:34 am
From: David Brown
On 11/11/13 12:35, Alf P. Steinbach wrote:
> On 11.11.2013 10:27, David Brown wrote:
>>
> [snipped lots of idiocy, then:]
>>
>> Oh, and "int(-1/2u)" is undefined behaviour.
>
> No, unsigned arithmetic is well-defined.
AFAIUI, int(-1/2u) means "take the signed int -1, promote it to an
unsigned to be compatible with 2u (this promotion is UB for a negative
number), divide it by 2 (fine in unsigned), then convert it to a signed
int (fine if there is no overflow)".
Does it mean something else to you? (It's quite possible that I've got
this wrong, but I'd prefer a better reference. Certainly "unsigned
arithmetic is well-defined" is /not/ the answer.)
>
> I think I plinked you earlier, are you posting under a new e-mail address?
I have a newsreaders on two different computers, and they happen to have
slightly different email addresses. But the name is the same.
>
> Plink.
>
>
> - ALf
>
>
== 2 of 14 ==
Date: Mon, Nov 11 2013 4:42 am
From: David Brown
On 11/11/13 12:31, Alf P. Steinbach wrote:
> On 11.11.2013 09:29, David Brown wrote:
>> On 09/11/13 22:00, Alf P. Steinbach wrote:
>>> On 09.11.2013 20:26, Victor Bazarov wrote:
>>>> On 11/9/2013 10:28 AM, Alf P. Steinbach wrote:
>>>>> This code is in support of some API functionality:
>>>>>
>>>>>
>>>>> [code]
>>>>> inline
>>>>> auto can_inflate( gdi::Rect const& r, int const dx, int const dy )
>>>>> -> bool
>>>>> {
>>>>> CPPX_XASSERT( INT_MIN/2 < dx && dx < INT_MAX/2 );
>>>>> CPPX_XASSERT( INT_MIN/2 < dy && dy < INT_MAX/2 );
>>>>>
>>>>> typedef unsigned long Unsigned_long;
>>>>> auto const msb = ULONG_MAX - (ULONG_MAX >> 1);
>>>>> return
>>>>> (r.left & msb) == ((Unsigned_long( r.left ) - dx) & msb) &&
>>>>> (r.top & msb) == ((Unsigned_long( r.top ) - dy) & msb) &&
>>>>> (r.right & msb) == ((Unsigned_long( r.right ) + dx) &
>>>>> msb) &&
>>>>> (r.bottom & msb) == ((Unsigned_long( r.bottom ) + dy) &
>>>>> msb);
>>>>> }
>>>>> [/code]
>>>>>
>>>>>
>>>>> Can this be written in an even gooder way, for bestest possible code?
>>>>>
>>>>> Disclaimer: the code has not been tested or even called.
>>>>
>>>> What is the code supposed to do? Are you checking if the size of
>>>> 'r' is
>>>> not going to under- or overflow if you add dx and dy to it?
>>>
>>> Yes.
>>>
>>>
>>>> Isn't this the usual way to check if (b+a) is not going to overflow:
>>>>
>>>> if (INT_MAX - b > a) // a+b will NOT overflow
>>>
>>> Don't know, but that expression has formally Undefined Behavior when b
>>> is a negative signed integer, since then the checking itself overflows.
>>
>> If you know (or have previously checked) that dx and/or dy are
>> non-negative, then there is no problem.
>>
>>>
>>> So, at least if one's not going to rely on two's complement form
>>> wrap-around (g++ can be made to trap on that), I /think/ it would yield
>>> more verbose code, possibly also more complicated?
>>>
>>
>> Didn't you learn /anything/ from the thread about undefined behaviour on
>> signed overflow? Because signed overflow is undefined, the compiler can
>> generate /better/ code than it could if it had to support wrap-around
>> behaviour. It will certainly /never/ generate worse code.
>>
>> Stop guessing (you are not "/thinking/", you are guessing) and try it
>> out. Look at the generated assembly on the target in question. Profile
>> it and see if it is too slow. Otherwise any attempt to improve the code
>> is a waste because you don't know that the code is a problem, and can't
>> check or measure any improvements.
>>
>>
>
> I'm sorry but what you write sounds like trolling. It's certainly
> idiocy, it's certainly more about your guessing about people's thoughts
> than the technical, and your assertions are extremely dishonest.
>
> I.e. you're a liar.
>
> Plink.
>
> - Alf
>
If you disagree with what I write, then point out the mistakes. If I am
wrong to assume you are merely guessing about compiler behaviour, then
show me the appropriate disassembly proving that you /have/ tested this
properly.
It's fine to tell me I'm rude (I'm sure there are others that will agree
with you), and it's fine to say I'm wrong (it would not be the first
time). But it is /not/ fine to accuse someone of active dishonesty and
lying without /very/ clear and specific evidence.
== 3 of 14 ==
Date: Mon, Nov 11 2013 5:00 am
From: Victor Bazarov
On 11/11/2013 7:34 AM, David Brown wrote:
> On 11/11/13 12:35, Alf P. Steinbach wrote:
>> On 11.11.2013 10:27, David Brown wrote:
>>>
>> [snipped lots of idiocy, then:]
>>>
>>> Oh, and "int(-1/2u)" is undefined behaviour.
>>
>> No, unsigned arithmetic is well-defined.
>
> AFAIUI, int(-1/2u) means "take the signed int -1, promote it to an
> unsigned to be compatible with 2u (this promotion is UB for a negative
> number),
Where did you get the UB portion of that? And it's not "promoted", it's
"converted". Promotions defined in [conv.prom] and they don't involve
'int' as the *source* type.
> divide it by 2 (fine in unsigned), then convert it to a signed
> int (fine if there is no overflow)".
"Fine" is not a definition of what's going to happen. It's
implementation-defined if the value cannot be represented in the
destination type. See [conv.integral].
> Does it mean something else to you? (It's quite possible that I've got
> this wrong, but I'd prefer a better reference. Certainly "unsigned
> arithmetic is well-defined" is /not/ the answer.)
Well, get a copy of the Standard and ask questions after reading the
relevant sections of it.
>[..]
V
--
I do not respond to top-posted replies, please don't ask
== 4 of 14 ==
Date: Mon, Nov 11 2013 5:45 am
From: David Brown
On 11/11/13 14:00, Victor Bazarov wrote:
> On 11/11/2013 7:34 AM, David Brown wrote:
>> On 11/11/13 12:35, Alf P. Steinbach wrote:
>>> On 11.11.2013 10:27, David Brown wrote:
>>>>
>>> [snipped lots of idiocy, then:]
>>>>
>>>> Oh, and "int(-1/2u)" is undefined behaviour.
>>>
>>> No, unsigned arithmetic is well-defined.
>>
>> AFAIUI, int(-1/2u) means "take the signed int -1, promote it to an
>> unsigned to be compatible with 2u (this promotion is UB for a negative
>> number),
>
> Where did you get the UB portion of that? And it's not "promoted", it's
> "converted". Promotions defined in [conv.prom] and they don't involve
> 'int' as the *source* type.
>
I've read the section of the standard document, and I stand corrected -
thanks.
The "-1" is converted, rather than promoted, to "unsigned int" - and
that conversion is done modulo 2^n. So the conversion of -1 to
"unsigned int" is well defined.
>> divide it by 2 (fine in unsigned), then convert it to a signed
>> int (fine if there is no overflow)".
>
> "Fine" is not a definition of what's going to happen. It's
> implementation-defined if the value cannot be represented in the
> destination type. See [conv.integral].
By "fine", I mean there is clearly defined behaviour for converting an
"unsigned int" into an "int" as long as there is no overflow - i.e., the
value can be represented identically as an "int".
If there /is/ an overflow (i.e., the value cannot be represented), then
the behaviour is implementation defined. (It is a good job I didn't say
what I thought would happen in this case - before reading the standards
closely here, I would probably have said it was "undefined behaviour".)
>
>> Does it mean something else to you? (It's quite possible that I've got
>> this wrong, but I'd prefer a better reference. Certainly "unsigned
>> arithmetic is well-defined" is /not/ the answer.)
>
> Well, get a copy of the Standard and ask questions after reading the
> relevant sections of it.
>
The obvious question to ask is, did I get it right this time?
>> [..]
>
> V
== 5 of 14 ==
Date: Mon, Nov 11 2013 8:07 am
From: Victor Bazarov
On 11/11/2013 8:45 AM, David Brown wrote:
> On 11/11/13 14:00, Victor Bazarov wrote:
>> On 11/11/2013 7:34 AM, David Brown wrote:
>>> On 11/11/13 12:35, Alf P. Steinbach wrote:
>>>> On 11.11.2013 10:27, David Brown wrote:
>>>>>
>>>> [snipped lots of idiocy, then:]
>>>>>
>>>>> Oh, and "int(-1/2u)" is undefined behaviour.
>>>>
>>>> No, unsigned arithmetic is well-defined.
>>>
>>> AFAIUI, int(-1/2u) means "take the signed int -1, promote it to an
>>> unsigned to be compatible with 2u (this promotion is UB for a negative
>>> number),
>>
>> Where did you get the UB portion of that? And it's not "promoted", it's
>> "converted". Promotions defined in [conv.prom] and they don't involve
>> 'int' as the *source* type.
>>
>
> I've read the section of the standard document, and I stand corrected -
> thanks.
>
> The "-1" is converted, rather than promoted, to "unsigned int" - and
> that conversion is done modulo 2^n. So the conversion of -1 to
> "unsigned int" is well defined.
>
>>> divide it by 2 (fine in unsigned), then convert it to a signed
>>> int (fine if there is no overflow)".
>>
>> "Fine" is not a definition of what's going to happen. It's
>> implementation-defined if the value cannot be represented in the
>> destination type. See [conv.integral].
>
> By "fine", I mean there is clearly defined behaviour for converting an
> "unsigned int" into an "int" as long as there is no overflow - i.e., the
> value can be represented identically as an "int".
>
> If there /is/ an overflow (i.e., the value cannot be represented), then
The term "overflow" as used by some other folks here is not the same as
"requires more storage than can be given". I believe the use of the
term 'overflow' relates to the situation that can be recognized by the
processor and appropriately flagged (or trapped). It is run-time
behavior (or situation), not hypothetical relationship between numbers
that exists at the compile time.
So, given that your use of the term "overflow" appears different from
Alf's, I would recommend reviewing your understanding and your previous
statements in this thread. This might help you understand the
objections Alf had to what you had said/written.
According to the standard, the behavior is implementation-defined, that
means that whatever the behavior is, it shall be documented. The result
of such conversion *may* cause overflow (IOW allow such condition to be
registered and programmatically recognized and acted upon), but it does
not *need to*, nor does it *usually* happen.
> the behaviour is implementation defined. (It is a good job I didn't say
> what I thought would happen in this case - before reading the standards
> closely here, I would probably have said it was "undefined behaviour".)
>
>>
>>> Does it mean something else to you? (It's quite possible that I've got
>>> this wrong, but I'd prefer a better reference. Certainly "unsigned
>>> arithmetic is well-defined" is /not/ the answer.)
>>
>> Well, get a copy of the Standard and ask questions after reading the
>> relevant sections of it.
>>
>
> The obvious question to ask is, did I get it right this time?
I'd say, you're getting closer.
V
--
I do not respond to top-posted replies, please don't ask
== 6 of 14 ==
Date: Mon, Nov 11 2013 10:47 am
From: Leigh Johnston
On 11/11/2013 12:42, David Brown wrote:
> On 11/11/13 12:31, Alf P. Steinbach wrote:
>> On 11.11.2013 09:29, David Brown wrote:
>>> On 09/11/13 22:00, Alf P. Steinbach wrote:
>>>> On 09.11.2013 20:26, Victor Bazarov wrote:
>>>>> On 11/9/2013 10:28 AM, Alf P. Steinbach wrote:
>>>>>> This code is in support of some API functionality:
>>>>>>
>>>>>>
>>>>>> [code]
>>>>>> inline
>>>>>> auto can_inflate( gdi::Rect const& r, int const dx, int const dy )
>>>>>> -> bool
>>>>>> {
>>>>>> CPPX_XASSERT( INT_MIN/2 < dx && dx < INT_MAX/2 );
>>>>>> CPPX_XASSERT( INT_MIN/2 < dy && dy < INT_MAX/2 );
>>>>>>
>>>>>> typedef unsigned long Unsigned_long;
>>>>>> auto const msb = ULONG_MAX - (ULONG_MAX >> 1);
>>>>>> return
>>>>>> (r.left & msb) == ((Unsigned_long( r.left ) - dx) & msb) &&
>>>>>> (r.top & msb) == ((Unsigned_long( r.top ) - dy) & msb) &&
>>>>>> (r.right & msb) == ((Unsigned_long( r.right ) + dx) &
>>>>>> msb) &&
>>>>>> (r.bottom & msb) == ((Unsigned_long( r.bottom ) + dy) &
>>>>>> msb);
>>>>>> }
>>>>>> [/code]
>>>>>>
>>>>>>
>>>>>> Can this be written in an even gooder way, for bestest possible code?
>>>>>>
>>>>>> Disclaimer: the code has not been tested or even called.
>>>>>
>>>>> What is the code supposed to do? Are you checking if the size of
>>>>> 'r' is
>>>>> not going to under- or overflow if you add dx and dy to it?
>>>>
>>>> Yes.
>>>>
>>>>
>>>>> Isn't this the usual way to check if (b+a) is not going to overflow:
>>>>>
>>>>> if (INT_MAX - b > a) // a+b will NOT overflow
>>>>
>>>> Don't know, but that expression has formally Undefined Behavior when b
>>>> is a negative signed integer, since then the checking itself overflows.
>>>
>>> If you know (or have previously checked) that dx and/or dy are
>>> non-negative, then there is no problem.
>>>
>>>>
>>>> So, at least if one's not going to rely on two's complement form
>>>> wrap-around (g++ can be made to trap on that), I /think/ it would yield
>>>> more verbose code, possibly also more complicated?
>>>>
>>>
>>> Didn't you learn /anything/ from the thread about undefined behaviour on
>>> signed overflow? Because signed overflow is undefined, the compiler can
>>> generate /better/ code than it could if it had to support wrap-around
>>> behaviour. It will certainly /never/ generate worse code.
>>>
>>> Stop guessing (you are not "/thinking/", you are guessing) and try it
>>> out. Look at the generated assembly on the target in question. Profile
>>> it and see if it is too slow. Otherwise any attempt to improve the code
>>> is a waste because you don't know that the code is a problem, and can't
>>> check or measure any improvements.
>>>
>>>
>>
>> I'm sorry but what you write sounds like trolling. It's certainly
>> idiocy, it's certainly more about your guessing about people's thoughts
>> than the technical, and your assertions are extremely dishonest.
>>
>> I.e. you're a liar.
>>
>> Plink.
>>
>> - Alf
>>
>
> If you disagree with what I write, then point out the mistakes. If I am
> wrong to assume you are merely guessing about compiler behaviour, then
> show me the appropriate disassembly proving that you /have/ tested this
> properly.
>
> It's fine to tell me I'm rude (I'm sure there are others that will agree
> with you), and it's fine to say I'm wrong (it would not be the first
> time). But it is /not/ fine to accuse someone of active dishonesty and
> lying without /very/ clear and specific evidence.
The idiot "plink'd" you which is idiot-speak for blacklisting your
posts. He has also "plink'd" me as the guy can't handle criticism.
/Leigh
== 7 of 14 ==
Date: Mon, Nov 11 2013 10:54 am
From: James Kanze
On Saturday, 9 November 2013 22:09:34 UTC, Alf P. Steinbach wrote:
> On 09.11.2013 22:14, Ian Collins wrote:
> > Alf P. Steinbach wrote:
> >> This code is in support of some API functionality:
> >> [code]
> >> inline
> >> auto can_inflate( gdi::Rect const& r, int const dx, int const dy )
> >> -> bool
> > Why do you insist on using this form rather than the sorter, more
> > conventional form?
> Uhm, the word "insist" incorrectly indicates some kind of opposition to
> the adoption of `auto`. ;-)
> Anyway, there are many good reasons, but for me the most important is a
> consistent visual layout:
> * function name at fixed place.
> * return type visually separated.
You mean like the way I've always written function definitions:
bool
can_inflate( ... )
{
}
The function name is always at the start of the line. Has been
since I learned C. (Back then, about all we had for searching
was grep, and "grep ^can_inflate" would always get the
definition, and nothing else.)
> Which means that the human eye finds it much easier to just scan through
> the code to find a name or note the names, or inspect return types, with
> no to read and analyze the text.
You're style makes it harder to find the return type. (I never
found this a problem in Modula-2, but C++ is not Modula-2.)
--
James
== 8 of 14 ==
Date: Mon, Nov 11 2013 11:01 am
From: James Kanze
On Sunday, 10 November 2013 01:34:40 UTC, Sam wrote:
> Alf P. Steinbach writes:
[...]
> Yes, it can be. A more generic algorithm, for any signed int type:
> template<typename signed_int_t>
> signed_int_t add_with_overflow_check(signed_int_t a, signed_int_t b)
> {
> signed_int_t c=a+b;
> if (b > 0)
> {
> if (c < a)
> do_whatever_you_want_when_you_overflow();
> }
> else
> {
> if (c > a)
> do_whatever_you_want_when_you_overflow();
> }
> return c;
> }
> Your C++ homework assignment consists of three parts:
> 1. Explain why the above code works
It doesn't. Unless the undefined behavior happens to give it
the appearance of working.
To correctly check for overflow of signed integral types, you
first have to check whether the signs are the same. (If they
aren't it won't overflow.) Then check either
std::numeric_limits<int_t>::max() - a or
std::numeric_limits<int_t>::min() + a with b, depending on
whether both are negative, or both are positive.
--
James
== 9 of 14 ==
Date: Mon, Nov 11 2013 11:24 am
From: "Alf P. Steinbach"
On 11.11.2013 19:54, James Kanze wrote:
> On Saturday, 9 November 2013 22:09:34 UTC, Alf P. Steinbach wrote:
>> On 09.11.2013 22:14, Ian Collins wrote:
>>> Alf P. Steinbach wrote:
>>>> This code is in support of some API functionality:
>
>>>> [code]
>>>> inline
>>>> auto can_inflate( gdi::Rect const& r, int const dx, int const dy )
>>>> -> bool
>
>>> Why do you insist on using this form rather than the sorter, more
>>> conventional form?
>
>> Uhm, the word "insist" incorrectly indicates some kind of opposition to
>> the adoption of `auto`. ;-)
>
>> Anyway, there are many good reasons, but for me the most important is a
>> consistent visual layout:
>
>> * function name at fixed place.
>> * return type visually separated.
>
> You mean like the way I've always written function definitions:
>
> bool
> can_inflate( ... )
> {
> }
>
> The function name is always at the start of the line. Has been
> since I learned C. (Back then, about all we had for searching
> was grep, and "grep ^can_inflate" would always get the
> definition, and nothing else.)
No, with C++11 that style can no longer (in practice) yield a consistent
layout, since in cases where the return type depends on the argument
types one avoids a lot of complication and verbosity by using `auto`.
For details of how bad it can be see Andrei's "min max revisited"
article in DDJ (I leave it to the reader to google it). For example,
even in C++11 you can NOT simply write
template< class T >
decltype( a*b ) mul( T a, T b )
{ return a*b; }
But you can write, and since you're pragmatic you will eventually write,
template< class T >
auto mul( T a, T b )
-> decltype( a*b )
{ return a*b; }
So, your currently favorite style was good for C, to the degree that a
syntax that both the C creators and the C++ creator have described as a
"failed experiment", can be good. It was good in that sense also for
C++03. With C++11 it's IMHO just ungood, since it no longer covers all
cases and thus yields an inconsistent mix of declaration styles.
d>> Which means that the human eye finds it much easier to just scan
through
>> the code to find a name or note the names, or inspect return types, with
>> no to read and analyze the text.
>
> You're style makes it harder to find the return type. (I never
> found this a problem in Modula-2, but C++ is not Modula-2.)
Hm, I can't remember much about Modula-2 declarations.
I do remember that good old Niklaus, Praise be Upon Him, for some
inexplicable reason forced the Modula-2 programmer to use UPPERCASE
keywords. Or I think I remember that. Also it was nice with built-in
coroutine support.
Anyway... ;-)
Cheers & hth.,
- Alf
== 10 of 14 ==
Date: Tues, Nov 12 2013 1:02 am
From: David Brown
On 11/11/13 19:47, Leigh Johnston wrote:
> On 11/11/2013 12:42, David Brown wrote:
>> On 11/11/13 12:31, Alf P. Steinbach wrote:
>>> On 11.11.2013 09:29, David Brown wrote:
>>>> On 09/11/13 22:00, Alf P. Steinbach wrote:
>>>
>>> I'm sorry but what you write sounds like trolling. It's certainly
>>> idiocy, it's certainly more about your guessing about people's thoughts
>>> than the technical, and your assertions are extremely dishonest.
>>>
>>> I.e. you're a liar.
>>>
>>> Plink.
>>>
>>> - Alf
>>>
>>
>> If you disagree with what I write, then point out the mistakes. If I am
>> wrong to assume you are merely guessing about compiler behaviour, then
>> show me the appropriate disassembly proving that you /have/ tested this
>> properly.
>>
>> It's fine to tell me I'm rude (I'm sure there are others that will agree
>> with you), and it's fine to say I'm wrong (it would not be the first
>> time). But it is /not/ fine to accuse someone of active dishonesty and
>> lying without /very/ clear and specific evidence.
>
> The idiot "plink'd" you which is idiot-speak for blacklisting your
> posts. He has also "plink'd" me as the guy can't handle criticism.
>
> /Leigh
>
Yes, I know what he meant by "plink" (even though I have only ever seen
it as "plonk" from other Usenet users). I've always thought it was
quite childish (like putting your fingers in your ears and saying "I'm
not listening"), except of course for the worst spammers. I suppose in
the "old days" with slow links, it might have been more important to
save bandwidth.
This is a public arena - the disagreements were in public, so I think it
is right to respond in public even after a "plonk" (or "plink"). Of
course, I'd much rather that Alf reads my posts and responds - but
that's up to him.
== 11 of 14 ==
Date: Tues, Nov 12 2013 1:53 am
From: David Brown
On 11/11/13 17:07, Victor Bazarov wrote:
> On 11/11/2013 8:45 AM, David Brown wrote:
>> On 11/11/13 14:00, Victor Bazarov wrote:
>>> On 11/11/2013 7:34 AM, David Brown wrote:
>>>> On 11/11/13 12:35, Alf P. Steinbach wrote:
>>>>> On 11.11.2013 10:27, David Brown wrote:
>>>>>>
>>>>> [snipped lots of idiocy, then:]
>>>>>>
>>>>>> Oh, and "int(-1/2u)" is undefined behaviour.
>>>>>
>>>>> No, unsigned arithmetic is well-defined.
>>>>
>>>> AFAIUI, int(-1/2u) means "take the signed int -1, promote it to an
>>>> unsigned to be compatible with 2u (this promotion is UB for a negative
>>>> number),
>>>
>>> Where did you get the UB portion of that? And it's not "promoted", it's
>>> "converted". Promotions defined in [conv.prom] and they don't involve
>>> 'int' as the *source* type.
>>>
>>
>> I've read the section of the standard document, and I stand corrected -
>> thanks.
>>
>> The "-1" is converted, rather than promoted, to "unsigned int" - and
>> that conversion is done modulo 2^n. So the conversion of -1 to
>> "unsigned int" is well defined.
>>
>>>> divide it by 2 (fine in unsigned), then convert it to a signed
>>>> int (fine if there is no overflow)".
>>>
>>> "Fine" is not a definition of what's going to happen. It's
>>> implementation-defined if the value cannot be represented in the
>>> destination type. See [conv.integral].
>>
>> By "fine", I mean there is clearly defined behaviour for converting an
>> "unsigned int" into an "int" as long as there is no overflow - i.e., the
>> value can be represented identically as an "int".
>>
>> If there /is/ an overflow (i.e., the value cannot be represented), then
>
> The term "overflow" as used by some other folks here is not the same as
> "requires more storage than can be given". I believe the use of the
> term 'overflow' relates to the situation that can be recognized by the
> processor and appropriately flagged (or trapped). It is run-time
> behavior (or situation), not hypothetical relationship between numbers
> that exists at the compile time.
I am not sure that we can make such subtle distinctions about the use of
the word "overflow" - I think it is valid to use it in either sense. As
far as I can see, there is not "official" definition in the C++ standard
(correct me if I'm wrong!), and no particular grounds for fine
differentiation. To my understanding, a calculation "overflows" if it
cannot be done while keeping the natural correspondence between the
abstract idea (such as mathematical integers) and the concrete
implementation (such as a an n-bit twos-complement number). So with
16-bit integers, 30000 + 20000 overflows - regardless of whether or not
the processor flags it.
I have been trying a simple search for the term "overflow" in N3337
(approximately the C++11 standard, but conveniently available as a free
pdf). Under 1.9 "Program execution" paragraph 9, there is a discussion
about re-arranging arithmetic by associative and commutative operations
- on targets which "produce exceptions on overflow", the compiler cannot
necessarily re-arrange the arithmetic, while on targets " in which the
results of overflows are reversible" allows them.
Under chapter 5 "Expressions", we have this:
If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values for
its type, the behavior is undefined. [ Note: most existing
implementations of C++ ignore integer overflows. Treatment of division
by zero, forming a remainder using a zero divisor, and all floating
point exceptions vary among machines, and is usually adjustable by a
library function. — end note ]
I think that suggests "overflow" means "the result is not mathematically
defined or not in the range of representable values for its type", which
is the how I have been using the term.
>
> So, given that your use of the term "overflow" appears different from
> Alf's, I would recommend reviewing your understanding and your previous
> statements in this thread. This might help you understand the
> objections Alf had to what you had said/written.
I have tried, but I don't see it. I don't think the issue of
flagging/trapping is important in the discussion (though Alf has used
"-ftrapv" with varying success in his tests). I am very open to the
idea that our disagreement was/is due to a misunderstanding on some
particular term, but I think that we do understand each other, and we
disagree. Alf thinks that signed integers should behave as module 2^n,
that this is the "natural" behaviour (following the principle of least
surprise), and that compilers should follow that even though the
standard says signed integer overflow is undefined behaviour. I think
that there is no natural behaviour for signed integer overflow, that
modulo behaviour is as surprising as any other behaviour, and that
compilers can use the "undefined behaviour" tag to allow better
optimisations.
It is unfortunate and regrettable that the argument seems to have got
suddenly out of hand with Alf's later replies to my posts - I still do
not see where his accusations come from.
>
> According to the standard, the behavior is implementation-defined, that
> means that whatever the behavior is, it shall be documented. The result
> of such conversion *may* cause overflow (IOW allow such condition to be
> registered and programmatically recognized and acted upon), but it does
> not *need to*, nor does it *usually* happen.
Yes.
>
>> the behaviour is implementation defined. (It is a good job I didn't say
>> what I thought would happen in this case - before reading the standards
>> closely here, I would probably have said it was "undefined behaviour".)
>>
>>>
>>>> Does it mean something else to you? (It's quite possible that I've got
>>>> this wrong, but I'd prefer a better reference. Certainly "unsigned
>>>> arithmetic is well-defined" is /not/ the answer.)
>>>
>>> Well, get a copy of the Standard and ask questions after reading the
>>> relevant sections of it.
>>>
>>
>> The obvious question to ask is, did I get it right this time?
>
> I'd say, you're getting closer.
>
> V
== 12 of 14 ==
Date: Tues, Nov 12 2013 2:23 am
From: tomalak@gmail.com
On Monday, November 11, 2013 11:37:46 AM UTC, Alf P. Steinbach wrote:
> I've already replied to earlier postings of yours in this thread.
>
> You have demonstrated general incompetence, reasoning disability,
> dishonesty and trolling.
>
> Plink.
Alf,
Please refrain from this unnecessary vitriol. This is a technical forum for the discussion of technical issues, and childish insults and finger-in-ear "la la la I can't hear you" screaming is off-topic. If you wish to "plink" someone then fine, do it, but there is no need to advertise the fact to the entire group, other than to "have the last word". Shame it's not even a real word.
Let's all stick to the matter at hand.
Thanks.
== 13 of 14 ==
Date: Tues, Nov 12 2013 2:45 am
From: James Kanze
On Monday, 11 November 2013 19:24:57 UTC, Alf P. Steinbach wrote:
> On 11.11.2013 19:54, James Kanze wrote:
> > On Saturday, 9 November 2013 22:09:34 UTC, Alf P. Steinbach wrote:
> >> On 09.11.2013 22:14, Ian Collins wrote:
> >>> Alf P. Steinbach wrote:
> >>>> This code is in support of some API functionality:
> >>>> [code]
> >>>> inline
> >>>> auto can_inflate( gdi::Rect const& r, int const dx, int const dy )
> >>>> -> bool
> >>> Why do you insist on using this form rather than the sorter, more
> >>> conventional form?
> >> Uhm, the word "insist" incorrectly indicates some kind of opposition to
> >> the adoption of `auto`. ;-)
> >> Anyway, there are many good reasons, but for me the most important is a
> >> consistent visual layout:
> >> * function name at fixed place.
> >> * return type visually separated.
> > You mean like the way I've always written function definitions:
> > bool
> > can_inflate( ... )
> > {
> > }
> > The function name is always at the start of the line. Has been
> > since I learned C. (Back then, about all we had for searching
> > was grep, and "grep ^can_inflate" would always get the
> > definition, and nothing else.)
> No, with C++11 that style can no longer (in practice) yield a consistent
> layout, since in cases where the return type depends on the argument
> types one avoids a lot of complication and verbosity by using `auto`.
> For details of how bad it can be see Andrei's "min max revisited"
> article in DDJ (I leave it to the reader to google it). For example,
> even in C++11 you can NOT simply write
> template< class T >
> decltype( a*b ) mul( T a, T b )
> { return a*b; }
And you said something about avoiding complication... (Of
course, in this case the return is just T, so any decltype is
simply added verbosity. I suspect you meant for a and b to
potentially have different types, however, in which case, it
sort of makes sense. If you like implicit type conversions and
unreadable code at the client level---but that too is a long
tradition, dating back to C.)
The question is: how often is something like this relevant?
Perhaps if you're writting a very low level library, but
certainly not in application code.
> But you can write, and since you're pragmatic you will eventually write,
> template< class T >
> auto mul( T a, T b )
> -> decltype( a*b )
> { return a*b; }
(Just to be clear: I think you really mean:
template< typename T1, typename T2 >
auto mul( T1 a, T2 b )
-> decltype( a * b )
{
return a * b;
}
. Otherwise, using decltype is just added verbosity.)
> So, your currently favorite style was good for C, to the degree that a
> syntax that both the C creators and the C++ creator have described as a
> "failed experiment", can be good. It was good in that sense also for
> C++03. With C++11 it's IMHO just ungood, since it no longer covers all
> cases and thus yields an inconsistent mix of declaration styles.
It's good in the same sense that && and ||, rather than "and"
and "or" are good. It's idiomatic for the language. It's what
everyone reading the language expects.
It's also good in the sense that seeing "auto" in front of
a function triggers the reaction: here's some fancy, overly
complicated template mess. Because the ubiquitous use today is
not to use "auto", unless you need it for the decltype.
That doesn't mean that in an abstract, ideal world, something
like:
FUNCTION func( ... ) -> return_type
wouldn't be better. But this isn't an abstract, ideal world;
this is C++. And the keyword "auto" is the same as for
a variable, so it doesn't add any additional information. For
the moment, all of this is new, so best practices haven't really
been established, but generally, from what I can see so far:
"auto" should be limited to variables containing "standardized"
return values of member functions, where the type of the return
value depends on the type of object the member function was
called on. E.g.
auto iter = container.begin();
For just about anything else, it's simply additional
obfuscation.
> d>> Which means that the human eye finds it much easier to just scan through
> >> the code to find a name or note the names, or inspect return types, with
> >> no to read and analyze the text.
> > You're style makes it harder to find the return type. (I never
> > found this a problem in Modula-2, but C++ is not Modula-2.)
> Hm, I can't remember much about Modula-2 declarations.
See above.
> I do remember that good old Niklaus, Praise be Upon Him, for some
> inexplicable reason forced the Modula-2 programmer to use UPPERCASE
> keywords.
Which is as it should be. Upper case stands out; keywords (like
WHILE and IF) should stand out, given the impact they have on
the meaning of the code. Upper case is less readable; the
keywords form a small, closed set, which makes them immediately
identifiable despite this.
The fact that keywords and user symbols were not distinguishable
made early C significantly harder to read. (Today, of course,
syntax highlighting solves this problem, so it's no longer
a bother.)
> Or I think I remember that. Also it was nice with built-in
> coroutine support.
Above all, it had the best model for separate compilation that
I've ever seen. (If I understand correctly, David Vandevorde's
module proposal is based, at least for the semantics, on
Modula-2's modules.)
--
James
== 14 of 14 ==
Date: Tues, Nov 12 2013 3:51 am
From: James Kanze
On Tuesday, 12 November 2013 09:53:53 UTC, David Brown wrote:
> On 11/11/13 17:07, Victor Bazarov wrote:
> >> If there /is/ an overflow (i.e., the value cannot be represented), then
> > The term "overflow" as used by some other folks here is not the same as
> > "requires more storage than can be given". I believe the use of the
> > term 'overflow' relates to the situation that can be recognized by the
> > processor and appropriately flagged (or trapped). It is run-time
> > behavior (or situation), not hypothetical relationship between numbers
> > that exists at the compile time.
> I am not sure that we can make such subtle distinctions about the use of
> the word "overflow" - I think it is valid to use it in either sense.
I don't really see two different senses. Overflow is run-time
behavior (unless it occurs in a constant expression in
pre-C++11), since whether it occurs depends on the values
involved. But I think we would agree that if the data types had
enough bits, overflow wouldn't occur. (At the hardware level,
at least with 2's complement addition, overflow is defined as
the xor of the carry into the sign bit and the carry out of the
sign bit. Hardware doesn't consider the possibility that word
size can be increased.)
> As
> far as I can see, there is not "official" definition in the C++ standard
> (correct me if I'm wrong!), and no particular grounds for fine
> differentiation. To my understanding, a calculation "overflows" if it
> cannot be done while keeping the natural correspondence between the
> abstract idea (such as mathematical integers) and the concrete
> implementation (such as a an n-bit twos-complement number). So with
> 16-bit integers, 30000 + 20000 overflows - regardless of whether or not
> the processor flags it.
Almost all processors do flag it. (IIRC, the 8080 didn't. But
that was a long time ago.) The issue is whether the generated
code pays attention to the flag.
The Intel x86 processors have a special instruction
(INTO---interrupt on overflow) precisely to make it simple to
handle. A good compiler will, at least when the proper options
are given, insert this instruction immediately after each
operation.
[...]
> > So, given that your use of the term "overflow" appears different from
> > Alf's, I would recommend reviewing your understanding and your previous
> > statements in this thread. This might help you understand the
> > objections Alf had to what you had said/written.
> I have tried, but I don't see it. I don't think the issue of
> flagging/trapping is important in the discussion (though Alf has used
> "-ftrapv" with varying success in his tests).
Trapping is one of the possible "undefined behavior". The
preferable one, although on most hardware, it has significant
performance implementations if the compiler is to achieve it.
> I am very open to the
> idea that our disagreement was/is due to a misunderstanding on some
> particular term, but I think that we do understand each other, and we
> disagree. Alf thinks that signed integers should behave as module 2^n,
> that this is the "natural" behaviour (following the principle of least
> surprise),
Least surprise for who?
> and that compilers should follow that even though the
> standard says signed integer overflow is undefined behaviour. I think
> that there is no natural behaviour for signed integer overflow, that
> modulo behaviour is as surprising as any other behaviour, and that
> compilers can use the "undefined behaviour" tag to allow better
> optimisations.
The error isn't that signed overflow isn't module; the error is
that unsigned overflow is defined. There are cases where you
want an abstraction with modulo arithmetic (e.g. calculating
hash codes), but if you're using usual arithmetic, the
"abstraction" is the set of integers (an infinit set), and if
the abstraction is violated in any manner, you want an abrupt
and fatal failure. (Afterwards, of course, it's up to you to
validate the input, so that you can't end up in such a case.)
> It is unfortunate and regrettable that the argument seems to have got
> suddenly out of hand with Alf's later replies to my posts - I still do
> not see where his accusations come from.
> > According to the standard, the behavior is implementation-defined, that
> > means that whatever the behavior is, it shall be documented. The result
> > of such conversion *may* cause overflow (IOW allow such condition to be
> > registered and programmatically recognized and acted upon), but it does
> > not *need to*, nor does it *usually* happen.
The C standard makes this much clearer: the "results" are
implementation defined, and may include an implementation
defined signal being raised.
--
James
==============================================================================
TOPIC: C and C++
http://groups.google.com/group/comp.lang.c++/t/0c5cd0246395d2ed?hl=en
==============================================================================
== 1 of 4 ==
Date: Mon, Nov 11 2013 5:39 am
From: Juha Nieminen
Scott Lurndal <scott@slp53.sl.home> wrote:
> In over 30 years of C and C++ programming, both bare-metal and large application,
> I've not found the speed of allocation, when properly designed and utilized,
> to be a significant issue.
In the vast majority of cases it doesn't matter if you allocate objects
dynamically. Thinks like std::set are useful in most situations regardless
of the slowness of dynamic memory allocation (because in the vast majority
of cases searching is done a lot more than adding elements.)
However, as an experienced C++ programmer one should be aware of how
inefficient dynamic allocation is, and avoid it in situations where it
may cause a problem, especially if there's an easy alternative. For
example, allocating an object dynamically in a tight inner loop of an
algorithm that needs to be as fast as possible (and which may get run
millions of times) is madness, especially if there's really no need to
allocate it dynamically. The difference in speed will probably be one
or two orders of magnitude.
Also, if you can use an array or vector to handle objects by value,
that's always preferable to allocating individual objects separately,
unless there's a good reason to do the latter. (As an extreme example,
if you were handling eg. image data, and you have a class that represents
one pixel, it would be madness to allocate each pixel object individually
instead of using a vector of them.)
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 2 of 4 ==
Date: Mon, Nov 11 2013 5:45 am
From: Juha Nieminen
Drew Lawson <drew@furrfu.invalid> wrote:
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others.
Note that this thread is mainly comparing C to C++. C does not offer
any alternative to RAII (like many other programming languages do.)
An argument could be made whether RAII-style or eg. Java-style GC is
better, but I don't think that's the issue being discussed.
> Templates are either not very important,
> or they are the only essential language contribution.
It's not a question of religious conviction. It's a question of experience.
In my experience templates are much more useful and important than eg.
dynamic binding. (Not that the language wouldn't get a lot worse if
dynamic binding were removed, but if I were to compare the two, then
templates are in practice much more useful.)
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 3 of 4 ==
Date: Mon, Nov 11 2013 5:46 am
From: Juha Nieminen
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> RAII without exceptions would not be so important.
I have to strongly disagree with that.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 4 of 4 ==
Date: Mon, Nov 11 2013 5:52 am
From: Juha Nieminen
Dombo <dombo@disposable.invalid> wrote:
> My experience is that the lack of RAII is not all that painful in these
> languages.
It might not be painful per se, but the lack can certainly be felt in
some cases. It's the very reason for the existence of 'using' blocks
in C#, for instance (which is basically a limited form of RAII.)
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
==============================================================================
TOPIC: Template to add members to a class
http://groups.google.com/group/comp.lang.c++/t/4093d20b1f2e8f1a?hl=en
==============================================================================
== 1 of 4 ==
Date: Mon, Nov 11 2013 11:30 am
From: David Harmon
On Sun, 10 Nov 2013 12:02:20 +0100 in comp.lang.c++, "Alf P.
Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote,
>The prefix "C" for a class is a Microsoft abomination.
>It has no useful purpose, but it does preclude using that prefix to
>indicate something useful such as "const".
It serves the very useful purpose of enabling someone reading your
code to distinguish Microsoft classes from your own classes without
remembering them all. Never using class names beginning with "C"
for your own classes is a small price to pay for that. Of course
namespaces are a better solution, but many Microsoft APIs were
defined before c++ namespaces existed.
== 2 of 4 ==
Date: Tues, Nov 12 2013 12:01 am
From: Juha Nieminen
Giuliano Bertoletti <gbe32241@libero.it> wrote:
> I need to define other classes with the same layout but with generally a
> different number of items.
It sounds like you essentially want std::tuple.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 3 of 4 ==
Date: Tues, Nov 12 2013 2:23 am
From: James Kanze
On Monday, 11 November 2013 19:30:24 UTC, David Harmon wrote:
> On Sun, 10 Nov 2013 12:02:20 +0100 in comp.lang.c++, "Alf P.
> Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote,
> >The prefix "C" for a class is a Microsoft abomination.
> >It has no useful purpose, but it does preclude using that prefix to
> >indicate something useful such as "const".
> It serves the very useful purpose of enabling someone reading your
> code to distinguish Microsoft classes from your own classes without
> remembering them all. Never using class names beginning with "C"
> for your own classes is a small price to pay for that. Of course
> namespaces are a better solution, but many Microsoft APIs were
> defined before c++ namespaces existed.
It's fairly short for a prefix. Still, it doesn't exclude using
your own classes beginning with a "C", as long as the "C" isn't
a prefix in your classes. In the Microsoft classes, it will be
a "C", followed by a word which also begins with an upper case;
it's immediately visible that the "C" is a prefix. In your own
classes, if the "C" isn't a prefix, it will normally be followed
by a lower case, and will effectively appear as part of the
name, and not an unrelated prefix.
--
James
== 4 of 4 ==
Date: Tues, Nov 12 2013 3:44 am
From: Öö Tiib
On Sunday, 10 November 2013 10:34:10 UTC+2, Giuliano Bertoletti wrote:
> I've some classes with the following layout:
>
> // CCrumb is a string derived type
>
> typedef std::vector<CCrumb *> CRUMBSVECTOR;
>
> class CMatchEntry {
> public:
> // similar classes may have a different number of CCrumbs
> // with different names
> CCrumb id;
> CCrumb name;
> CCrumb logistic;
> CCrumb result;
> CCrumb details;
> CCrumb status;
>
> public:
> // there's only this member which
> // fills a vector of pointers
> void GetCrumbs(CRUMBSVECTOR &cv)
> {
> cv.clear();
> cv.push_back(&id);
> cv.push_back(&name);
> cv.push_back(&logistic);
> cv.push_back(&result);
> cv.push_back(&details);
> cv.push_back(&status);
> }
> };
>
> as you see, this class has some members all of the same type which have
> to be conveniently returned into a vecotr of pointers for output in an
> HTML table.
>
> I need to define other classes with the same layout but with generally a
> different number of items.
When I generate classes then I usually do it with some (often self-made) external
code generator tool. Preprocessor metaprogramming and/or template
metaprogramming feel hellishly cryptic if to compare with little Python script that
any kid can read.
> I do not want to define a vector of crumbs inside a generic class,
> beacuse I would then need to use indexes to set members which is prone
> to error.
>
> Is there a way to cleverly use template and define classes by specifying
> only the names and number of crumbs? I.e.
Ok ... so hard way then? Smart choice. Boost.Serialization can serialise any
object to XML and back from XML to object with not too much work for user.
Writing similar thing is another story of course. ;-) Download it and study.
Every preprocessor, template and pointer-to-member trick you need (and
way more than you need) is used there. You are lot more clever after
studying it than you were before. ;-)
==============================================================================
TOPIC: Better way to specify return type in obscure case involving Visual C++
bug?
http://groups.google.com/group/comp.lang.c++/t/e05fdec4855ecfb4?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Nov 11 2013 4:59 pm
From: "Alf P. Steinbach"
As context info, this question originated with the following code
supporting direct use of the Windows GUI API (properly unpacking and
dispatching so called "window message" events), where the problematic
stuff is in the last "->" result type specification:
[code]
#pragma once
// Copyright (c) 2013 Alf P. Steinbach
#include <rfc/cppx/Type_.h> // cppx::Type_T_
#include <rfc/cppx/macros/c++11_features.h> // CPPX_NOEXCEPT
#include <rfc/winapi/gui/event/Data.h> //
winapi::gui::event::Data, LRESULT
// Invokes e.g. HANDLE_WM_SIZE from <windowsx.h>.
// The type `This_class` should be accessible to the invocation.
#define WINAPI_CALL_WM_HANDLER( wm_name, event_handler_func, event_data
) \
((void) event_data, HANDLE_ ## wm_name(
\
&This_class::event_handler_func,
\
event_data.w_param(),
\
event_data.l_param(),
\
call_member<This_class>
\
) )
namespace winapi{ namespace gui{ namespace event{
using cppx::Type_T_;
class Handler
{
private:
virtual auto on( event::Data const& ) CPPX_NOEXCEPT -> LRESULT = 0;
protected:
static auto forward_to(
Handler* const handler,
event::Data const& event_data
)
-> LRESULT
{ return handler->on( event_data ); }
template< class Derived, class Member_func, class... Args >
auto call_member( Member_func const& mf, Args&&... args )
-> typename Type_T_<decltype( mem_fn( mf ) )>::T::result_type
{ return (static_cast<Derived*>( this )->*mf)( forward<Args>(
args )... ); }
};
} } } // namespace winapi::gui::event
[/code]
That is, the problem is the sheer verbosity of
-> typename Type_T_<decltype( mem_fn( mf ) )>::T::result_type
The Type_T_ template is just a means to get a specified type as a type,
a workaround for syntactical issues. It typedefs the specified type as
T. A marginal improvement is to use C++11 "using" and write just
-> typename Type_<decltype( mem_fn( mf ) )>::result_type
but Visual C++ 12.0 (2013) chokes on this, in the above context.
I have the feeling that this can somehow be done in some much betterer way?
Cheers,
- Alf
==============================================================================
TOPIC: Reference is not an object.
http://groups.google.com/group/comp.lang.c++/t/76b508a8b70ab612?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Nov 11 2013 5:23 pm
From: wy
On 11/11/2013 09:18 AM, Ian Collins wrote:
> int &r = ref;
>
> doesn't declare a reference to a reference, it declares another
> reference that is assigned the same value as ref.
I say this on P69 of the book. "When we use a reference, we are really
using the object to which the reference refers." Thank you!
> int& *p;
>
> would attempt to declare a pointer to a reference.
>
So "int &&" attempts to declare a reference to a reference, "int &*"
attempts to declare a pointer to a reference, right?
== 2 of 2 ==
Date: Mon, Nov 11 2013 6:10 pm
From: Öö Tiib
On Tuesday, 12 November 2013 03:23:40 UTC+2, wy wrote:
> On 11/11/2013 09:18 AM, Ian Collins wrote:
> > int &r = ref;
> >
> > doesn't declare a reference to a reference, it declares another
> > reference that is assigned the same value as ref.
> I say this on P69 of the book. "When we use a reference, we are really
> using the object to which the reference refers." Thank you!
>
> > int& *p;
> >
> > would attempt to declare a pointer to a reference.
> >
>
> So "int &&" attempts to declare a reference to a reference, "int &*"
> attempts to declare a pointer to a reference, right?
No. "int &&" is reference to int rvalue. "int &*" is syntax error
that looks like someone wanted to declare pointer to reference.
==============================================================================
TOPIC: WHAT DOES ISLAM SAY ABOUT TERRORISM ?????????????????
http://groups.google.com/group/comp.lang.c++/t/6bd3b1012d72d85b?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Nov 12 2013 2:40 am
From: tomalak@gmail.com
On Thursday, November 7, 2013 7:09:50 PM UTC, BV BV wrote:
> WHAT DOES ISLAM SAY ABOUT TERRORISM?
Although I understood the above code, I couldn't get it to compile.
Could you please tell me which compiler flags you used?
Thanks.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment