www.digitalmars.com         C & C++   DMDScript  

D - D safety and simplicity?

reply Rex Couture "spamdump" <auser levee.wustl.edu> writes:
Will you permit some questions and observations from a D newbie-to-be?  (Well,
maybe it's a soapbox or a challenge, but you can decide.)  I'm thinking of using
D, and I like what I see so far.  Still, I have some fundamental questions that
I think are essential measures of the quality of a programming language.  I
think most of the answers are "right", but I'd rather hear them from this
community.

1. Is it safe?  By that I mean, is it completely type-safe, even across compiled
modules?  Are memory violations possible?  Is pointer arithmetic allowed?  Is
the compiler capable of ensuring that all the rules of the language are
followed?  Are array subscript bounds always checked at run time?  (I will allow
that maybe it is necessary to turn this off in rare instances for lengthy
computations.  And yes, I know, probably nothing is completely safe.)

It seems to me that if memory and type violations are possible, they will occur.
Your own programs will not be as reliable as they could be, and if you use a
second- or third-party library, you can never be sure it won't crash and leave
you with the wreckage.


2. Is it simple?  I really like the philosophy of simplicity espoused on the
home page.  Maybe I'm mistaken, but I think I detect a certain pressure for
creeping featuritis.  If I can violate the rule against programming religion, I
would say, please, please keep the language simple.  All-powerful, but as simple
as possible.  And resist dialects at all costs.  My support goes to those of you
who have consistently advocated simplicity.

Please permit me some observations, if you will.  Programming is only part of my
job.  Although I'm not a professional programmer, as such, my programs have to
be right, and have to give the right answers, or I'm out of business.

My preferred language so far is Pascal -- you heard me right.  It's not without
problems, but when I started writing in Pascal, Fortran could not do the job,
and C++ was vaporware.  I also judged C and C++ to be dangerous, and apparently
the creators of D agree.  The interesting thing is that my very first, crude
Pascal program (about 1700 lines + communications libraries) has performed
complicated instrument-control functions flawlessly, day and night, for 15+
years.  (Well, actually, two errors surfaced during that time, but only two.)  I
can't remember ever writing a program with a memory violation (and yes, I use
pointers and OOP), and my programs almost always work right with little
debugging.  I attribute success not to programming prowess, but to the
simplicity and clarity of the language.

I would like to pass on one other observation.  There is a programmer who has
been using Component Pascal (an Oberon variant) extensively for a few years.
(I'm not really advocating that, for irrelevant reasons.)  The compiler and
environment are written in the same language.  The point is that he claims that
he has made just about every kind of mistake possible, including dangling
pointers, subtle type conversion errors -- you name it -- but he has not had a
single crash.  Maybe some infinite loops or other errors, but no memory
violations or type errors.

The $64 question:  can you match the simplicity and safety?  Please tell me you
can!
Jul 26 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Rex Couture spamdump" <auser levee.wustl.edu> wrote in message
news:ahrvec$2tdm$1 digitaldaemon.com...

 Will you permit some questions and observations from a D newbie-to-be?


Sure! Fire away.


 1. Is it safe?  By that I mean, is it completely type-safe, even across


compiled

 modules?


Yes.


  Are memory violations possible?  Is pointer arithmetic allowed?


Yes, and yes.


  Is
 the compiler capable of ensuring that all the rules of the language are
 followed?


No, although I try to note these areas in the spec.


  Are array subscript bounds always checked at run time?


No, it is enabled/disabled with a compiler switch. D requires that programs
not be coded in such a manner that they *depend* on array bounds checking
(this is different from Java).


 It seems to me that if memory and type violations are possible, they will


occur.

 Your own programs will not be as reliable as they could be, and if you use


a

 second- or third-party library, you can never be sure it won't crash and


leave

 you with the wreckage.


That's correct. On the other hand, D makes it largely unnecessary to use
practices that commonly lead in C to corrupted memory. An example is 'out'
parameters for functions.


 2. Is it simple?  I really like the philosophy of simplicity espoused on


the

 home page.  Maybe I'm mistaken, but I think I detect a certain pressure


for

 creeping featuritis.  If I can violate the rule against programming


religion, I

 would say, please, please keep the language simple.  All-powerful, but as


simple

 as possible.  And resist dialects at all costs.  My support goes to those


of you

 who have consistently advocated simplicity.


Where to draw that line between features and simplicity will make or break
D.


 My preferred language so far is Pascal -- you heard me right.  It's not


without

 problems, but when I started writing in Pascal, Fortran could not do the


job,

 and C++ was vaporware.  I also judged C and C++ to be dangerous, and


apparently

 the creators of D agree.  The interesting thing is that my very first,


crude

 Pascal program (about 1700 lines + communications libraries) has performed
 complicated instrument-control functions flawlessly, day and night, for


15+

 years.  (Well, actually, two errors surfaced during that time, but only


two.)  I

 can't remember ever writing a program with a memory violation (and yes, I


use

 pointers and OOP), and my programs almost always work right with little
 debugging.  I attribute success not to programming prowess, but to the
 simplicity and clarity of the language.


Modula 3 is derived from Pascal. I'd be interested then in your take on a
comparison between M3 and D.


 I would like to pass on one other observation.  There is a programmer who


has

 been using Component Pascal (an Oberon variant) extensively for a few


