On Wednesday, 3 April 2013 at 14:54:03 UTC, Steven Schveighoffer
wrote:
On Wed, 03 Apr 2013 07:33:05 -0400, Don
turnyourkidsintoc...@nospam.com wrote:
Yeah, but I think that what this is, is demonstrating what a
useful concept a positive integer type is. There's huge value
in statically
On Tuesday, 2 April 2013 at 09:43:37 UTC, Jonathan M Davis wrote:
Naturally, the biggest reason to have size_t be unsigned is so
that you can
access the whole address space
Length exists to limit access to memory. If you want unlimited
access, use just a pointer.
For some people though, it
On Thursday, April 04, 2013 15:20:26 Kagamin wrote:
I'm afraid, those applications are not tied to 32-bit ints. They
just want a lot of memory because they have a lot of data. It
means they want more than 4 gigs, so uint won't help in the
slightest: it can't address more than 4 gigs, and
On 4/2/2013 8:10 PM, Steven Schveighoffer wrote:
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright newshou...@digitalmars.com
wrote:
For example, with a signed array index, a bounds check is two comparisons
rather than one.
Why?
struct myArr
{
int length;
int opIndex(int idx) {
I'm afraid, a factor of 2 is too small. If an application needs
gigabytes, you'll have hard time trying to convince it to not use
more than 4 gigs. Or more specifically between 2 and 4 gigs.
Your examples don't specify if those applications needed large
contiguous allocations (which is
On Thu, 04 Apr 2013 15:10:28 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/2/2013 8:10 PM, Steven Schveighoffer wrote:
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
For example, with a signed array index, a bounds check is two
BTW don't we already have a hungry application *with* unsigned
integers?
http://d.puremagic.com/issues/show_bug.cgi?id=4236
http://d.puremagic.com/issues/show_bug.cgi?id=6498
http://d.puremagic.com/issues/show_bug.cgi?id=3719
http://d.puremagic.com/issues/show_bug.cgi?id=4984 - and who
On Thursday, April 04, 2013 21:39:35 Kagamin wrote:
BTW don't we already have a hungry application *with* unsigned
integers?
http://d.puremagic.com/issues/show_bug.cgi?id=4236
http://d.puremagic.com/issues/show_bug.cgi?id=6498
http://d.puremagic.com/issues/show_bug.cgi?id=3719
On Friday, 5 April 2013 at 01:26:27 UTC, Jonathan M Davis wrote:
But I would point out that the bugs that you listed are not at
really related
to this discussion. They're about dmd running out of memory
when compiling,
and it's running out of memory not because it needs 64-bit to
have enough
On Wednesday, 3 April 2013 at 03:26:54 UTC, Andrei Alexandrescu
wrote:
On 4/2/13 11:10 PM, Steven Schveighoffer wrote:
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/2/2013 12:47 PM, Andrei Alexandrescu wrote:
I used to lean a lot more toward this
On Tue, 02 Apr 2013 23:26:54 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/2/13 11:10 PM, Steven Schveighoffer wrote:
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/2/2013 12:47 PM, Andrei Alexandrescu wrote:
I used to lean
On Wed, 03 Apr 2013 07:33:05 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
Yeah, but I think that what this is, is demonstrating what a useful
concept a positive integer type is. There's huge value in statically
knowing that the sign bit is never negative. Unfortunately, using uint
On Thursday, 28 March 2013 at 20:03:08 UTC, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP
addresses in a database as a uint. For some reason though, some
addresses were coming out as 0.0.0.0, despite the fact that
if(ip == 0) return; in the only place it actually
On Tuesday, 2 April 2013 at 07:49:04 UTC, Don wrote:
[cut]
IMHO, array.length is *the* place where unsigned does *not*
work. size_t should be an integer. We're not supporting 16 bit
systems, and the few cases where a size_t value can potentially
exceed int.max could be disallowed.
The
On Tuesday, April 02, 2013 09:49:03 Don wrote:
On Thursday, 28 March 2013 at 20:03:08 UTC, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP
addresses in a database as a uint. For some reason though, some
addresses were coming out as 0.0.0.0, despite the fact that
On Tuesday, 2 April 2013 at 08:29:41 UTC, renoX wrote:
On Tuesday, 2 April 2013 at 07:49:04 UTC, Don wrote:
[cut]
IMHO, array.length is *the* place where unsigned does *not*
work. size_t should be an integer. We're not supporting 16 bit
systems, and the few cases where a size_t value can
Don:
But very often, people use 'uint' when they really want an int,
whose sign bit is zero.
Sometimes you need the modular nature of unsigned values, and
some other times you just need an integer that according to the
logic of the program never gets negative and you want the full
range of
On Friday, 29 March 2013 at 19:29:21 UTC, Jonathan M Davis wrote:
No. -w makes it so that warnings are errors, so you generally
can't make
anything a warning unless you're willing for it to be treated
as an error at
least some of the time (and a lot of people compile with -w),
and this sort of
On Tuesday, 2 April 2013 at 09:43:37 UTC, Jonathan M Davis wrote:
On Tuesday, April 02, 2013 09:49:03 Don wrote:
On Thursday, 28 March 2013 at 20:03:08 UTC, Adam D. Ruppe
wrote:
I was working on a project earlier today that stores IP
addresses in a database as a uint. For some reason though,
On 4/2/13 3:49 AM, Don wrote:
IMHO, array.length is *the* place where unsigned does *not* work. size_t
should be an integer. We're not supporting 16 bit systems, and the few
cases where a size_t value can potentially exceed int.max could be
disallowed.
The problem with unsigned is that it gets
On 4/2/2013 12:47 PM, Andrei Alexandrescu wrote:
I used to lean a lot more toward this opinion until I got to work on a C++
codebase using signed integers as array sizes and indices. It's an pain all over
the code - two tests instead of one or casts all over, more cases to worry
about...
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/2/2013 12:47 PM, Andrei Alexandrescu wrote:
I used to lean a lot more toward this opinion until I got to work on a
C++
codebase using signed integers as array sizes and indices. It's an pain
all over
On 4/2/13 11:10 PM, Steven Schveighoffer wrote:
On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/2/2013 12:47 PM, Andrei Alexandrescu wrote:
I used to lean a lot more toward this opinion until I got to work on
a C++
codebase using signed integers as
On Friday, 29 March 2013 at 05:34:07 UTC, Kagamin wrote:
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis
wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned)
to the
language, as bearophile suggests?
It's not
I vaguely remember Walter said those diagnostics are mostly false
positives. Though I don't remember whether if was about implicit
conversions.
I can say C compilers bug me with InterlockedIncrement function:
it can be called on both volatile and non-volatile variables so
type qualification of argument can't always match that of
parameter and the compiler complains. I found that silly.
Kagamin:
I vaguely remember Walter said those diagnostics are mostly
false positives. Though I don't remember whether if was about
implicit conversions.
I agree several of them seem innocuous.
Bye,
bearophile
On Friday, 29 March 2013 at 19:29:21 UTC, Jonathan M Davis wrote:
because if it
doesn't, you're forced to cast all over the place
There are so many implicit conversions between signed and
unsigned? Are they all ok?
Kagamin:
Jonathan M Davis wrote:
because if it
doesn't, you're forced to cast all over the place
There are so many implicit conversions between signed and
unsigned? Are they all ok?
I think Jonathan doesn't have enough proof that forbidding
signed-unsigned implicit casts in D is worse
On Saturday, March 30, 2013 22:12:30 bearophile wrote:
Kagamin:
Jonathan M Davis wrote:
because if it
doesn't, you're forced to cast all over the place
There are so many implicit conversions between signed and
unsigned? Are they all ok?
I think Jonathan doesn't have enough proof
Jonathan M Davis:
Walter is the one that you have to convince, and I don't think
that that's ever going to happen.
I understand. But maybe Walter too don't have that proof... I
compile C code with all warnings, and the compiler tells me most
cases of mixing signed with unsigned. I usually
On 3/28/2013 6:17 PM, Jonathan M Davis wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to the
language, as bearophile suggests?
It's not terribly pretty, but you can always do this:
On Thursday, March 28, 2013 23:10:18 Walter Bright wrote:
On 3/28/2013 6:17 PM, Jonathan M Davis wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to the
language, as bearophile suggests?
It's not terribly pretty,
Am 29.03.2013 02:28, schrieb Adam D. Ruppe:
Part of why I did it this way was the annoyance that I can't do a
variadic template in an interface. I'd REALLY prefer to do it that way
so there wouldn't be a list of types at all - just plain to!string(foo).
Who says you can't ? In fact you can
On Friday, 29 March 2013 at 09:26:33 UTC, Benjamin Thaut wrote:
Who says you can't ? In fact you can using the NVI idiom:
Is that fairly new in D? I'm almost certain I tried it and it
didn't work when I originally wrote this code (which was a couple
years ago).
But it'd be worth redoing it
On Friday, March 29, 2013 13:10:02 Adam D. Ruppe wrote:
On Friday, 29 March 2013 at 09:26:33 UTC, Benjamin Thaut wrote:
Who says you can't ? In fact you can using the NVI idiom:
Is that fairly new in D? I'm almost certain I tried it and it
didn't work when I originally wrote this code (which
Consider:
uint u = ...;
int x = u;
Wouldn't a warning be enough?
Am 29.03.2013 13:10, schrieb Adam D. Ruppe:
Is that fairly new in D? I'm almost certain I tried it and it didn't
work when I originally wrote this code (which was a couple years ago).
Yes it's fairly new. I think dmd 2.060 or something along that line. I
tend to use it a lot because its so
On Friday, March 29, 2013 17:27:10 Minas Mina wrote:
Consider:
uint u = ...;
int x = u;
Wouldn't a warning be enough?
No. -w makes it so that warnings are errors, so you generally can't make
anything a warning unless you're willing for it to be treated as an error at
least some of the
Am 29.03.2013 20:29, schrieb Jonathan M Davis:
No. -w makes it so that warnings are errors, so you generally can't make
anything a warning unless you're willing for it to be treated as an error at
least some of the time (and a lot of people compile with -w), and this sort of
thing is _supposed_
On Friday, 29 March 2013 at 19:38:32 UTC, Benjamin Thaut wrote:
2) The library needs something like an int_cast which checks
casts from one integer type to another and asserts / throws on
error.
uint value = 3408924;
auto v = std.conv.to!int(value);
Exception is thrown if an overflow
If you remove the implicit uint==int assignment from D you
have to add many cast() in the code. And casts are dangerous,
maybe even more than implicit casts.
On the other hand I have not tried D with such change, so that's
just an hypothesis. And maybe a library-defined
toSigned()/toUnsigned()
I was working on a project earlier today that stores IP addresses
in a database as a uint. For some reason though, some addresses
were coming out as 0.0.0.0, despite the fact that if(ip == 0)
return; in the only place it actually saves them (which was my
first attempted quick fix for the bug).
On 28-03-2013 21:03, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP addresses in a
database as a uint. For some reason though, some addresses were coming
out as 0.0.0.0, despite the fact that if(ip == 0) return; in the only
place it actually saves them (which was my
On Thu, 28 Mar 2013 21:03:07 +0100
Adam D. Ruppe destructiona...@gmail.com wrote:
which then got truncated by the database,
While I won't necessarily disagree with the rest, that right there is
the real WTF. A database that silently alters data is unreliable,
and therefore fundamentally broken
On Thursday, 28 March 2013 at 21:29:55 UTC, Nick Sabalausky wrote:
Is this MySQL, by any chance?
Yes, and no on strict mode, I didn't even know it had one!
Adam D. Ruppe:
if (arg == typeid(uint)) {
int e = va_arg!uint(_argptr);
a = to!string(e);
}
See, I copy/pasted it from the int check, but didn't update the
type on the left hand side. So it correctly pulled a uint out
of the varargs, but then assigned it to an int, which the
On 03/28/2013 09:03 PM, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP addresses in a
database as a uint. For some reason though, some addresses were coming
out as 0.0.0.0, despite the fact that if(ip == 0) return; in the only
place it actually saves them (which was
On Thu, Mar 28, 2013 at 09:03:07PM +0100, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP addresses in
a database as a uint. For some reason though, some addresses were
coming out as 0.0.0.0, despite the fact that if(ip == 0) return; in
the only place it actually
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to the
language, as bearophile suggests?
It's not terribly pretty, but you can always do this
auto foo = cast(Unsigned!(typeof(var))var;
or
auto bar =
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
It's not terribly pretty, but you can always do this
We could also do more C++ looking:
unsigned_cast!foo or IFTI or whatever;
On Friday, March 29, 2013 02:19:49 Adam D. Ruppe wrote:
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
It's not terribly pretty, but you can always do this
We could also do more C++ looking:
unsigned_cast!foo or IFTI or whatever;
It would be pretty trivial to add a
On Thursday, 28 March 2013 at 22:12:57 UTC, H. S. Teoh wrote:
Also, I don't like repeating types, precisely for this reason;
if that second line had been written:
Yeah, I usually don't either, but apparently I did here. Murphy's
law at work perhaps!
On Thursday, 28 March 2013 at 21:58:05 UTC, bearophile wrote:
I didn't write a Bugzilla request to remove the implicit
uint==int assignment. (I think the signed-unsigned comparisons
are more dangerous than those signed-unsigned assignments. But
maybe too is a problem with no solution).
Oh
On Thursday, 28 March 2013 at 22:04:36 UTC, Timon Gehr wrote:
- Copypasta edit instead of string mixins / static foreach.
Part of why I did it this way was the annoyance that I can't do a
variadic template in an interface. I'd REALLY prefer to do it
that way so there wouldn't be a list of
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to
the
language, as bearophile suggests?
It's not terribly pretty, but you can always do this
auto foo =
56 matches
Mail list logo
