Sean Kelly wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
One could argue that gcc has them as an extension but nobody uses them.
My experience with adding extensions to DM C++ is that nobody uses them
because it is non-standard, not because they are a bad idea.
And
Walter Bright wrote:
Nested functions do closures in a straightforward way, so by leaving off
nested functions they were forced to make an ugly syntax . This is
why I shake my head in just not understanding the process that led to
their design.
Well, one problem would be that nested function
Leandro Lucarella wrote:
GCC support them as an extension to C for ages too.
True for nested functions but nested functions are not blocks.
typedef void (*foo_t)(void);
foo_t getSomeFunc()
{
int x = 4;
void bar(void) {
printf("%d\n", x);
}
return
Walter Bright wrote:
S. wrote:
I find it strange that people are continuing to reinvent nested
functions in ugly ways.
The blocks are not nested functions, they are more like closures. There
are some block copy functions that move a block to the heap (including
the captured variables).
Nes
Kagamin wrote:
NICTA announced the completion of the world’s first formal machine-checked
proof of a general-purpose operating system kernel, promising safety-critical
software of unprecedented levels of reliability.
Yes, sort of what they proved was that the implementation was inline
with t
Robert Fraser wrote:
Eljay wrote:
Is there ANY use case where you'd need a 256-bit integer instead of a
BigInteger? Even 128 is a bit dodgy. UUIDs and what not are identifiers,
not numbers, so have no problem being stored in a struct wrapping a
ubyte[].
Fixed point arithmetic!!!
Seriously,
Beer is the same in all languages!
Swedish: öl.
That word has the same root as the English word "ale". But it is not
very specific in Swedish. A more slang-like word that you will easily
remember is "bira" or "bärs" that obviously derive from the word beer
(or the original root of the word
Bitfields in Phobos are defined portably: always populated from lsb to
msb, the total size must be 8, 16, 32, or 64, and there is no hidden
padding (you obtain padding with anonymous fields).
Andrei
If this is the case, the bitfields are not portable and the behaviour is
the same as for GCC,
Except that bitfields don't appear to be a widely used feature.
You clearly have not written systems code in Ada... :)
C-bitfields are problematic because the bit-ordering is implementation
defined, GCC have the bits appear in the order of definition on
big-endian machines and the reverse ord
I think that the following would work reasonably well:
allow the [] operator for arrays to take comma separated lists of
indices.
So the OpenCL like statement:
v.xyzw = v2.wzyx;
will be written as:
v[0,1,2,3] = v2[3,2,1,0];
Would this be ok? This is a general extensi
On 2009-02-21 17:03:06 +0100, Don said:
I don't think that's messy at all. I can't see much difference between
special support for float[4] versus float4. It's better if the code can
take advantage of hardware without specific support. Bear in mind that
SSE/SSE2 is a temporary situation. AVX
Yeah, this is good statistics and does point out that the vector
add/mul/permute stuff are used whenever vectors are in use.
Intrinsics is one thing, however, better would be platform independent stuff.
Altivec have a different syntax for the permute instructions than the SSE
shuffle instructio
On 2009-02-19 21:04:06 +0100, Bill Baxter said:
To justify making them primitive types you need to show that they are
widespread, and that there is some good reason that they cannot be
implemented in a library. And even if they can't be implemented in a
library right now, it could be that fixin
Since (SIMD) vectors are so common and every reasonabe system support
them in one way or the other (and scalar emulation of this is rather
simple), why not have support for this in D directly?
Yes, the array operations are nice (and one of the main reasons for why
I like D :) ), but have the p
14 matches
Mail list logo