years.

 (I'm not really advocating that, for irrelevant reasons.)  The compiler


and

 environment are written in the same language.  The point is that he claims


that

 he has made just about every kind of mistake possible, including dangling
 pointers, subtle type conversion errors -- you name it -- but he has not


had a

 single crash.  Maybe some infinite loops or other errors, but no memory
 violations or type errors.
 The $64 question:  can you match the simplicity and safety?  Please tell


me you

 can!


I think that is possible, but only more experience doing large projects in D
will tell for sure.
Jul 26 2002
parent reply Rex Couture <auser levee.wustl.edu writes:
"Rex Couture wrote

  Are memory violations possible?  Is pointer arithmetic allowed?




Walter's reply

Yes, and yes.


I guess it's too late, but I sure like the Java idea of no pointer arithmetic.
Of course, pointers are used, they just don't admit to it.



  Are array subscript bounds always checked at run time?


No, it is enabled/disabled with a compiler switch. D requires that programs
not be coded in such a manner that they *depend* on array bounds checking
(this is different from Java).


Now this is interesting!  How is this possible?  I missed this somehow.




 2. Is it simple?  I really like the philosophy of simplicity espoused on


the

 home page....


Where to draw that line between features and simplicity will make or break
D.


That's hard to say, isn't it?  Good luck!  I don't have any great wisdom here.



 My preferred language so far is Pascal -- you heard me right....  I attribute
success not to programming prowess, but to the
 simplicity and clarity of the language.





Modula 3 is derived from Pascal. I'd be interested then in your take on a
comparison between M3 and D.


I don't know.  Sorry, never tried M3.
It takes an enormous amount of effort to get into a language, with libraries and
all.  Unfortunately, Pascal and derivatives are plagued by dialects and division
of effort, as are all programming languages.


Thanks for your thoughtful reply.
Jul 26 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri=2C 26 Jul 2002 18=3A44=3A36 +0000 =28UTC=29 Rex Couture
=3Causer=40levee=2Ewustl=2Eedu 
wrote=3A

=3E I guess it's too late=2C but I sure like the Java idea of no pointer
arithmetic=2E
=3E Of course=2C pointers are used=2C they just don't admit to it=2E

Pointers =28and arithmetic=29 are necessary for low-level system programming=2E

But well=2C if you want safety=2C do you really =5Fneed=5F pointers=3F You've
got
references to objects - and these don't support arithmetic =28although
one could cast them to byte*=2C and then=2E=2E=2E=29=2C just like Java=2E

=3E=3ENo=2C it is enabled=2Fdisabled with a compiler switch=2E D requires that
programs
=3E=3Enot be coded in such a manner that they *depend* on array bounds checking
=3E=3E=28this is different from Java=29=2E
=3E 
=3E Now this is interesting!  How is this possible=3F  I missed this somehow=2E
 
This means that for debug builds=2C compiler inserts checks to throw
an exception whenever array index is out of bounds=2E However=2C this
is implementation detail=2C and you should NOT rely on it in your
programs - in other words=2C never ever do something like this=3A

=09try
=09=09array=5Bi=5D =3D 666=3B
=09catch =28EOutOfBounds=29
=09=09return=3B
Jul 26 2002
next sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <CFN374639694477315 news.digitalmars.com>, Pavel Minayev says...


Pointers and arithmetic are necessary for low-level system programming.
But well if you want safety do you really need pointers?  You've got
references to objects - and these don't support arithmetic...


Actually, I hope I'm not making enemies here, but all variants of the Oberon
language completely prohibit pointer arithmetic.  Nevertheless, they have been
used extensively for systems programming, and at least two or three operating
systems have been written and ported to several platforms.  The compilers are
also completely written in Oberon.  You can easily verify that pointer
arithmetic is prohibited by searching Google for ' "pointer arithmetic" Oberon
'.  I don't know anything about the convenience of their approach, and they may
use a safe substitute of some sort, but I'm pretty sure that they don't give up
any capability by prohibiting pointer arithmetic.

I don't want to get into an argument about which is better (I don't use Oberon,
but I am considering D, after all), but 's very hard to convince me that pointer
arithmetic is either necessary or safe.  Maybe it's worth considering
alternatives.

I do like the idea of references to objects, which makes possible such
structures as linked lists.  I agree, I would never use pointer arithmetic for
my own software, but I would never be sure about compilers and libraries.

The majority of commercial programs that I own crash from time to time because
of memory violations.  D seems to be a big step in the right direction, but
could it be made even safer?
Jul 26 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 26 Jul 2002 21:25:50 +0000 (UTC) Rex Couture <Rex_member pathlink.com> 
wrote:


 '.  I don't know anything about the convenience of their approach, and they 


may

 use a safe substitute of some sort, but I'm pretty sure that they don't give 


up

 any capability by prohibiting pointer arithmetic.


I guess they just cast pointers to integers, then do arithmetic, then cast back.
At least I did so when writing programs in Borland Pascal, where pointer
arithmetic was forbidden as well. =)

Still I prefer the C way.
 

 I don't want to get into an argument about which is better (I don't use 


Oberon,

 but I am considering D, after all), but 's very hard to convince me that 


pointer

 arithmetic is either necessary or safe.  Maybe it's worth considering
 alternatives.


It is definitely not safe. But as long as you stick with references and
dynamic arrays, you don't even have to remember about this problem.
 

 I do like the idea of references to objects, which makes possible such
 structures as linked lists.  I agree, I would never use pointer arithmetic for
 my own software, but I would never be sure about compilers and libraries.


This would also assume that any program which has parts written in assembler
should not be trusted, nor can you trust OS API calls (because they could
use pointer arithmetic), nor drivers etc etc.

As long as it works correctly, why should I care if it uses pointer arithmetic
or not? It is a dangerous feature, indeed, but it is quite possible - and
not very hard, in fact - to use it properly. At least easier than inline 
assembler.
 

 The majority of commercial programs that I own crash from time to time because
 of memory violations.  D seems to be a big step in the right direction, but
 could it be made even safer?


At a cost of power. For an example of what it could then turn into, see Java.
Jul 27 2002
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <CFN374644754512384 news.digitalmars.com>, Pavel Minayev says...

It is definitely not safe. But as long as you stick with references and
dynamic arrays, you don't even have to remember about this problem.



... It is a dangerous feature, indeed, but it is quite possible - and
not very hard, in fact - to use it properly. At least easier than inline 
assembler.



...This would also assume that any program which has parts written in assembler
should not be trusted, nor can you trust OS API calls (because they could
use pointer arithmetic), nor drivers etc etc.


