I've started looking at D yesterday and what caught my attention is the fact that primitives have properties (int.sizeof, int.init, etc), which is a deviation from C/C++. I understand that this is just a slight difference in syntax, but I don't understand the rationale behind it. If double and int and such are really just primitive types, then why make them look like class instances (at a glance it might look like they're real objects on the heap, which is totally inefficient for such a simple thing)? I think C got it right with a separate sizeof operator. Besides, I don't see a compelling reason for this change so why do it in the first place?

Marcin wrote:

>I've started looking at D yesterday and what caught my attention is the fact
>that primitives have properties (int.sizeof, int.init, etc), which is a
>deviation from C/C++. I understand that this is just a slight difference in
>syntax, but I don't understand the rationale behind it. If double and int
>and such are really just primitive types, then why make them look like class
>instances (at a glance it might look like they're real objects on the heap,
>which is totally inefficient for such a simple thing)? I think C got it
>right with a separate sizeof operator. Besides, I don't see a compelling
>reason for this change so why do it in the first place?
>  
>
Two thing I like about the D way is:
1) it groups like terms under one roof. 2) if you use intellisense this type of thing will *eventually* be able to be picked up.

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:ca82na$tpk$1@digitaldaemon.com...

> Two thing I like about the D way is:
> 1) it groups like terms under one roof.
> 2) if you use intellisense this type of thing will *eventually* be able
> to be picked up.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

Yes they are grouped, but does it make sense for every type to have the same properties? The generic way is to provide a single operator that works on each type, and doing so reinforces the fact that primitives are infact simple ol' data types. The intellisense argument doesn't hold water either because built in keywords should be commited to memory anyway. So is there a rationale behind this change?

Marcin wrote:

>The intellisense argument doesn't hold water either
>because built in keywords should be commited to memory anyway. So is there a
>rationale behind this change?
>  
>
This is an argument not to have have intellisense at all.  Intellisense is a great learning tool.

-- 
-Anderson: http://badmama.com.au/~anderson/

Marcin wrote:

> I've started looking at D yesterday and what caught my attention is the fact
> that primitives have properties (int.sizeof, int.init, etc), which is a
> deviation from C/C++. I understand that this is just a slight difference in
> syntax, but I don't understand the rationale behind it. If double and int
> and such are really just primitive types, then why make them look like class
> instances (at a glance it might look like they're real objects on the heap,
> which is totally inefficient for such a simple thing)? I think C got it
> right with a separate sizeof operator. Besides, I don't see a compelling
> reason for this change so why do it in the first place?

It makes types more interchangeable when templates come into play. Template authors can rely on that interface when their template arguments may or may not be primitive types, and everything works out nicely.

 -- andy

Marcin wrote:

> I've started looking at D yesterday and what caught my attention is the fact
> that primitives have properties (int.sizeof, int.init, etc), which is a
> deviation from C/C++. I understand that this is just a slight difference in
> syntax, but I don't understand the rationale behind it. If double and int
> and such are really just primitive types, then why make them look like class
> instances (at a glance it might look like they're real objects on the heap,
> which is totally inefficient for such a simple thing)?

It's not meant to look like a class instance with instance properties, it's meant to look like a class (a type) with static properties.

If you pretend that the primitive types begin with capital letters, it might feel a bit more consistent e.g. Int.sizeof.

James McComb

You kids with your intellisense, spoiled is what you are ;).  Why in my day we had to program with punch cards ... in the snow ... uphill.

Charlie

In article <ca84r7$10u4$2@digitaldaemon.com>, J Anderson says...
>
>Marcin wrote:
>
>>The intellisense argument doesn't hold water either
>>because built in keywords should be commited to memory anyway. So is there a
>>rationale behind this change?
>> 
>>
>This is an argument not to have have intellisense at all.  Intellisense is a great learning tool.
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

Ha! You wo' pampered. We didn't have punched cards. They'd 'ave been a luxury. We programmed by punches.



"Charlie" <Charlie_member@pathlink.com> wrote in message news:ca8l81$1p7j$1@digitaldaemon.com...
> You kids with your intellisense, spoiled is what you are ;).  Why in my day we had to program with punch cards ... in the snow ... uphill.
>
> Charlie
>
> In article <ca84r7$10u4$2@digitaldaemon.com>, J Anderson says...
> >
> >Marcin wrote:
> >
> >>The intellisense argument doesn't hold water either
> >>because built in keywords should be commited to memory anyway. So is there a
> >>rationale behind this change?
> >>
> >>
> >This is an argument not to have have intellisense at all.  Intellisense is a great learning tool.
> >
> >-- 
> >-Anderson: http://badmama.com.au/~anderson/
>
>

