Paul Pluzhnikov writes:
> Keying off NDEBUG rather than __OPTIMIZE__ seems like a more
> consistent approach -- if you want assert()s, then you probably also
> want these checks.
That's a bad idea. NDEBUG ("Be really slow unless the user has
positively defined this macro, whose use is rare enoug
A nitpick: the dragon book was first published 36 years ago... (!)
-miles
--
“There are moments, Jeeves, when one asks oneself, ‘Do trousers matter?’”
“The mood will pass, sir.” [P.G. Wodehouse, "The Code Of The Woosters"]
"N.M. Maclaren" writes:
> That is another matter entirely. The code of gcc/gfortran is supposed
> to be compilable with other compilers, and it is foolish to make
> unnecessary assumptions by relying on undefined behaviour.
>
> The simple facts are that C++ does NOT define bool to be compatible w
Gabriel Dos Reis writes:
> In many places, we do thinks like:
> 1. test that we have a identifier.
> 2. immediately follow that with access to parts of the
> tree as identifiers, but check again that we really
> an identifier, etc.
>
> There is nothing silly about that.
Sure, it's
Gabriel Dos Reis writes:
> in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
> except that it returns a typed pointer instead of a boolean value.
What's the point of returning a pointer when the name (and apparently,
use, judging from the patch) suggest a boolean...?
[If it
Marek Polacek writes:
> + bool changed = false;
> + changed |= true;
> + changed |= true;
> + changed |= true;
> + changed |= true;
> +if (changed)
Why do you use "|=" ...? Isn't it equivalent to just "=" (which is
more clear) for a boolean?
Thanks,
-miles
--
永日の
x...@google.com (Rong Xu) writes:
> - gcov_unsigned_t is_exported;
> + gcov_unsigned_t flag;/* bit 0: is_exported,
> + bit 1: need to include all the auxiliary
> + modules in use compilation. */
"flags"?
Thanks,
-miles
Can this replace the current mersenne twister implementation in
std:: once the endianness issue, etc, have been worked out?
-miles
--
Is it true that nothing can be known? If so how do we know this? -Woody Allen
Richard Guenther writes:
Constructors are allowed, but PODs are often passed more efficiently.
That property seemed particularly important for double_int.
>>>
>>> Show us the difference in timing. Show us the generated code. I
>>> can't imagine that it could ever matter.
>>
>> I'm also
Mike Stump writes:
>> Constructors are allowed, but PODs are often passed more efficiently.
>> That property seemed particularly important for double_int.
>
> Show us the difference in timing. Show us the generated code. I
> can't imagine that it could ever matter.
I'm also curious about that s
Michael Matz writes:
> Bikeshedding: please settle on consistent naming, either IS, or HAS or _P.
> (FWIW, I suggest _P).
"IS" and "HAS" have different meanings...
-miles
--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware
Robert Dewar writes:
> On 7/2/2012 8:35 AM, Alexandre Oliva wrote:
>> On Jun 30, 2012, David Edelsohn wrote:
>>> IBM's policy specifies a comma:
>>
>>> ,
>>
>>> and not a dash range.
>>
>> But this notation already means something else in our source tree.
>
> I think using the dash is preferable
Magnus Fromreide writes:
> Two spaces for members is common practice with GNU, and it seems to be
> used for libstdc++.
>
> One space for protection labels is not something I have heard of before
> and libstdc++ uses no indentation for them.
>
> A freshly started emacs also doesn't indent access l
Gabriel Dos Reis writes:
> if this coding standard is going to be adopted as a GNU coding
> convention, then you have to be flexible and allow yourself to see
> beyond the past written in C. You have to ask yourself: how do I
> want the codebase to look like in 10, 15, 20, 25 years.
Er, sure, bu
NightStrike writes:
> You wouldn't use the GNU C Coding conventions to write in tcl, and you
> shouldn't use them to write in C++. You should just create the GNU
> C++ Coding Standards new, and not base them off of the former.
... r, just use some common sense, and change things which need
c
Paolo Carlini writes:
> in case my message ends up garbled, the carets do not point to &&
> (column 13), two times point to b (column 20), which is obviously
> wrong. In other terms, all the columns are 20, all wrong.
The new caret support does seem to have revealed a bunch of places
where the co
Jonathan Wakely writes:
How about "...; suggest adding the using keyword"?
>>>
>>> That sounds like the compiler is suggesting that the user suggests
>>> doing that!
>>
>> It is similar to "suggest parentheses ...".
>
> Good point, that's not correct English either, but it would be consistent
BTW, is there a reason that C1X _Alignas is supported, but not C++11
alignas? Is the latter harder?
Thanks,
-Miles
--
Generous, adj. Originally this word meant noble by birth and was rightly
applied to a great multitude of persons. It now means noble by nature and is
taking a bit of a rest.
18 matches
Mail list logo