I don't know much about the question about balance between power and safety, and
it probably seems awfully presumptuous of me to try to influence language
design.  I just think that if mistakes can be made, they will be.  It's the guys
who write my word processor, the guys who write all my security loopholes, the
guys who write my operating systems, etc., that I'm worried about.  Although
they're getting better, a lot of API calls and drivers are actually not very
reliable.  It would be very nice if D were to become the next preferred
language, and would eliminate memory errors forever.  It seems to close.  Inline
assembler will not be used very much.  But if pointer arithmetic is easy, it
will be commonly used, and mistakes will be made.  Are you sure that there isn't
a safe and effective way to avoid pointer arithmetic?

Thanks, Adam Connor, for the pointer to Cyclone.
Jul 29 2002
next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:ai45k0$ffo$1 digitaldaemon.com...

 a safe and effective way to avoid pointer arithmetic?

 Thanks, Adam Connor, for the pointer to Cyclone.


Use dynamic arrays.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jul 29 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 29 Jul 2002 19:38:40 +0000 (UTC) Rex Couture <Rex_member pathlink.com> 
wrote:


 design.  I just think that if mistakes can be made, they will be.  It's the 


guys

Not sure if this is the right approach. I think it is better to state that
"if language requires using dangerous techniques, mistakes will be made".
C does (printf and all). D doesn't. All the code I've written in vanilla D
(no ports etc) so far does not use pointers at all simply because they are
not needed for my tasks. Why would anybody use pointers and PA while there
are better, simpler replacements provided by the language - dynamic arrays,
references, out parameters... I would only use a pointer where I need to -
and just in case I need them, I want them to be there.


 who write my word processor, the guys who write all my security loopholes, the
 guys who write my operating systems, etc., that I'm worried about.  Although


Well I doubt you can write an OS in a completely typesafe language. You'll
simply have to mess with the hardware and other low-level stuff too much
for this to work. You'll get down to asm anyhow, which is far from being safe.


 assembler will not be used very much.  But if pointer arithmetic is easy, it
 will be commonly used, and mistakes will be made.  Are you sure that there 


isn't

I don't understand why somebody would use PA "just because it is there". This
is not a criteria. After all, if somebody writes a program in such a manner,
well, we have free market, right? So you can always find someone who doesn't
abuse dangerous language features just for the sake of it.


 a safe and effective way to avoid pointer arithmetic?


Yes. Just don't use it. =)
Alternatively, something like Cyclone's "fat pointers" could be made. But
they are simply TOO fat, IMHO - making a check every time one subscripts
a pointer!


 Thanks, Adam Connor, for the pointer to Cyclone.


By the way, after taking a look at Cyclone, I've made a decision that it is
The Language I Would Never Ever Use. Nah, I'll beter stick to Delphi and C++
for now, and wait for D to grow mature.

..BTW, Walter, any plans on the next alpha (beta?) release?
Jul 29 2002
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <CFN374670355875694 news.digitalmars.com>, Pavel Minayev says...


...  All the code I've written in vanilla D
(no ports etc) so far does not use pointers at all simply because they are
not needed for my tasks. Why would anybody use pointers and PA while there
are better, simpler replacements provided by the language - dynamic arrays,
references, out parameters... I would only use a pointer where I need to -
and just in case I need them, I want them to be there.



It sounds * very * encouraging that you have never needed pointers or pointer
arithmetic except for porting.

Here's my vision:  D becomes a language of choice, maybe the language of choice.
Millions of lines of code later, and there are no more memory errors.  With
luck, crashes could be a thing of the past.

Please allow me one last impudent suggestion.  If it's dangerous and not needed
except for comptibility (or maybe for some rare, unforseen circumstance), why
not forbid pointer arithmetic by default?  It could be allowed with a switch for
compatibility.

I see Russ Lewis has just posted that suggestion too.  I think it's a great
idea.  Otherwise, a lot of people will probably use old ways out of habit.

I'm also a little concerned that subscript range checking is always turned off
in the final compilation, whether this is really needed or not.  I certainly am
capable of leaving undetected subscript range errors in my programs.




Well I doubt you can write an OS in a completely typesafe language....You'll
get down to asm anyhow, which is far from being safe.


I believe the Oberon OS's and compilers were written entirely in the Oberon
language.  Assembly language was used to write part of the compiler, and the
compiler was then completely rewritten in its own language.  I don't know much
about this, but it certainly sounds like a safe way of operating.  I'm not
certain whether there might be some low-level, relatively unsafe language.
Jul 29 2002
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
P.S.  Thanks to all about being good sports and letting me invade your
discussion group like this and continue to press these questions.  Walter, sorry
to make all these suggestions and not be able to help with coding.
Jul 29 2002
prev sibling next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:ai4ege$pin$1 digitaldaemon.com...


 Please allow me one last impudent suggestion.  If it's dangerous and not


needed

 except for comptibility (or maybe for some rare, unforseen circumstance),


why

 not forbid pointer arithmetic by default?  It could be allowed with a


switch for

 compatibility.


   After all, what are pointers good for?

1- Referencing polymorphic classes.
2- Referencing elements of an array.
3- Converting raw memory into typed memory. Usually used for OS and such
type stuff.
4- Converting memory from one type of object to another.

   Did I forget any?

1- D automatically uses mutable references for polymorphic objects. Not an
issue in D.
2- Could become a "safe" pointer, like an iterator... Or could just use
indices. Not needed in D.
3- This is just a cast. It doesn't need arithmetic, as long as raw memory is
just represented by an integer.

conversion from typed to raw memory.

   The end result is that the only case really needed in D is number 3. And
all of it can be done easily by using integers for addresses, and converting
to/from typed pointers, so pointer arithmetic is definitely not needed. I'll
bet that's how the Oberon compilers and OSs and such do it this way, too. If
you just make the conversion functions nasty enough (like the C++ casts)
that they'll be used only when needed, you'll have the best of all worlds.

   Completely eliminating the possibility of dealing with raw memory makes
