Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:ijeil4$2aso$3...@digitalmars.com...
spir wrote:
Having to constantly explain that "_t" means type, that "size" does not
mean size, what this type is supposed to mean instead, what it is used
for in core and stdlib functionality, and
Am 15.02.2011 19:10, schrieb bearophile:
> Daniel Gibson:
>
>> void main() {
>>size_t x;
>>writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and
>> the "real" type is shown. uint in your case. (Here - gdc on am
"Jens Mueller" wrote in message
news:mailman.1694.1297781518.4748.digitalmar...@puremagic.com...
>
> I read that the compiler is free to return whatever name of an alias,
> i.e. either the name of the alias or the name of the thing it was
> aliased to (which can be again an alias). I do not under
"Walter Bright" wrote in message
news:ijeil4$2aso$3...@digitalmars.com...
> spir wrote:
>> Having to constantly explain that "_t" means type, that "size" does not
>> mean size, what this type is supposed to mean instead, what it is used
>> for in core and stdlib functionality, and what programm
"bearophile" wrote in message
news:ijefj9$25sm$1...@digitalmars.com...
> Daniel Gibson:
>
>> void main() {
>>size_t x;
>>writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and
>> the "real" type is shown. uint i
On 02/15/2011 03:25 PM, Daniel Gibson wrote:
Am 15.02.2011 15:18, schrieb spir:
On 02/15/2011 02:01 PM, Daniel Gibson wrote:
Am 15.02.2011 12:50, schrieb spir:
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vot
On Tue, 15 Feb 2011 14:15:06 -0500, Rainer Schuetze
wrote:
I think David has raised a good point here that seems to have been lost
in the discussion about naming.
Please note that the C name of the machine word integer was usually
called "int". The C standard only specifies a minimum b
On 02/15/2011 08:05 PM, Walter Bright wrote:
foobar wrote:
1. that size_t is inconsistent with D's style guide. the "_t" suffix is a C++
convention and not a D one. While it makes sense for [former?] C++
programmers it will confuse newcomers to D from other languages that would
expect the langua
I disagree that the discussion is pointless.
On the contrary, the OP pointed out some valid points:
1. that size_t is inconsistent with D's style guide. the "_t" suffix is
a C++ convention and not a D one. While it makes sense for [former?] C++
programmers it will confuse newcomers to D from
I think David has raised a good point here that seems to have been lost
in the discussion about naming.
Please note that the C name of the machine word integer was usually
called "int". The C standard only specifies a minimum bit-size for the
different types (see for example
http://www.eric
foobar wrote:
1. that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ convention and not a D one. While it makes sense for [former?] C++ programmers it will confuse newcomers to D from other languages that would expect the language to follow its own style guide.
It's a C
spir wrote:
Having to constantly explain that "_t" means type, that "size" does not
mean size, what this type is supposed to mean instead, what it is used
for in core and stdlib functionality, and what programmers are supposed
to use it for... isn't this a waste of our time? This, only because
Daniel Gibson:
> void main() {
>size_t x;
>writefln(typeof(x).stringof);
> }
> try this, too ;-)
>
> Because it's an alias the information about size_t gone at runtime and
> the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's
> ulong).
I think both typeof() and str
Steven Schveighoffer Wrote:
> On Tue, 15 Feb 2011 09:26:21 -0500, spir wrote:
>
> > On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:
>
> >>
> >> Hey, bikeshedders, I found this cool easter-egg feature in D! It's
> >> called
> >> alias! Don't like the name of something? Well you can change
== Quote from dsimcha (dsim...@yahoo.com)'s article
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
> of code to compile in 64 mode. Frankly, the compiler is way too freakin'
> pedantic when it comes to implicit conversions (or lack thereof) of
> array.length. 99.
spir wrote:
> On 02/15/2011 02:01 PM, Daniel Gibson wrote:
> >Am 15.02.2011 12:50, schrieb spir:
> >>On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
> >>>spir wrote:
> Rename size-t, or rather introduce a meaningful standard alias? (would
> vote for Natural)
> >>>
> >>>Maybe ptrint and ptruin
On Tue, 15 Feb 2011 09:26:21 -0500, spir wrote:
On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:
Hey, bikeshedders, I found this cool easter-egg feature in D! It's
called
alias! Don't like the name of something? Well you can change it!
alias size_t wordsize;
Now, you can use wordsiz
Am 15.02.2011 15:18, schrieb spir:
On 02/15/2011 02:01 PM, Daniel Gibson wrote:
Am 15.02.2011 12:50, schrieb spir:
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
I
spir wrote:
> press play
Since size_t is an alias, you wouldn't see it's name anywhere
except the source code.
On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:
On Mon, 14 Feb 2011 20:58:17 -0500, Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather int
On 02/15/2011 02:01 PM, Daniel Gibson wrote:
Am 15.02.2011 12:50, schrieb spir:
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
If ptr means pointer, then it's wrong
Sometimes I think we should troll the users a little and make
a release with names like so:
alias size_t
TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;
alias ptrdiff_t
TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;
a
On Mon, 14 Feb 2011 20:58:17 -0500, Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for N
spir wrote:
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while
Am 15.02.2011 11:30, schrieb spir:
On 02/15/2011 02:58 AM, Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather introduce a meaningful standard ali
Am 15.02.2011 12:50, schrieb spir:
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess.
On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
If ptr means pointer, then it's wrong: size-t is used for more than that, I
guess. Strangely enough, while "size" may
On 02/15/2011 06:51 AM, Walter Bright wrote:
Andrej Mitrovic wrote:
The question is then do you want to be more consistent with the
language (abolish size_t and make something nicer), or be consistent
with the known standards (C99 ISO, et all.).
I'd vote for a change, but I know it will never h
On 02/15/2011 05:50 AM, Andrej Mitrovic wrote:
The question is then do you want to be more consistent with the
language (abolish size_t and make something nicer), or be consistent
with the known standards (C99 ISO, et all.).
I'd vote for a change, but I know it will never happen (even though it
On 02/15/2011 03:26 AM, Jonathan M Davis wrote:
On Monday, February 14, 2011 18:19:35 Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1655.1297736016.4748.digitalmar...@puremagic.com...
I believe that t is for type. The same goes for types such as time_t. The
size
part
On 02/15/2011 03:11 AM, Don wrote:
Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would vote
for Natu
On 02/15/2011 02:58 AM, Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for Natural)
Why?
On 02/15/2011 02:55 AM, Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:ijcm8d$1lf5$1...@digitalmars.com...
"spir" wrote in message
news:mailman.1648.1297732015.4748.digitalmar...@puremagic.com...
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for
On 02/15/2011 02:28 AM, Jonathan M Davis wrote:
On Monday, February 14, 2011 17:06:43 spir wrote:
On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
Here's something I've noticed (x86 code):
void main()
{
ulong size = 2;
i
On 2011-02-15 01:08, Walter Bright wrote:
dsimcha wrote:
Now that DMD has a 64-bit beta available, I'm working on getting a
whole bunch
of code to compile in 64 mode. Frankly, the compiler is way too freakin'
pedantic when it comes to implicit conversions (or lack thereof) of
array.length. 99.99
Andrej Mitrovic wrote:
The question is then do you want to be more consistent with the
language (abolish size_t and make something nicer), or be consistent
with the known standards (C99 ISO, et all.).
I'd vote for a change, but I know it will never happen (even though it
just might not be too la
Nick Sabalausky wrote:
I've been aware of size_t for years and still
don't have the slightest clue WTF that "t" means.
A _t postfix in C is a common convention to signify that an identifier is a
type.
Actually, the more I think about it the more I realize it was kind of a
corner case. Basically, in the two programs that were a royal PITA to
convert to 64-bit, I was storing arrays of indices into other arrays.
This needed to be reasonably memory-efficient. There is no plausible
way that any
The question is then do you want to be more consistent with the
language (abolish size_t and make something nicer), or be consistent
with the known standards (C99 ISO, et all.).
I'd vote for a change, but I know it will never happen (even though it
just might not be too late if we're not coding fo
The very fact that you didn't have issues with size_t before compiling in 64
bit mode seems like a short-coming of D. It should be hard to write code that
isn't platform independent. One would kind of hope that size_t was a distinct
type that could have uints assigned to them without casts. It m
"Jonathan M Davis" wrote in message
news:mailman.1657.1297736740.4748.digitalmar...@puremagic.com...
> On Monday, February 14, 2011 18:19:35 Nick Sabalausky wrote:
>> "Jonathan M Davis" wrote in message
>> news:mailman.1655.1297736016.4748.digitalmar...@puremagic.com...
>>
>> > I believe that t
spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)
Maybe ptrint and ptruint?
On Monday, February 14, 2011 18:19:35 Nick Sabalausky wrote:
> "Jonathan M Davis" wrote in message
> news:mailman.1655.1297736016.4748.digitalmar...@puremagic.com...
>
> > I believe that t is for type. The same goes for types such as time_t. The
> > size
> > part of the name is probably meant to
"Jonathan M Davis" wrote in message
news:mailman.1655.1297736016.4748.digitalmar...@puremagic.com...
>
> I believe that t is for type. The same goes for types such as time_t. The
> size
> part of the name is probably meant to be short for either word size or
> pointer
> size.
>
> Personally, I
Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
On Monday, February 14, 2011 17:06:43 spir wrote:
Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for Natural)
Why? size_t is what's used in
On Monday, February 14, 2011 17:58:17 Nick Sabalausky wrote:
> "Jonathan M Davis" wrote in message
> news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
>
> > On Monday, February 14, 2011 17:06:43 spir wrote:
> >> Rename size-t, or rather introduce a meaningful standard alias? (would
"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
> On Monday, February 14, 2011 17:06:43 spir wrote:
>>
>> Rename size-t, or rather introduce a meaningful standard alias? (would
>> vote
>> for Natural)
>
> Why? size_t is what's used in C++. It'
"Nick Sabalausky" wrote in message
news:ijcm8d$1lf5$1...@digitalmars.com...
> "spir" wrote in message
> news:mailman.1648.1297732015.4748.digitalmar...@puremagic.com...
>>
>> Rename size-t, or rather introduce a meaningful standard alias? (would
>> vote for Natural)
>>
>
> My bikeshed is paint
"spir" wrote in message
news:mailman.1648.1297732015.4748.digitalmar...@puremagic.com...
> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
>> On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
>>> Here's something I've noticed (x86 code):
>>>
>>> void main()
>>> {
>>> ulong size =
On Monday, February 14, 2011 17:06:43 spir wrote:
> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
> > On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
> >> Here's something I've noticed (x86 code):
> >>
> >> void main()
> >> {
> >>
> >> ulong size = 2;
> >> int[] arr = new
On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
Here's something I've noticed (x86 code):
void main()
{
ulong size = 2;
int[] arr = new int[](size);
}
This will error with:
sizetTest.d(8): Error: cannot implicitly convert e
auto, size_t, foreach & friends.
Once we get a stable 64bit compiler it's time to start advertising the
portability of D apps across 32/64bit, methinks! ;)
On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
> Here's something I've noticed (x86 code):
>
> void main()
> {
> ulong size = 2;
> int[] arr = new int[](size);
> }
>
> This will error with:
> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
> type ulong
Andrej Mitrovic wrote:
Here's something I've noticed (x86 code):
void main()
{
ulong size = 2;
int[] arr = new int[](size);
}
This will error with:
sizetTest.d(8): Error: cannot implicitly convert expression (size) of
type ulong to uint
size_t is aliased to uint since I'm running 32bit
Here's something I've noticed (x86 code):
void main()
{
ulong size = 2;
int[] arr = new int[](size);
}
This will error with:
sizetTest.d(8): Error: cannot implicitly convert expression (size) of
type ulong to uint
size_t is aliased to uint since I'm running 32bit.
I'm really not experie
dsimcha wrote:
Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
of code to compile in 64 mode. Frankly, the compiler is way too freakin'
pedantic when it comes to implicit conversions (or lack thereof) of
array.length. 99.999% of the time it's safe to assume an arr
On Monday, February 14, 2011 15:22:38 dsimcha wrote:
> Now that DMD has a 64-bit beta available, I'm working on getting a whole
> bunch of code to compile in 64 mode. Frankly, the compiler is way too
> freakin' pedantic when it comes to implicit conversions (or lack thereof)
> of array.length. 99
Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
of code to compile in 64 mode. Frankly, the compiler is way too freakin'
pedantic when it comes to implicit conversions (or lack thereof) of
array.length. 99.999% of the time it's safe to assume an array is not going
t
101 - 158 of 158 matches
Mail list logo
