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

 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

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

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

 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

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

 creeping featuritis.  If I can violate the rule against programming

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

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

 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

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

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

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

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

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

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

 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

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

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

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

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

 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

 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?

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

 home page....

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 

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

 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 

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

 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 

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 

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

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

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

 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. 4- Usually a nasty hack. Not desirable. And #3 allows this if we add 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

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

 just represented by an integer.

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

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

 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


 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

 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


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


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


 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* ...?

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* ...?

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>

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


 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>

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


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

 compatibility.

<Babble> That reminds me of C#. It has has unsafe blocks where you can do all your 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 

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

 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 

 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

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

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

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

 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

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

 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


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


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


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


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


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.


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


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


a safe and effective way to avoid pointer arithmetic?

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

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

 for the vast majority of programs.

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

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

 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

 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

 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?



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



 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....




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

 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

 name, but they do seem safe.

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

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

 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

 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

 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