system programming impossible. But providing a simple and visible way of
doing it is definitely good enough.

Salutaciones,
                         JCAB
Jul 29 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 29 Jul 2002 16:50:58 -0700 "Juan Carlos Arevalo Baeza" 
<jcab roningames.com> wrote:


    After all, what are pointers good for?
 
 1- Referencing polymorphic classes.


These are covered by object references in D, which don't support arithmetic.


 2- Referencing elements of an array.


You can almost always cast a pointer to a dynamic array, which will
be bounds-checked.
Jul 30 2002
parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676562744097 news.digitalmars.com...


 On Mon, 29 Jul 2002 16:50:58 -0700 "Juan Carlos Arevalo Baeza"
 <jcab roningames.com> wrote:


    After all, what are pointers good for?

 1- Referencing polymorphic classes.


 These are covered by object references in D, which don't support


arithmetic.

   My point exactly. Keep reading ;-)


 2- Referencing elements of an array.


 You can almost always cast a pointer to a dynamic array, which will
 be bounds-checked.


   That sounds like another reasonably good option.

Salutaciones,
                         JCAB
Jul 30 2002
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:ai4k20$10vp$1 digitaldaemon.com...

 "Rex Couture" <Rex_member pathlink.com> wrote in message
 news:ai4ege$pin$1 digitaldaemon.com...

 3- This is just a cast. It doesn't need arithmetic, as long as raw memory


is

 just represented by an integer.

    The end result is that the only case really needed in D is number 3.


And

 all of it can be done easily by using integers for addresses, and


converting

 to/from typed pointers, so pointer arithmetic is definitely not needed.


Making code depend on pointers fitting into integers will cause problems
with portability. For instance, AS/400 has very large pointers that will not
fit into any integral type. Another example is DOS' segmented memory model
where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an
issue anymore, but we might very well see a segmented model again - next
time with 64 bit pointers and 32 bit integers, I suspect. Your solution to
the problem is IMHO bad practice.

Regards,
Martin M. Pedersen
Jul 30 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Martin M. Pedersen" wrote:


 Making code depend on pointers fitting into integers will cause problems
 with portability. For instance, AS/400 has very large pointers that will not
 fit into any integral type. Another example is DOS' segmented memory model
 where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an
 issue anymore, but we might very well see a segmented model again - next
 time with 64 bit pointers and 32 bit integers, I suspect. Your solution to
 the problem is IMHO bad practice.


Yeah, when you absolutely need pointer arithmetic, all other options are just
hacks.  However, we should try to push the language to a point where 99% of the
programs will never need it...

I sincerely hope we've learned our lesson from the segmented memory
nightmare...let's not do that again :(

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jul 30 2002
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ai66ul$2rq1$1 digitaldaemon.com...


 "Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
 news:ai4k20$10vp$1 digitaldaemon.com...


 3- This is just a cast. It doesn't need arithmetic, as long as raw




memory

 is just represented by an integer.


 Making code depend on pointers fitting into integers will cause problems
 with portability. For instance, AS/400 has very large pointers that will


not

 fit into any integral type. Another example is DOS' segmented memory model
 where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an
 issue anymore, but we might very well see a segmented model again - next
 time with 64 bit pointers and 32 bit integers, I suspect. Your solution to
 the problem is IMHO bad practice.


   On the contrary. I wasn't suggesting to make pointers fit any specific
integral type. I was suggesting creating a new integral type that would be
used to represent addresses in raw memory. I'd assume some operations would
be pretty much platform-specific, like separating the segment and offset
parts of it and such, but still it should support the basic arithmetic
operations. And making part of its interface platform-specific doesn't sound
like such a bad idea, as this type of stuff would only be needed for system
work, which is inherently non-portable at its core.

   So, this would be different from C/C++ pointers in general in that this
would be just raw addresses, kind of like a char*. It would not be like a
void*, because it would allow arithmetic. But it would be something similar
at its core.

Salutaciones,
                         JCAB
Jul 30 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Tue, 30 Jul 2002 12:23:18 -0700 "Juan Carlos Arevalo Baeza" 
<jcab roningames.com> wrote:


    So, this would be different from C/C++ pointers in general in that this
 would be just raw addresses, kind of like a char*. It would not be like a
 void*, because it would allow arithmetic. But it would be something similar
 at its core.


Then maybe just allow pointer arithmetic on void* as if it was char*?
I remember someone suggested it before, and it doesn't sound like
a bad idea to me.
Jul 30 2002
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Pavel Minayev wrote:


 On Tue, 30 Jul 2002 12:23:18 -0700 "Juan Carlos Arevalo Baeza" 
 <jcab roningames.com> wrote:
 
 

   So, this would be different from C/C++ pointers in general in that this
would be just raw addresses, kind of like a char*. It would not be like a
void*, because it would allow arithmetic. But it would be something similar
at its core.


 
 Then maybe just allow pointer arithmetic on void* as if it was char*?
 I remember someone suggested it before, and it doesn't sound like
 a bad idea to me.


It's been in a long time.  You can do it in GCC too, and maybe C99.
Jul 30 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374680226337732 news.digitalmars.com...

 On Tue, 30 Jul 2002 12:23:18 -0700 "Juan Carlos Arevalo Baeza"
 <jcab roningames.com> wrote:


    So, this would be different from C/C++ pointers in general in that




this

 would be just raw addresses, kind of like a char*. It would not be like




a

 void*, because it would allow arithmetic. But it would be something




similar

 at its core.


 Then maybe just allow pointer arithmetic on void* as if it was char*?
 I remember someone suggested it before, and it doesn't sound like
 a bad idea to me.


It may have been me.

Did you mean?

 Then maybe just allow pointer arithmetic ONLY on void* ...?


(I'm not syntax checking your gramma. I'm just wondering about the
semantics(meaning)?)

I'm wondering how do you get the datatype from a void* in D and also in C++?

--PS

The two reasons why I don't use D all that much are:

