www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why do primitives have properties?

reply "Marcin" <sixpackguy earthlink.net> writes:
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?
Jun 09 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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?
  

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/
Jun 09 2004
parent reply "Marcin" <sixpackguy earthlink.net> writes:
"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?
Jun 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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?
  

is a great learning tool. -- -Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent reply Charlie <Charlie_member pathlink.com> writes:
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?
  

is a great learning tool. -- -Anderson: http://badmama.com.au/~anderson/

Jun 09 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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?

is a great learning tool. -- -Anderson: http://badmama.com.au/~anderson/


Jun 09 2004
parent EricAnderton at yahoo dot com <EricAnderton_member pathlink.com> writes:
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?

is a great learning tool. -- -Anderson: http://badmama.com.au/~anderson/



Jun 10 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
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
Jun 09 2004
prev sibling next sibling parent James McComb <alan jamesmccomb.id.au> writes:
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
Jun 09 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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

 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

 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

 instances (at a glance it might look like they're real objects on the

 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?
Jun 11 2004