Bah!  Punches?  We didn't even have fists! (And we were thankful for it too)

I remember when we had to write our applciations to tape using a magnet and a paperclip.  And compared to the clay tablets we used to use, it was a godsend!

..

On the serious side:

Marcin called them primitive "properties"...?  Personally, I've always thought of these as more like 'metadata' that only really exists at compilation.  They couple aspects of a given type to the language in a way that C/C++ simply cannot; hence why there is no mountain of global vars anddefines like "MAX_INT".

That way, an errant #undefine or missing #include can't, doesn't and won't ever cripple compilation of your program in D.

Walter, thank you for putting such an insightful feature into this wonderful language.

- Eric

In article <ca8lcv$1pd9$1@digitaldaemon.com>, Matthew says...
>
>Ha! You wo' pampered. We didn't have punched cards. They'd 'ave been a luxury. We programmed by punches.
>
>
>
>"Charlie" <Charlie_member@pathlink.com> wrote in message news:ca8l81$1p7j$1@digitaldaemon.com...
>> You kids with your intellisense, spoiled is what you are ;).  Why in my day we had to program with punch cards ... in the snow ... uphill.
>>
>> Charlie
>>
>> In article <ca84r7$10u4$2@digitaldaemon.com>, J Anderson says...
>> >
>> >Marcin wrote:
>> >
>> >>The intellisense argument doesn't hold water either
>> >>because built in keywords should be commited to memory anyway. So is there a
>> >>rationale behind this change?
>> >>
>> >>
>> >This is an argument not to have have intellisense at all.  Intellisense is a great learning tool.
>> >
>> >-- 
>> >-Anderson: http://badmama.com.au/~anderson/
>>
>>
>
>

"Marcin" <sixpackguy@earthlink.net> wrote in message news:ca7ue0$na8$1@digitaldaemon.com...
> I've started looking at D yesterday and what caught my attention is the
fact
> that primitives have properties (int.sizeof, int.init, etc), which is a deviation from C/C++. I understand that this is just a slight difference
in
> syntax, but I don't understand the rationale behind it. If double and int and such are really just primitive types, then why make them look like
class
> instances (at a glance it might look like they're real objects on the
heap,
> which is totally inefficient for such a simple thing)? I think C got it right with a separate sizeof operator. Besides, I don't see a compelling reason for this change so why do it in the first place?

Take a look at the C #include files <limits.h> and <float.h>, the arbitrary and inconsistent names used therein, and the brittle dependencies on just the right preprocessor #ifdef's, and I think you'll agree that having the compiler do it is more consisent, reliable, and less prone to mismatching the wrong type with the wrong macro.

Consider, for example, DBL_DIG.

    printf("The number of digits in a float is %d\n", DBL_DIG);

Oops! Should have been FLT_DIG. In D, it's easier to get right the first time:

    printf("The number of digits in a float is %d\n", float.dig);

Now, what do you do with a typedef for a floating point type:

C:
    void foo(my_floating_point_type x)
    {
#if SIZEOF_MYTYPE == SIZEOF_FLOAT
          printf("The number of digits in my_floating_point_type is %d\n",
FLT_DIG);
#elif if SIZEOF_MYTYPE == SIZEOF_DOUBLE
          printf("The number of digits in my_floating_point_type is %d\n",
DBL_DIG);
 #elif SIZEOF_MYTYPE == SIZEOF_LONGDOUBLE
         printf("The number of digits in my_floating_point_type is %d\n",
LDBL_DIG);
#else
#error "goofed up the macros"
#endif
    }

Consider that you cannot use a sizeof(expression) in a preprocessor expression, so you're reduced to making a slew of macros for the sizeof's that are non-portable. Next, as happens on some architectures, sizeof(double)==sizeof(long double), which of course causes the above brittle construction to fail. Thirdly, it fails again if the compiler acquires a 4th floating point type.


D:

    void foo(my_floating_point_type x)
    {
          printf("The number of digits in my_floating_point_type is %d\n",
my_floating_point_type.dig);
    }

Which would you rather type in, which looks better, and which is more portable?