1) No MFC or equivalent OO-control based classes.
2) No editor specific (or as useful) for D as MVS has for Visual C++.

I'm sure this will probably change in the future. And perhaps I'll be able
to help with that (but not at the moment, I've got a hundred assignments,
and an a continual stackoverflow ;) ).
Aug 01 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:aibcpj$9ii$1 digitaldaemon.com...

 --PS

 The two reasons why I don't use D all that much are:

 1) No MFC or equivalent OO-control based classes.
 2) No editor specific (or as useful) for D as MVS has for Visual C++.

 I'm sure this will probably change in the future. And perhaps I'll be able
 to help with that (but not at the moment, I've got a hundred assignments,
 and an a continual stackoverflow ;) ).


--I just thought of something. It's a rhetorical thing for me. If I was to
add MFC support I'd like a good editor, but to build the editor in D I'd
need MFC. (Of course the editor could be developed in C++ (or in D with
win32), and MFC could be added without an editor.)
Aug 01 2002
prev sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson firestar.com.au> wrote:


 Did you mean?

 Then maybe just allow pointer arithmetic ONLY on void* ...?


 (I'm not syntax checking your gramma. I'm just wondering about the
 semantics(meaning)?)


Yes, exactly.
 

 I'm wondering how do you get the datatype from a void* in D and also in C++?


What do you mean, "get the datatype"? You just cast it to whatever it
actually is...
 

 The two reasons why I don't use D all that much are:
 
 1) No MFC or equivalent OO-control based classes.


I'm waiting for the next DMD alpha to continue the development of WinD.
In fact, as soon as I write class Bitmap, I'll release the first alpha.
But, oh well, it's quite different from MFC. =)


 2) No editor specific (or as useful) for D as MVS has for Visual C++.


The bad thing is, M$ doesn't give the SDK for MVS plugins for free.
For now, I've got stick with FAR + Colorer plugin, and wrote a
hilighting scheme for D. Works fine for me. But of course, an
IDE with integrated debugger, project manager, class browser, code
completion etc would be much better. =)
Aug 01 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374700113674769 news.digitalmars.com...

 On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson firestar.com.au>


wrote:

 I'm wondering how do you get the datatype from a void* in D and also in




C++?

 What do you mean, "get the datatype"? You just cast it to whatever it
 actually is...


Say you cast a void * to something else how do you get the previous
datatype? I think it's impossible at the moment (although I'm not sure)
without extra details. You need to data type to know the size of each memory
component in the array at least. Perhaps there should be a special type of
general array or perhaps (for the sake of learnability) something can be
added to void * that is worked out at compile time (ie like a template).
Aug 01 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
Whoops,

Say you cast something to a void * how do you get the previous datatype? I
think it's impossible at the moment (although I'm not sure) without extra
details. You need to data type to know the size of each memory component
in the array at least. Perhaps there should be a special type of general
array or perhaps (for the sake of learnability) something can be added
to void * that is worked out at compile time (ie like a template).
Aug 01 2002
parent Pavel Minayev <evilone omen.ru> writes:
On Fri, 2 Aug 2002 13:09:41 +0800 "anderson" <anderson firestar.com.au> wrote:


 
 Whoops,
 
 Say you cast something to a void * how do you get the previous datatype? I
 think it's impossible at the moment (although I'm not sure) without extra
 details. You need to data type to know the size of each memory component
 in the array at least. Perhaps there should be a special type of general
 array or perhaps (for the sake of learnability) something can be added
 to void * that is worked out at compile time (ie like a template).


Yes, it is impossible now.

Practically, what you're suggesting now is some kind of variant data type,
only it doesn't store the data, but the pointer to it.
Aug 02 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
anderson wrote:


 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374700113674769 news.digitalmars.com...
 

On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson firestar.com.au>


 wrote:
 

I'm wondering how do you get the datatype from a void* in D and also in




 C++?
 

What do you mean, "get the datatype"? You just cast it to whatever it
actually is...


 
 Say you cast a void * to something else how do you get the previous
 datatype? I think it's impossible at the moment (although I'm not sure)
 without extra details. You need to data type to know the size of each memory
 component in the array at least. Perhaps there should be a special type of
 general array or perhaps (for the sake of learnability) something can be
 added to void * that is worked out at compile time (ie like a template).


You should be able to eventually do (using my generics syntax):

     struct Pointer
     {
         TypeInfo type;
         void *data;

         this ($type *data)
         {
             this.type = $type.next;
             this.data = data;
         }
     }

     int x;
     Pointer f = Pointer (&x);

     printf ("%s %d\n", f.type.kind, f.type.tsize);

Which will print "int 4".
Aug 01 2002
prev sibling next sibling parent "anderson" <anderson firestar.com.au> writes:
 not forbid pointer arithmetic by default?  It could be allowed with a


switch for

 compatibility.


<Babble>

dirty code work. Even without pointers and the like, there will still be
memory bugs. If a variable overflows, and the programmer simply tells the
system to reboot/shutdown, then you have rockets falling out of the sky (ie
ADA). In many cases, it's impossible to catch every error but it's possible
to reduce them by forcing the programmer to work a particular way like you
suggest with pointers. However, sometimes the best solution is to a product
that is reasonably bug free and use testing processes and end users to plug
the gaps.

In the defence of pointers. Sometimes pointers can reduce bugs because
things coded may be shorter and more readable. Also a I consider speed a
debugging issue. so for code that is meant to run efficiently but doesn't,
that's a bug. If pointer can solved this issue (most often they don't bring
much of a performance benefit), then that's what I'll use.

--One of the disadvantages of adding more language features to code is that
it gets harder to read. Of course you need to always weight this up against
efficiency, writability and flexibility.
Jul 29 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 29 Jul 2002 22:10:22 +0000 (UTC) Rex Couture <Rex_member pathlink.com> 
wrote:


 Please allow me one last impudent suggestion.  If it's dangerous and not 


