https://issues.dlang.org/show_bug.cgi?id=22827
Nick Treleaven changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=22827
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=22827
mhh changed:
What|Removed |Added
CC||maxha...@gmail.com
--- Comment #3 from mhh ---
The
https://issues.dlang.org/show_bug.cgi?id=22827
--- Comment #2 from Dlang Bot ---
dlang/dmd pull request #13730 "Issue 22827 - Deprecate 128-bit cent and ucent
types" was merged into master:
- e89ab5b838e2cbee1a96916cb97fe125309a4951 by Iain Buclaw:
Issue 22827 - Deprecate 12
https://issues.dlang.org/show_bug.cgi?id=22827
--- Comment #1 from Dlang Bot ---
@ibuclaw created dlang/dmd pull request #13730 "Issue 22827 - Deprecate 128-bit
cent and ucent types" mentioning this issue:
- Issue 22827 - Deprecate 128-bit cent and ucent types
https://github.com/dlan
https://issues.dlang.org/show_bug.cgi?id=22827
Issue ID: 22827
Summary: Deprecate 128-bit cent and ucent types
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority
never have cent or ucent unless someone forks it and continues to
work on it, in which case, they can do whatever they want with it. But the
official D1 compiler will never have cent or ucent, so there's no reason to
worry about them for D1.
--
Configure issuemail: http://d.puremagic.com/issues
from Stewart Gordon s...@iname.com 2012-11-21 15:29:46 PST ---
(In reply to comment #33)
Closing since fixed on D2. Doesn't make sense for D1.
How do you mean???
As of the end of this year, D1 will no longer be supported, so it will
definitely never have cent or ucent unless someone forks
about to be officially unsupported. So, it's not all that surprising if it
has some rough edges anyway. And all that this means is that there are two
words that no one using D1 can use - cent and ucent. That's far from a disaster
and really not worth our time to worry about IMHO. Also note
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #32 from Stewart Gordon s...@iname.com 2012-11-13 05:14:49 PST ---
(In reply to comment #31)
Closing since fixed on D2. Doesn't make sense for D1.
How do you mean???
--
Configure issuemail:
|D1 |D2
Resolution||FIXED
Summary|(D1 only) Make 'cent' and |Make 'cent' and 'ucent'
|'ucent' syntactically valid |syntactically valid pending
|pending implementation |implementation
/2e70bcac262e879769f3236a05ce9bc46483a429
Issue 785 - Make 'cent' and 'ucent' syntactically valid pending implementation
This adds just enough of cent and ucent to parse, but fail at the semantic
stage. This allows cent and ucent to be used inside version and static if
blocks.
https://github.com/D-Programming-Language/dmd/commit
http://d.puremagic.com/issues/show_bug.cgi?id=785
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Version|D1 D2 |D1
--- Comment #30 from
#28 from ponce alil...@gmail.com 2012-04-23 13:15:23 PDT ---
I have a mostly working software implementation for cent and ucent.
https://github.com/p0nce/gfm/blob/master/math/softcent.d
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
Le 29/01/2012 02:17, Alex Rønne Petersen a écrit :
Are there any current plans to implement cent and ucent?
I implemented cent and ucent as a library, using division algorithm from
Ian Kaplan.
https://github.com/p0nce/gfm/blob/master/math/softcent.d
Suggestions welcome.
On 31 January 2012 18:47, Marco Leise marco.le...@gmx.de wrote:
Am 31.01.2012, 16:07 Uhr, schrieb Stewart Gordon smjg_1...@yahoo.com:
On 30/01/2012 16:00, Timon Gehr wrote:
On 01/30/2012 03:59 AM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #20 from Andrei Alexandrescu and...@metalanguage.com 2012-02-01
00:58:00 PST ---
Focus, that's what we lose.
1. There's no real request for cent and ucent.
2. This let's add a filler doing nothing, discuss it ad nauseam
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #21 from yebblies yebbl...@gmail.com 2012-02-01 20:12:24 EST ---
With respect, Andrei, it's my time to waste.
A lot more time has been wasted on arguing about it than the 5 minutes it took
for me to make a patch that fixed it.
128
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #22 from Andrei Alexandrescu and...@metalanguage.com 2012-02-01
01:17:09 PST ---
It's great you want to work on this. It's this particular patch that I have
difficulty backing: it future proofs code that doesn't exist, for a feature
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #23 from Stewart Gordon s...@iname.com 2012-02-01 04:21:17 PST ---
(In reply to comment #20)
2. This let's add a filler doing nothing, discuss it ad nauseam, and consider
implement later is an utter waste of time. If someone really
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #24 from Stewart Gordon s...@iname.com 2012-02-01 04:36:09 PST ---
Moreover, when we finally get the types, there will still be users on older
compilers (DM or third-party, possibly commercial), even some on platforms for
which an
on different backends, may choose not to
implement cent/ucent, and if they do this in the parser then the code will be
non-portable. The proposed patch is a much more correct solution to this
problem.
Regardless, there is a patch for this issue already out there which is waiting
for review. I
On 30/01/2012 16:00, Timon Gehr wrote:
On 01/30/2012 03:59 AM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
On 29/01/2012 01:17, Alex Rønne Petersen wrote:
Hi,
Are there any current plans to implement cent and ucent?
snip
Whether it's implemented any time soon or not, it's high time the _syntax_ allowed their
use as basic types for forward/backward compatibility's sake.
http://d.puremagic.com
Am 31.01.2012, 16:07 Uhr, schrieb Stewart Gordon smjg_1...@yahoo.com:
On 30/01/2012 16:00, Timon Gehr wrote:
On 01/30/2012 03:59 AM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort
On 31/01/2012 18:47, Marco Leise wrote:
snip
pragma(msg, real.sizeof);
Prints 10u for me (2.057, Win32).
Prints the expected platform alignment for me:
DMD64 / GDC64: 16LU
DMD32: 12LU
That isn't alignment, that's padding built into the type. I assume you're testing on
Linux. I've heard
On 1/31/2012 4:28 PM, Stewart Gordon wrote:
That isn't alignment, that's padding built into the type. I assume you're
testing on Linux. I've heard before that long double/real is 12 bytes under
Linux because it includes 2 bytes of padding. I don't know why Linux does it
that way, but there you
On 1/30/2012 9:06 AM, Marco Leise wrote:
On the x86 architecture, most compilers implement long double as the 80-bit
extended precision type supported by that hardware (sometimes stored as 12 or 16
bytes to maintain data structure alignment).
That's all there is to know I think.
10 bytes on
...@gmx.com
--- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-31 10:10:02
PST ---
I agree with Walter on this one. cent and ucent are merely keywords in
preparation for if/when we decide to add 128-bit integer types to the language.
Keywords are plenty for that. I see no reason to expect any
http://d.puremagic.com/issues/show_bug.cgi?id=785
Andrei Alexandrescu and...@metalanguage.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #9 from Stewart Gordon s...@iname.com 2012-01-31 16:05:30 PST ---
(In reply to comment #7)
I agree with Walter on this one. cent and ucent are merely
keywords in preparation for if/when we decide to add 128-bit
integer types
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #11 from Stewart Gordon s...@iname.com 2012-01-31 16:52:39 PST ---
(In reply to comment #10)
This is not an enhancement request.
I still don't understand that statement in the slightest.
It is a possible future feature that we
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #12 from Walter Bright bugzi...@digitalmars.com 2012-01-31
16:54:48 PST ---
The point of doing this is to enable libraries to support cent/ucent _if_ the
language/compiler/platform supports it, by using a static if to test whether
.
Sorry, I only now see how that might be confusing. I was referring to
implement cent/ucent, as opposed to this particular patch.
Let's leave this closed and focus on more workable action items.
Thanks!
OK. But please note that Walter himself hasn't commented on this in over 4
years now
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #14 from Stewart Gordon s...@iname.com 2012-01-31 17:29:40 PST ---
(In reply to comment #12)
The point of doing this is to enable libraries to support cent/ucent _if_ the
language/compiler/platform supports it, by using a static
CC||yebbl...@gmail.com
Resolution|WONTFIX |
--- Comment #15 from yebblies yebbl...@gmail.com 2012-02-01 14:14:35 EST ---
I actually think this is something worth asking for.
I intend to have a go at implementing cent and ucent once I
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #16 from Walter Bright bugzi...@digitalmars.com 2012-01-31
19:20:29 PST ---
Not bad, but they should be in TypeBasic.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #17 from yebblies yebbl...@gmail.com 2012-02-01 14:26:05 EST ---
(In reply to comment #16)
Not bad, but they should be in TypeBasic.
I know, but TypeBasic doesn't have a custom semantic routine and has no support
for 128bit types,
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #18 from Walter Bright bugzi...@digitalmars.com 2012-01-31
19:53:30 PST ---
Yes, it would be a blocker.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because:
http://d.puremagic.com/issues/show_bug.cgi?id=785
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||patch
On 1/29/2012 10:39 PM, H. S. Teoh wrote:
Interesting. How would D fare in that kind of environment, I wonder? I
suppose it shouldn't be a big deal, since you have to custom rewrite
everything anyways -- just use int32 throughout.
You could write a custom D compiler for it.
On 01/30/2012 03:59 AM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
Really?! Ugh. Hopefully D handles it better?
Am 30.01.2012, 03:59 Uhr, schrieb H. S. Teoh hst...@quickfur.ath.cx:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
Really?! Ugh.
On Mon, Jan 30, 2012 at 05:00:22PM +0100, Timon Gehr wrote:
On 01/30/2012 03:59 AM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of
On 30/01/12 18:06, Marco Leise wrote:
Am 30.01.2012, 03:59 Uhr, schrieb H. S. Teoh hst...@quickfur.ath.cx:
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of
to optimize code. I think such optimizations are not
performed on library-defined numbers like a Fixed!128 or BigInt. This
means there are advantages of having cent/ucent/BigInt as built-ins.
Yes, but the advantages in implementation ease and portability currently
favour a library solution.
Do
On Sunday, January 29, 2012 16:26:02 Timon Gehr wrote:
long long is 64-bit on 64-bit linux.
Are you sure? I'm _certain_ that we looked at this at work when we were
sorting issue with moving some of our products to 64-bit and found that long
long was 128 bits. Checking...
Well, you're right.
On Sun, Jan 29, 2012 at 02:26:55PM -0800, Jonathan M Davis wrote:
[...]
This is one of the many reasons why I think that any language which
didn't define integers according to their _absolute_ size instead of
relative size (with the possible exception of some types which vary
based on the
On Sunday, January 29, 2012 15:31:57 H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 02:26:55PM -0800, Jonathan M Davis wrote:
[...]
This is one of the many reasons why I think that any language which
didn't define integers according to their _absolute_ size instead of
relative size (with the
On 29-01-2012 23:26, Jonathan M Davis wrote:
On Sunday, January 29, 2012 16:26:02 Timon Gehr wrote:
long long is 64-bit on 64-bit linux.
Are you sure? I'm _certain_ that we looked at this at work when we were
sorting issue with moving some of our products to 64-bit and found that long
long
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
On 1/29/2012 3:31 PM, H. S. Teoh wrote:
Yeah, size_t especially drives me up the wall. Is it %u, %lu, or %llu?
I think either gcc or C99 actually has a dedicated printf format for
size_t, except that C++ doesn't include parts of C99, so you end up with
format string #ifdef nightmare no matter
On Sunday, January 29, 2012 17:57:39 Walter Bright wrote:
On 1/29/2012 3:31 PM, H. S. Teoh wrote:
Yeah, size_t especially drives me up the wall. Is it %u, %lu, or %llu?
I think either gcc or C99 actually has a dedicated printf format for
size_t, except that C++ doesn't include parts of C99,
On 1/29/2012 4:30 PM, Jonathan M Davis wrote:
But there are
definitely arguments for having an integral type which is the most efficient for
whatever machine that it's compiled on, and D doesn't really have that. You'd
probably have to use something like c_long if you really wanted that.
I
On Sun, Jan 29, 2012 at 06:23:33PM -0800, Walter Bright wrote:
[...]
C has varying size for builtin types and fixed size for aliases. D is
just the reverse - fixed builtin sizes and varying alias sizes. My
experience with both languages is that D's approach is far superior.
I agree. It's not
On Sun, Jan 29, 2012 at 05:57:39PM -0800, Walter Bright wrote:
On 1/29/2012 3:31 PM, H. S. Teoh wrote:
Yeah, size_t especially drives me up the wall. Is it %u, %lu, or %llu?
I think either gcc or C99 actually has a dedicated printf format for
size_t, except that C++ doesn't include parts of
On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
long double is 128-bit.
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
Really?! Ugh. Hopefully D handles it better?
T
--
One disk to rule them all, One disk
On 29 January 2012 22:26, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Sunday, January 29, 2012 16:26:02 Timon Gehr wrote:
long long is 64-bit on 64-bit linux.
Are you sure? I'm _certain_ that we looked at this at work when we were
sorting issue with moving some of our products to 64-bit
On 30 January 2012 03:17, Iain Buclaw ibuc...@ubuntu.com wrote:
On 29 January 2012 22:26, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Sunday, January 29, 2012 16:26:02 Timon Gehr wrote:
long long is 64-bit on 64-bit linux.
Are you sure? I'm _certain_ that we looked at this at work when we
On 1/29/2012 6:46 PM, H. S. Teoh wrote:
Not to mention the totally non-commital way the specs were written about
wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it *could* be
a non-unicode encoding, we don't guarantee anything. Oh, you want
Unicode, right? Well for that you need to
H. S. Teoh hst...@quickfur.ath.cx wrote in message
news:mailman.172.1327892267.25230.digitalmar...@puremagic.com...
Sort of. It's 80 bits of useful data with 48 bits of unused padding.
Really?! Ugh. Hopefully D handles it better?
No. D has to be abi compatible.
On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
On 1/29/2012 6:46 PM, H. S. Teoh wrote:
Not to mention the totally non-commital way the specs were written
about wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it
*could* be a non-unicode encoding, we don't guarantee
On 1/29/2012 8:21 PM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
I've had people tell me this was an advantage because there are some
chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it
awesome that the C standard supports that?
Is there
On Sun, Jan 29, 2012 at 09:24:48PM -0800, Walter Bright wrote:
On 1/29/2012 8:21 PM, H. S. Teoh wrote:
On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
I've had people tell me this was an advantage because there are some
chips where chars, shorts, ints, and wchars are all 32
Hi,
Are there any current plans to implement cent and ucent? I realize no
current processors support 128-bit integers natively, but I figure they
could be implemented the same way 64-bit integers are on 32-bit machines.
I know I could use std.bigint, but there's no good way to declare
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message
news:jg26nr$29bh$1...@digitalmars.com...
Hi,
Are there any current plans to implement cent and ucent? I realize no
current processors support 128-bit integers natively, but I figure they
could be implemented the same way 64-bit
a Fixed!128 or BigInt. This means
there are advantages of having cent/ucent/BigInt as built-ins.
Alternatively in theory special annotations are able to tell the compiler that
a user-defined type shares some of the characteristics of integer numbers,
allowing the compiler to optimize better
or BigInt. This
means there are advantages of having cent/ucent/BigInt as built-ins.
Yes, but the advantages in implementation ease and portability currently
favour a library solution.
Do the gcc or llvm backends support 128 bit integers?
Alternatively in theory special annotations are able
are not
performed on library-defined numbers like a Fixed!128 or BigInt. This
means there are advantages of having cent/ucent/BigInt as built-ins.
Yes, but the advantages in implementation ease and portability currently
favour a library solution.
Do the gcc or llvm backends support 128 bit
on library-defined numbers like a Fixed!128 or BigInt. This
means there are advantages of having cent/ucent/BigInt as built-ins.
Yes, but the advantages in implementation ease and portability currently
favour a library solution.
Do the gcc or llvm backends support 128 bit integers?
Can't speak
gcc does on 64-bit systems. long long is 128-bit on 64-bit Linux. I don't
know about llvm, but it's supposed to be gcc-compatible, so I assume that
it's the same.
- Jonathan M Davis
Can't speak for GCC, but LLVM allows arbitrary-size integers. SDC maps
cent/ucent to i128.
- Alex
On 1/28/2012 8:24 PM, Daniel Murphy wrote:
That's good news. I can't find any information about int128_t in 32 bit
gcc, but if the support is already there then it's just the dmd backend that
need to be upgraded.
There is some support for 128 bit ints already in the backend, but it is
On Saturday, January 28, 2012 20:41:38 Walter Bright wrote:
There is some support for 128 bit ints already in the backend, but it is
incomplete. It's a bit low on the priority list.
Gotta love the pun there, intended or otherwise... :)
- Jonathan M Davis
Walter Bright newshou...@digitalmars.com wrote in message
news:jg2im4$30qi$1...@digitalmars.com...
There is some support for 128 bit ints already in the backend, but it is
incomplete. It's a bit low on the priority list.
Walter Bright newshou...@digitalmars.com wrote in message
news:jg2im4$30qi$1...@digitalmars.com...
There is some support for 128 bit ints already in the backend, but it is
incomplete. It's a bit low on the priority list.
No rush. The backend is still a mystery to me.
On 1/28/2012 9:20 PM, Daniel Murphy wrote:
The backend is still a mystery
Better call Nancy Drew!
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #6 from Stewart Gordon s...@iname.com 2009-09-09 01:08:15 PDT ---
(In reply to comment #5)
Created an attachment (id=447) [details]
Basic frontend support for cent/ucent.
I've attached a simple patch which implements basic
http://d.puremagic.com/issues/show_bug.cgi?id=785
--- Comment #5 from Jeremie Pelletier jerem...@gmail.com 2009-09-08 17:04:01
PDT ---
Created an attachment (id=447)
Basic frontend support for cent/ucent.
I've attached a simple patch which implements basic support for cent/ucent to
the dmd
78 matches
Mail list logo
