This shows many pitfalls regarding conversion of 32 bit code to 64, some of
them are relevant for D code too:
http://www.gamedev.net/reference/articles/article2767.asp
On 32 bit D systems this compiles with no errors, while on 64 bit D this
probably requires a cast:
size_t foo() { return -1; }
On 8/16/10, bearophile wrote:
> So I think size_t=>uint may require a cast on 32
> bit systems too, so when the code gets compiled with the 64 bit dmd this
> error isn't present.
I don't think that's a good idea because of what you say later in your
post: the cast punches a hole through the syste
So I think size_t=>uint may require a cast on 32 bit systems too,
so when the code gets compiled with the 64 bit dmd this error isn't
present.
Well just make size_t a typedef instead of an alias.
On Aug 16, 10 23:19, Trass3r wrote:
So I think size_t=>uint may require a cast on 32 bit systems too,
so when the code gets compiled with the 64 bit dmd this error isn't
present.
Well just make size_t a typedef instead of an alias.
Isn't typedef being deprecated?
On Mon, 16 Aug 2010 09:40:15 -0500, bearophile
wrote:
This shows many pitfalls regarding conversion of 32 bit code to 64, some
of them are relevant for D code too:
http://www.gamedev.net/reference/articles/article2767.asp
Thanks for sharing this article bearophile. It's actually pretty go
Here are some other articles about problems with 32bit>64bit porting if
anyone is interested:
http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-arithmetic.html&lang=en&content=64-bit-development
http://www.viva64.com/content/articles/64-bit-development/?f=TrapsDetection.html&lang
And some more:
http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-migration-7-steps.html&lang=en&content=64-bit-development
http://www.viva64.com/content/articles/64-bit-development/?f=20_issues_of_porting_C++_code_on_the_64-bit_platform.html&lang=en&content=64-bit-development
On
Isn't typedef being deprecated?
Which brings us back to the task of augmenting the library-based
alternative.
I already started 2 threads about this.
On Aug 17, 10 04:30, Trass3r wrote:
Isn't typedef being deprecated?
Which brings us back to the task of augmenting the library-based
alternative.
I already started 2 threads about this.
Or size_t and ptrdiff_t could be made to be built-in types. (?)
Or size_t and ptrdiff_t could be made to be built-in types. (?)
There's no justification for that.
A proper way to define a strong typedef on the other hand is something
that is really needed.
On Aug 17, 10 05:34, Trass3r wrote:
Or size_t and ptrdiff_t could be made to be built-in types. (?)
There's no justification for that.
A proper way to define a strong typedef on the other hand is something
that is really needed.
If size_t is a library-defined strong typedef instead of alias,
On 17-ago-10, at 09:56, KennyTM~ wrote:
On Aug 17, 10 05:34, Trass3r wrote:
Or size_t and ptrdiff_t could be made to be built-in types. (?)
There's no justification for that.
A proper way to define a strong typedef on the other hand is
something
that is really needed.
If size_t is a lib
If size_t is a library-defined strong typedef instead of alias, what
type should .sizeof return?
Hmm good point, I don't know how it is handled currently.
On Aug 17, 10 22:07, Trass3r wrote:
If size_t is a library-defined strong typedef instead of alias, what
type should .sizeof return?
Hmm good point, I don't know how it is handled currently.
Currently, .sizeof returns a uint, and size_t is defined as
alias typeof(int.sizeof) size_t;
ins
14 matches
Mail list logo