needed

 except for comptibility (or maybe for some rare, unforseen circumstance), why
 not forbid pointer arithmetic by default?  It could be allowed with a switch 


for

 compatibility.


I wouldn't ming having something like that. Some sort of a subset of D,
with no pointer arithmetic, available from the compiler by request.


 I'm also a little concerned that subscript range checking is always turned off
 in the final compilation, whether this is really needed or not.  I certainly 


am

 capable of leaving undetected subscript range errors in my programs.


I think there should be a separate switch and/or language statement to
control subscript range checking. Having it on in debug builds, and off
in release builds seems suitable for most coders, but just in case you
also want it in release build, a switch should be there...
Jul 30 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374676588998264 news.digitalmars.com...

 I think there should be a separate switch and/or language statement to
 control subscript range checking. Having it on in debug builds, and off
 in release builds seems suitable for most coders, but just in case you
 also want it in release build, a switch should be there...


It is controllable separately with a compiler switch. The -release switch is
just a combination of the most popular options for a release build. The
point of having it is that it reduces the need for long lists of switches
common for doing a release build in C++. Also, I find many people new to a
compiler find it frustrating to have to decipher complex lists of switches
just to figure out how to get an optimized, release build.
Aug 03 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:ai4ege$pin$1 digitaldaemon.com...

 Please allow me one last impudent suggestion.  If it's dangerous and not


needed

 except for comptibility (or maybe for some rare, unforseen circumstance),


why

 not forbid pointer arithmetic by default? It could be allowed with a


switch for

 compatibility. I see Russ Lewis has just posted that suggestion too.  I


think it's a great

 idea.  Otherwise, a lot of people will probably use old ways out of habit.


One of D's goals is to allow people to continue using their old style so
they can rapidly get up to speed using D. Over time, I expect they'll be
seduced by the D way of doing things, and their coding style will naturally
shift. I know this is how C++ became so popular. Eliminating pointers
completely will significantly raise the barrier to entry to D, enough I feel
to permanently marginalize it.


 I'm also a little concerned that subscript range checking is always turned


off

 in the final compilation, whether this is really needed or not.  I


certainly am

 capable of leaving undetected subscript range errors in my programs.


It would be your choice to leave that on or off in your release code.
Aug 01 2002
prev sibling parent reply Russ Lewis <Russ_member pathlink.com> writes:
In article <ai45k0$ffo$1 digitaldaemon.com>, Rex Couture says...

I don't know much about the question about balance between power and safety, and
it probably seems awfully presumptuous of me to try to influence language
design.  I just think that if mistakes can be made, they will be.  It's the guys
who write my word processor, the guys who write all my security loopholes, the
guys who write my operating systems, etc., that I'm worried about.  Although
they're getting better, a lot of API calls and drivers are actually not very
reliable.  It would be very nice if D were to become the next preferred
language, and would eliminate memory errors forever.  It seems to close.  Inline
assembler will not be used very much.  But if pointer arithmetic is easy, it
will be commonly used, and mistakes will be made.  Are you sure that there isn't
a safe and effective way to avoid pointer arithmetic?


One of the things I'm very excited about is that D includes enough language
features (dynamic arrays, in particular), that pointers are no longer necessary
for the vast majority of programs.

I fully expect that, in the future, D compilers will come with compiler switches
to turn on/turn off pointer arithmetic.  In fact, I believe that in most cases,
POINTER ARITHMETIC OFF will be the DEFAULT OPTION.

For those who still need it (systems programmers, perhaps some very
performance-sensitive game programmers), it will be there, but very few people
will ever use it.
Jul 29 2002
parent "anderson" <anderson firestar.com.au> writes:
"Russ Lewis" <Russ_member pathlink.com> wrote in message
news:ai4als$kro$1 digitaldaemon.com...

 In article <ai45k0$ffo$1 digitaldaemon.com>, Rex Couture says...

I don't know much about the question about balance between power and




safety, and

it probably seems awfully presumptuous of me to try to influence language
design.  I just think that if mistakes can be made, they will be.  It's




the guys

who write my word processor, the guys who write all my security




loopholes, the

guys who write my operating systems, etc., that I'm worried about.




Although

they're getting better, a lot of API calls and drivers are actually not




very

reliable.  It would be very nice if D were to become the next preferred
language, and would eliminate memory errors forever.  It seems to close.




Inline

assembler will not be used very much.  But if pointer arithmetic is easy,




it

will be commonly used, and mistakes will be made.  Are you sure that




there isn't

a safe and effective way to avoid pointer arithmetic?


 One of the things I'm very excited about is that D includes enough


language

 features (dynamic arrays, in particular), that pointers are no longer


necessary

 for the vast majority of programs.

 I fully expect that, in the future, D compilers will come with compiler


switches

 to turn on/turn off pointer arithmetic.  In fact, I believe that in most


cases,

 POINTER ARITHMETIC OFF will be the DEFAULT OPTION.

 For those who still need it (systems programmers, perhaps some very
 performance-sensitive game programmers), it will be there, but very few


people

 will ever use it.


I think most compiler switches should be included in the code itself. That
way each peace of code should run without having to know what complier
switches are needed. This would expecially the case if you wanted to combine
projects/modules. I think there should be a standard on how things are
disabled/enabled in a program. It should be module based so that options
don't effect other modules.

My suggestion is that it could be block based and look something like this.

dEnable(D_POINTER_ARITHMETIC | ...);


dDiable(D_POINTER_ARITHMETIC | ...);

and...

//Parhaps a set command would be better in this particular case
dDisable(D_ALL); //Disables all
dEnable(D_STANDARD); //The d standards


and parhaps complier stacking....

dPushEnable();
dDisable(D_POINTER_ARITHMETIC)

dPopEnable(); //We're finished with it

This code of course would be worked out at compiler time so "if" statement
and the like wouldn't effect it. It would also be able to used in the global
area (anywhere in the code) because for example...

dEnable(D_POINTER_ARITHMETIC);

int *p; ect...

dDisable(D_POINTER_ARITHMETIC);


//This method needs pointers
int func()
{
    dEnable(D_POINTER_ARITHMETIC);

    p = NULL;
    ...

    dDisable(D_POINTER_ARITHMETIC);
}

That's just my thoughts on that matter.
Jul 29 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
Pavel Minayev wrote:


 On Fri, 26 Jul 2002 18:44:36 +0000 (UTC) Rex Couture <auser levee.wustl.edu 
 wrote:
 
 

I guess it's too late, but I sure like the Java idea of no pointer arithmetic.
Of course, pointers are used, they just don't admit to it.


 
 Pointers (and arithmetic) are necessary for low-level system programming.




 But well, if you want safety, do you really _need_ pointers? You've got
 references to objects - and these don't support arithmetic (although
 one could cast them to byte*, and then...), just like Java.



If you don't need them, you're certainly already coding in a style that 
doesn't use them, so this issue is moot.  If you do need them, the 
language provides for it, so this issue is moot.

Cross-type casting is dangerous, and I don't mean just for portability 
reasons.  Consider the nonsense code:

     float g1, g2;

     float foo (int *p)
     {
         float res = g1 + g2;

         *p = 0;
         return res + g1 + g2;
     }

A compiler of C doesn't have to consider that "p" may point to "g1" or 
"g2", so it can freely mix the operation in such a way that it comes out 
all wrong if it does.  Type-based alias optimisations are pretty 
advanced, but they're becoming a reality in some compilers and 
definitely will be important in the future.  The solution is (if p could 
be one of g1 or g2):

     union e
     {
         float f;
         int i;
     }

     float foo (e *p)
     {
         float res = g1 + g2;

         p1->i = 0;
         return res + g1 + g2;
     }

Thus the compiler has to assume that p->f could be g1 or g2.

One way the language can help to keep this from being a problem is to 
prevent casting a pointer to anything but (void *), but allow (void *) 
to be casted to anything you want.  But this kind of error should be 
carefully written to make sure the programmer doesn't think the 
compiler's being gratuitously malicious or that there's no solution (see 
GCC's horrible error messages for longjmp).
Jul 26 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Rex Couture" <auser levee.wustl.edu> wrote in message
news:ahs5ak$2ot$1 digitaldaemon.com...

"Rex Couture wrote

  Are memory violations possible?  Is pointer arithmetic allowed?




 Walter's reply

Yes, and yes.


 I guess it's too late, but I sure like the Java idea of no pointer


arithmetic.

 Of course, pointers are used, they just don't admit to it.


For the most parts, you don't need pointers. You can use
one-dimensional dynamic arrays and object references for
most occasions were you might have used pointers in C/C++.
Also, all member fields of objects and variables are
initialized on instantiation, so there are much smaller
risks of using uninitialized variables.

But when you need pointers, they are there. Also, because
of D's garbage collection, there is no need to free memory,
so much smaller risks of memory leakage. This even works
for pointers you have malloc'ed yourself, so not only for
object references.



  Are array subscript bounds always checked at run time?


No, it is enabled/disabled with a compiler switch. D requires that




programs

not be coded in such a manner that they *depend* on array bounds checking
(this is different from Java).


 Now this is interesting!  How is this possible?  I missed this somehow.


In debug mode arrays are bounds-checked, but this code is
removed in release builds. This ensures that your code will
run at full speed in release mode, while still giving you
an easy way to check your code in debug mode.
The same goes for contracts (Design By Contract), check it
out:  http://www.digitalmars.com/d/ section Contracts.

<SNIP>

 My preferred language so far is Pascal -- you heard me right....  I






attribute success not to programming prowess, but to the

 simplicity and clarity of the language.






I like Pascal too.

<SNIP>


Nice too see more and more people taking an interest in D!


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jul 26 2002
next sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ahsbn4$9ms$1 digitaldaemon.com>, OddesE says...

For the most parts, you don't need pointers. You can use
one-dimensional dynamic arrays and object references for
most occasions were you might have used pointers in C/C++.


That's good news.  I think object references are really pointers by another
name, but they do seem safe.


Also, all member fields of objects and variables are
initialized on instantiation, so there are much smaller
risks of using uninitialized variables.


Oooh!



But when you need pointers, they are there. Also, because
of D's garbage collection, there is no need to free memory,
so much smaller risks of memory leakage. This even works
for pointers you have malloc'ed yourself, so not only for
object references.


Aaah!  :-)



In debug mode arrays are bounds-checked, but this code is
removed in release builds.


Ouch!  I still have legacy Fortran code (my own, unfortunately) that
occasionally violates array bounds after "successful" debugging and years of
use.  Personally, I've never needed to turn off bounds checking, but I
acknowledge that it is necessary to do so for some applications.  One trick that
often can be used, incidentally, is to hand-code bounds checking outside the
loop, so it takes essentially no time.



The same goes for contracts (Design By Contract), check it
out:  http://www.digitalmars.com/d/ section Contracts.


I'll do it.  I'm getting an education here.



 My preferred language so far is Pascal -- you heard me right....






...Nice too see more and more people taking an interest in D!


Well, Pascal-derived languages all have some sort of limitation (like dialects
or missing essentials), and I am definitely considering alternatives for future
development.  There's a lot to like in D.  So far, all languages are a pain in
some way, but I am still hoping for improvements.  By the way, I have given my
share of grief to those Swiss guys too, trying to instigate some improvements.
Occasionally they say I'm right, but it's always too late.

Thanks again to you and Walter and Pavel.
Jul 26 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:ahsg4p$f0k$1 digitaldaemon.com...

 In article <ahsbn4$9ms$1 digitaldaemon.com>, OddesE says...

For the most parts, you don't need pointers. You can use
one-dimensional dynamic arrays and object references for
most occasions were you might have used pointers in C/C++.


 That's good news.  I think object references are really pointers by


another

 name, but they do seem safe.


Pointers which the compiler has complete control over, so it can do more to
ensure they're used safely.  References are pointers minus most of the sharp
nasty dangerous parts.

Those of you who are advocating using dynamic arrays instead of pointer
arithmetic:   Yes that's a step in the right direction (at least the
compiler can verify the validity of the array itself and bounds check the
index) but it doesn't prevent bad indices from occurring.  A lot of pointer
arithmetic is of the iteration form;   p++ or p+=4  instead of the more
risky p2 = p + x;

Adding the iterator concept to the language would eliminate the need for a
whole class of potential uses for pointer arithmetic, and also bypass its
close relative, the indexed array.  Indexing is (potentially) slower
performance than iteration anyway.  When in any doubt whatsoever about the
optimization ability of the compiler, it's better to write for (T* i =
&array[array.size]; --i >= &array[0]; ) *i = 0;  than for (int i =
array.size; --i >=0; ) array[i] = 0; just because the former is effectively
a pre-optimized form of the latter.  An even better optimizer may replace
the whole loop with a block fill (memset).

Just as iteration isn't a good substitute for indexing, indexing isn't a
good substitute for iteration.  True native language iteration allows
elimination of many range checks and safety holes.

Sean
Jul 31 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ai866v$4r0$1 digitaldaemon.com...

 "Rex Couture" <Rex_member pathlink.com> wrote in message
 news:ahsg4p$f0k$1 digitaldaemon.com...

 In article <ahsbn4$9ms$1 digitaldaemon.com>, OddesE says...

For the most parts, you don't need pointers. You can use
one-dimensional dynamic arrays and object references for
most occasions were you might have used pointers in C/C++.


 That's good news.  I think object references are really pointers by


 another

 name, but they do seem safe.


 Pointers which the compiler has complete control over, so it can do more


to

 ensure they're used safely.  References are pointers minus most of the


sharp

 nasty dangerous parts.

 Those of you who are advocating using dynamic arrays instead of pointer
 arithmetic:   Yes that's a step in the right direction (at least the
 compiler can verify the validity of the array itself and bounds check the
 index) but it doesn't prevent bad indices from occurring.  A lot of


pointer

 arithmetic is of the iteration form;   p++ or p+=4  instead of the more
 risky p2 = p + x;

 Adding the iterator concept to the language would eliminate the need for a
 whole class of potential uses for pointer arithmetic, and also bypass its
 close relative, the indexed array.  Indexing is (potentially) slower
 performance than iteration anyway.  When in any doubt whatsoever about the
 optimization ability of the compiler, it's better to write for (T* i =
 &array[array.size]; --i >= &array[0]; ) *i = 0;  than for (int i =
 array.size; --i >=0; ) array[i] = 0; just because the former is


effectively

 a pre-optimized form of the latter.  An even better optimizer may replace
 the whole loop with a block fill (memset).


--Of course memsets can be faster then iteration, but memsets are considered
to be a slow block copying techniqiue (when compared to an ASM version), why
is this so? (I guess it's implementation dependent.)


 Just as iteration isn't a good substitute for indexing, indexing isn't a
 good substitute for iteration.  True native language iteration allows
 elimination of many range checks and safety holes.

 Sean


I agree.
Jul 31 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean L. Palmer wrote:

 Those of you who are advocating using dynamic arrays instead of pointer
 arithmetic:   Yes that's a step in the right direction (at least the
 compiler can verify the validity of the array itself and bounds check the
 index) but it doesn't prevent bad indices from occurring.  A lot of pointer
 arithmetic is of the iteration form;   p++ or p+=4  instead of the more
 risky p2 = p + x;


What about
     char[] a;
     ...
     a = a[1..a.length];

Which is, effectively, pointer arithmetic (with bounds checking, if that 
is turned on)?

You could even create a new property called "next" to do it for you:
     "<array>.next" is defined as "<array>[1..<array>.length]"

And then your array reference works with the same semantics as a 
(non-reversible) iterator :)
Jul 31 2002
parent Burton Radons <loth users.sourceforge.net> writes:
Russell Lewis wrote:


 Sean L. Palmer wrote:
 

 Those of you who are advocating using dynamic arrays instead of pointer
 arithmetic:   Yes that's a step in the right direction (at least the
 compiler can verify the validity of the array itself and bounds check the
 index) but it doesn't prevent bad indices from occurring.  A lot of 
 pointer
 arithmetic is of the iteration form;   p++ or p+=4  instead of the more
 risky p2 = p + x;


 
 
 What about
     char[] a;
     ...
     a = a[1..a.length];


Walter has agreed that:

     a = a[1..];

Is a good idea, and it's already in my port of DMD.  So a next property 
isn't necessary, and IMO it wouldn't be a good name anyway, as it's 
already a massively overloaded word.
Jul 31 2002
prev sibling parent Rex Couture <Rex_member pathlink.com> writes:
In article <ahsbn4$9ms$1 digitaldaemon.com>, OddesE says...

The same goes for contracts (Design By Contract), check it
out:  http://www.digitalmars.com/d/ section Contracts.


The contracts implementation is very nice.  There is one other very useful way
of implementing this, which I can recommend if it fits your coding style.  It
not only complements assert statements, but it can be used if assert statements
are not available.

I often place pre- and post-conditions in comments.  Like the enforced
contracts, this encourages a formal way of looking at the contract, and it
encourages you to identify and examine all possibilities when you are coding.

It seems to me that this can be used to complement assert statements, in two
ways.  In particular, you can use it as a reminder to verify preconditions at
the coding stage, when using previously debugged functions.  In addition, you
may not be able to test all possibilities by example, during debugging, and it
encourages one more analysis of the possibilities.  The only drawback is that
you need to keep comments with the headers.
Jul 26 2002
prev sibling parent Adam Connor <adamconnor nospam.maildotcom> writes:
You might want to take a look at Cyclone:
http://www.research.att.com/projects/cyclone/ 

It attempts to create a safe C, and adds some other features as well.
Jul 28 2002