www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - unsafe

reply nick <nick.atamas gmail.com> writes:
Note: I did a search for this and didn't come up with any threads. If it
has been discussed before... my apologies.


Recently I introduced D to a friend of mine (a C.S. grad student at
Purdue). His reaction was the usual "wow, awesome". Then he became
concerned about pointer safety. D allows unrestricted access to pointers.

I will skip the "pointers are unsafe" rigmarole.

Should D provide something analogous to the C# unsafe keyword?
Feb 12 2006
next sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-12 14:11:05 -0800, nick <nick.atamas gmail.com> said:

 Note: I did a search for this and didn't come up with any threads. If it
 has been discussed before... my apologies.
 
 
 Recently I introduced D to a friend of mine (a C.S. grad student at
 Purdue). His reaction was the usual "wow, awesome". Then he became
 concerned about pointer safety. D allows unrestricted access to pointers.
 
 I will skip the "pointers are unsafe" rigmarole.
 
 Should D provide something analogous to the C# unsafe keyword?

Don't play with the pointers if you want them to point to the right place. It's not like people are injecting malicious sourcecode into your projects. -S.
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
S. Chancellor wrote:
 On 2006-02-12 14:11:05 -0800, nick <nick.atamas gmail.com> said:
 
 Note: I did a search for this and didn't come up with any threads. If it
 has been discussed before... my apologies.


 Recently I introduced D to a friend of mine (a C.S. grad student at
 Purdue). His reaction was the usual "wow, awesome". Then he became
 concerned about pointer safety. D allows unrestricted access to pointers.

 I will skip the "pointers are unsafe" rigmarole.

 Should D provide something analogous to the C# unsafe keyword?

Don't play with the pointers if you want them to point to the right place. It's not like people are injecting malicious sourcecode into your projects. -S.

I guess skipping the rigmarole was a bad idea. I work with many EE people. EE people don't know how to write code. They are often very intelligent, but simple lack the experience and proper coding practices. Bjarne said that most programmers are amateurs. There is no helping that. A good language will provide safeguards against errors for amateurs. This would be one of them. When I get a piece of code from an colleague, I want to be sure that he didn't use pointers to mess something up. Having an unsafe keyword prevents his code from being compiled unless I provide the --allow-unsafe flag. That's a big assurance for me that his code doesn't mess up my heap.
Feb 12 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dsoifi$2von$1 digitaldaemon.com...
 I guess skipping the rigmarole was a bad idea.
 I work with many EE people. EE people don't know how to write code. They
 are often very intelligent, but simple lack the experience and proper
 coding practices.

 Bjarne said that most programmers are amateurs. There is no helping
 that. A good language will provide safeguards against errors for
 amateurs. This would be one of them.

The thing is, pointer use in D is pretty much restricted to interfacing with C libs. Using D normally, you should almost never have to touch pointers; the one real exception to this is the result of 'in' expressions.
 When I get a piece of code from an colleague, I want to be sure that he
 didn't use pointers to mess something up. Having an unsafe keyword
 prevents his code from being compiled unless I provide the
 --allow-unsafe flag. That's a big assurance for me that his code doesn't
 mess up my heap.

No code can mess up the heap, unless you're running with protected mode off. Which can't really happen with any OSes made in the last 15 years or so.
Feb 12 2006
next sibling parent reply nick <nick.atamas gmail.com> writes:
Jarrett Billingsley wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dsoifi$2von$1 digitaldaemon.com...
 The thing is, pointer use in D is pretty much restricted to interfacing with 
 C libs.  Using D normally, you should almost never have to touch pointers; 
 the one real exception to this is the result of 'in' expressions.
 
 No code can mess up the heap, unless you're running with protected mode off. 
 Which can't really happen with any OSes made in the last 15 years or so. 

I realize that pointers aren't meant to be used for things other than interfacing with C. However, it seems to me that D currently doesn't enforce this. A C programmer might be tempted to muck about with pointers. For example. ------------------------------------- CODE: import std.stdio; class A { private int data[]; public this() { data.length = 10; } public void printSelf() { writefln("Data: ", this.data); } } void surprise(inout A a) { byte *ap = cast(byte *)(a); ap[9] = 5; } int main() { A a = new A(); a.printSelf(); surprise(a); a.printSelf(); return 0; } ------------------------------------- OUTPUT: Data: [0,0,0,0,0,0,0,0,0,0] Data: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,2768,1245184,1,0,0,0 <..SNIP..> ,0,0,0,0,0,0,0,0,0,0,0] When I compile someone else's code I want an absolute guarantee that they aren't doing anything unsafe with their pointers. If they are doing something unsafe, I'd like to know. Better yet, I'd like to know if someone's library is unsafe when I link against it.
Feb 12 2006
parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Jarrett Billingsley wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dsoifi$2von$1 digitaldaemon.com...
 The thing is, pointer use in D is pretty much restricted to interfacing with 
 C libs.  Using D normally, you should almost never have to touch pointers; 
 the one real exception to this is the result of 'in' expressions.

 No code can mess up the heap, unless you're running with protected mode off. 
 Which can't really happen with any OSes made in the last 15 years or so. 

I realize that pointers aren't meant to be used for things other than interfacing with C.

What about someone who simply wants to maintain multiple references to a non-class type? C interfacing might be the most common use, but it certainly isn't the only use. Sean
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
 What about someone who simply wants to maintain multiple references to a
 non-class type?  C interfacing might be the most common use, but it
 certainly isn't the only use.
 
 
 Sean

References to non-class types are fine, but they should be maintained using typesafe pointers, which D provides. "Pointers are provided for interfacing with C and for specialized systems work....Most conventional uses for pointers can be replaced with dynamic arrays, out and inout parameters, and reference types." http://www.digitalmars.com/d/arrays.html You asking this is just further proof that there are people who will try to use unsafe pointers and that we need the unsafe keyword a. la. C#. I am in no way trying to attack you. I am just pointing out that C and C++ breeds bad programming practice, and we need protection from them.
Feb 12 2006
parent reply "Matthew" <nowhere noaddress.co.us> writes:
 I am in no way trying to attack you. I am just pointing out that C and
 C++ breeds bad programming practice, and we need protection from them.

Are you serious? Similarly, I am not trying to attack you, but this is terribly jejune. C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite. If you're bashing in a nail or injecting a patient or excavating a tunnel these are the best tools to have. They do not "breed" bad practice. That comes from process, experience and attitude. I'll repeat something I observed here a long time ago: the very worst coding I've come across, by a country mile, was a group of Java "consultants" (from one of the Big 5, or is it now Big 4, accountancy firms). I've seen bad C, bad COM, bad .NET, and, of course, plenty of bad C++, but nothing compares to the masses of swill that these jokers spewed forth. And nary a pointer in sight. Myself and several other (non-Java) consultants were brought in to fix the mess, and it took many days and hundreds of applications of source cleaning tools (which, thankfully, were written in a fast language) to start to clear up the junk. Further, I'd suggest that an understanding of what goes on beneath the covers is actually a hazardous skill to be lacking. (You might find http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative of my point.) Walter correctly sought to incorporate pointers in D as first class parts of the language. In the same way that I avoid IOStreams in C++, one tends to avoid pointers in D. Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.
Feb 12 2006
next sibling parent "Matthew" <nowhere noaddress.co.us> writes:
-- scratch this sentence. Unfinished though ... --

 In the same way that I avoid IOStreams in C++, one tends to avoid pointers 
 in D.

Feb 12 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 
 Further, I'd suggest that an understanding of what goes on beneath the 
 covers is actually a hazardous skill to be lacking.

I very much agree. In fact, this is my primary issue with the use of Java as a teaching language. It's nice when the teacher wants to gloss over details to focus on algorithm design or some such, but ignorance of the software-hardware interaction doesn't seem to make for good programmers. Sean
Feb 12 2006
prev sibling next sibling parent reply nick <nick.atamas gmail.com> writes:
Matthew wrote:
 I am in no way trying to attack you. I am just pointing out that C and
 C++ breeds bad programming practice, and we need protection from them.

Are you serious?

from a background that's primarily in C and C++ (especially if all they did was take one C or C++ course in college) are likely to use a C-style pointer instead of the appropriate D-style tools. We need a safeguard.
 Similarly, I am not trying to attack you, but this is terribly jejune. C and 
 C++ and pointers are no more or less hazardous than is a hammer or a syringe 
 or a stick of dynamite. If you're bashing in a nail or injecting a patient 
 or excavating a tunnel these are the best tools to have. They do not "breed" 
 bad practice. That comes from process, experience and attitude.

void surprise( in A a ) { byte *ap = cast(byte *)(a); ap[9] = 5; } If a function like that is part of a library, and I link against it, I may be in for quite a surprise. (There is code in the previous post that demonstrates the badness)
 Walter correctly sought to incorporate pointers in D as first class parts of 
 the language. In the same way that I avoid IOStreams in C++, one tends to 
 avoid pointers in D.

 Bottom line: if you're a good engineer, you're a good engineer. If you're 
 not, you're not. The language used won't affect this truth. And avoiding 
 peaking inside abstractions won't help you become one.

electrical engineers and bad programmers you are in for a void surprise(). I think you are looking at this through the eyes of someone who is an expert programmer, which you are. The fact is many people who program are not experts and you can't change that. It would be nice to have a safeguard against mistakes that they are likely to make. If you can point out why there shouldn't be a safeguard that (similar to the one in C# or a different one) I would like to hear that reason. That's exactly why I posted this thread. THE OTHER POINT: ---------------
 Further, I'd suggest that an understanding of what goes on beneath the 
 covers is actually a hazardous skill to be lacking. (You might find 
 http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative 
 of my point.)

out of my school before it became a Java prepschool. I took the weedout courses even though I had placement APs to get me out of some. You could say "I run gmake and gcc and I ain't never call malloc without calling free".
 C and 
 C++ and pointers are no more or less hazardous than is a hammer or a syringe 
 or a stick of dynamite.

"Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code."
 I'll repeat something I observed here a long time ago: the very worst coding 
 I've come across, by a country mile, was a group of Java "consultants" (from 

 cleaning tools (which, thankfully, were written in a fast language) to start 
 to clear up the junk.

effects of Java prepschools, let's start a new thread for that. I'll join you in bashing them.
Feb 12 2006
next sibling parent reply "Matthew" <nowhere noaddress.co.us> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dsp4lg$pul$1 digitaldaemon.com...
 Matthew wrote:
 I am in no way trying to attack you. I am just pointing out that C and
 C++ breeds bad programming practice, and we need protection from them.

Are you serious?

from a background that's primarily in C and C++ (especially if all they did was take one C or C++ course in college) are likely to use a C-style pointer instead of the appropriate D-style tools. We need a safeguard.

That's fair. But I think they're likely to not want to waste their time here, and so will have an open mind to new idioms. That's likely to be of more use and less bother in the long run, I think.
 Similarly, I am not trying to attack you, but this is terribly jejune. C 
 and
 C++ and pointers are no more or less hazardous than is a hammer or a 
 syringe
 or a stick of dynamite. If you're bashing in a nail or injecting a 
 patient
 or excavating a tunnel these are the best tools to have. They do not 
 "breed"
 bad practice. That comes from process, experience and attitude.

void surprise( in A a ) { byte *ap = cast(byte *)(a); ap[9] = 5; } If a function like that is part of a library, and I link against it, I may be in for quite a surprise. (There is code in the previous post that demonstrates the badness)

Sorry, I've fully read your post now. Always helps. The answer's simple: const. One of the continuing crushing advantages that C++ has over D. But you'll never see it in D. Walter doesn't use it in C/C++, and therefore has only a compiler writer's perspective on it, which is that it is a time-consuming pest to implement correctly with little, if any, use whatsoever because it can be subverted. Surprisingly, I'm from the other viewpoint. const is immensely expressive and powerful, and I wouldn't leave home without it. It is one of the ways I can tame the C++ compiler to do my will.
 Walter correctly sought to incorporate pointers in D as first class parts 
 of
 the language. In the same way that I avoid IOStreams in C++, one tends to
 avoid pointers in D.

 Bottom line: if you're a good engineer, you're a good engineer. If you're
 not, you're not. The language used won't affect this truth. And avoiding
 peaking inside abstractions won't help you become one.

electrical engineers and bad programmers you are in for a void surprise(). I think you are looking at this through the eyes of someone who is an expert programmer, which you are.

More flattery. You've obviously cotton'd on to my crushing insecurity, and its attendant vanity. ;-) To be fair, I would not claim expert status in anything other than C++ in general, STL extension in particular, and writing very fast recursive directory search libraries. Ha ha ha ha . . . . . . . wibble.
 The fact is many people who program
 are not experts and you can't change that. It would be nice to have a
 safeguard against mistakes that they are likely to make. If you can
 point out why there shouldn't be a safeguard that (similar to the one in
 C# or a different one) I would like to hear that reason. That's exactly
 why I posted this thread.

And now I fully follow your point, I agree that const would be perfect to your requirements.
 I'll repeat something I observed here a long time ago: the very worst 
 coding
 I've come across, by a country mile, was a group of Java "consultants" 
 (from

 cleaning tools (which, thankfully, were written in a fast language) to 
 start
 to clear up the junk.

effects of Java prepschools, let's start a new thread for that. I'll join you in bashing them.

Nah, it transpires that I only like talking with people with whom I violently disagree. ;-)
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
Matthew wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 That's fair. But I think they're likely to not want to waste their time 
 here, and so will have an open mind to new idioms. That's likely to be of 
 more use and less bother in the long run, I think.

You would hope that they would have an open mind and use the D features. But look at this quote:
 What about someone who simply wants to maintain multiple references to a
non-class type?  C interfacing might be the most common use, but it certainly
isn't the only use.


Maybe I'm misreading that, but isn't he basically saying "let's use c-style pointers". That's coming from someone who has been on the D newsgroup for some time. It's a testament to how much people get used to doing things a certain way. That particular person comes from a strong C/C++ background if I am not mistaken. My experience outside the D newsgroup shows this mentality to be true in general; it is human nature I guess. Then there is the specific matter of the /in/ keyword being easily broken by a c-style pointer. There may be other high-level features that are compromised by low-level features. That has to be looked into.
 And now I fully follow your point, I agree that const would be perfect to 
 your requirements.

semantics of /in/ can be modified so that it works more like const. However, I don't know if actual const parameters in D is what we need, because in/out/inout are a more explicit way of accomplishing the same idea. I realize that it's just a trade-off between the flexibility of const and the explicit nature of in/out My rambling about C++'s const follow: I've got beef with C++'s implementation of const. Allow me to explain. In C++ const serves multiple purposes that are related but not quite the same. Specifically, it can serve to signify that: 1. a function parameter is const e.g. 'void foo(const A &a)' 2. a method doesn't modify its object e.g. 'void foo() const' 3. a variable will never change e.g. const pi = 3.1415...; or const A a; I think it's perfectly cool to use const for #3 (does D only allow this for primitives?) In case of #2, I don't think that it makes sense because in/out/inout is more elegant. It seems that even in low-level code, in/out/inout can replace const in most cases. I am unsure about #1. It does cause a refactoring problem. On the other hand, D has a simple syntax, so a refactoring tool may be easy to implement. But then, maybe everything should be const by default and we should explicitly make things mutable.
Feb 13 2006
parent reply "Matthew" <nowhere noaddress.co.us> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dspgi4$1d03$1 digitaldaemon.com...
 Matthew wrote:
 "nick" <nick.atamas gmail.com> wrote in message
 That's fair. But I think they're likely to not want to waste their time
 here, and so will have an open mind to new idioms. That's likely to be of
 more use and less bother in the long run, I think.

You would hope that they would have an open mind and use the D features. But look at this quote:
 What about someone who simply wants to maintain multiple references to a 
 non-class type?  C interfacing might be the most common use, but it 
 certainly isn't the only use.


Maybe I'm misreading that, but isn't he basically saying "let's use c-style pointers". That's coming from someone who has been on the D newsgroup for some time. It's a testament to how much people get used to doing things a certain way. That particular person comes from a strong C/C++ background if I am not mistaken.

Well, Sean's very experienced in both C++ and D, and I tend to pay attention when he's opining. (Sean's going to be one of the reviewers on my new book. <g>) However, that doesn't proof him from the same frailties and preconceptions as the rest of us.
 My experience outside the D newsgroup shows this mentality to be true in
 general; it is human nature I guess.

If your point is that pointers should not be part of any of the mainline idioms of D, much less the language/std-libs, then I agree. I don't know if it's still the case, but the associative arrays used to have use pointers as part of its semantics. Fingers crossed that's no longer the case.
 Then there is the specific matter of the /in/ keyword being easily
 broken by a c-style pointer. There may be other high-level features that
 are compromised by low-level features. That has to be looked into.

No argument with the call for taking another look.
 And now I fully follow your point, I agree that const would be perfect to
 your requirements.

semantics of /in/ can be modified so that it works more like const. However, I don't know if actual const parameters in D is what we need, because in/out/inout are a more explicit way of accomplishing the same idea. I realize that it's just a trade-off between the flexibility of const and the explicit nature of in/out

It wouldn't have to be exactly the same as C++ const, but it'd have to confer all the advantages.
 My rambling about C++'s const follow:
 I've got beef with C++'s implementation of const. Allow me to explain.
 In C++ const serves multiple purposes that are related but not quite the
 same. Specifically, it can serve to signify that:
 1. a function parameter is const e.g. 'void foo(const A &a)'
 2. a method doesn't modify its object e.g. 'void foo() const'
 3. a variable will never change e.g. const pi = 3.1415...; or const A a;

 I think it's perfectly cool to use const for #3 (does D only allow this
 for primitives?)

 In case of #2, I don't think that it makes sense because in/out/inout is
 more elegant. It seems that even in low-level code, in/out/inout can
 replace const in most cases.

 I am unsure about #1. It does cause a refactoring problem. On the other
 hand, D has a simple syntax, so a refactoring tool may be easy to
 implement. But then, maybe everything should be const by default and we
 should explicitly make things mutable.

#1 and #2 are closely related, and that's an important feature of the keyword. I agree that mixing its name with the keyword for constants is a bad one - readonly would be much better - but C++ has a long and sorry history of reusing keywords inappropriately. What does typename mean? What does class mean? How are pre-/post- inc/decrement operators discriminated? How does one designate a pure virtual function? And so on. All hideous, to be sure.
Feb 13 2006
parent Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dspgi4$1d03$1 digitaldaemon.com...
 Matthew wrote:
 "nick" <nick.atamas gmail.com> wrote in message
 That's fair. But I think they're likely to not want to waste their time
 here, and so will have an open mind to new idioms. That's likely to be of
 more use and less bother in the long run, I think.

But look at this quote:
 What about someone who simply wants to maintain multiple references to a 
 non-class type?  C interfacing might be the most common use, but it 
 certainly isn't the only use.


c-style pointers". That's coming from someone who has been on the D newsgroup for some time. It's a testament to how much people get used to doing things a certain way. That particular person comes from a strong C/C++ background if I am not mistaken.

Well, Sean's very experienced in both C++ and D, and I tend to pay attention when he's opining. (Sean's going to be one of the reviewers on my new book. <g>) However, that doesn't proof him from the same frailties and preconceptions as the rest of us.

I was merely trying to point out that there are some situations where I might use a pointer in C/C++ that doesn't have a 'safe' D analog. However, it was somewhat of a weak position, as most of the examples could be refactored fairly easily to use classes to store the dynamically referenced data rather than using C-like pointers--the first example I thought of was the reference counter for shared pointers. Sean
Feb 13 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
What's going to stop them from making other mistakes, unrelated to 
pointers?  For example, the following:

void surprise(in char[] array)
{
     ubyte[100] x = cast(ubyte[100]) array;
     array[99] = 1;
}

This will compile fine, and uses zero pointers.  It's exactly the same 
concept, too.  Here's another one:

void surprise(in int i)
{
     if (i == 0 || i > 30)
         return i;
     else
         return surprise(--i);
}

Oops, what happens if i is below 0?  Oh, wait, here's another common 
mistake I see:

for (int i = 0; i != len; i++)
{
     ...
}

What happens if len is negative?  I've seen this happen, a lot, in more 
than a few different people's code.  They weren't stupid, you're right, 
but it did happen.

So do we mark != in fors as "unsafe"?  Recursion too?  And forget 
casting, any casting is unsafe now as well?

Seems to me like you're going to end up spending longer dealing with 
their problems, if they think they can use pointers but really can't, 
than you would just reviewing their darn code.

Oh wait, it's only open source where you do that "code review" thing. 
Otherwise it's considered a waste of time, except in huge corporations. 
  Why bother when "unsafe" can just fix everything for you like magic?

Valentine's day is coming up... good thing there are flowers, they just 
fix everything too.  I can be a jerk and all I need are flowers, right? 
  Magic.

-[Unknown]


 Matthew wrote:
 I am in no way trying to attack you. I am just pointing out that C and
 C++ breeds bad programming practice, and we need protection from them.


from a background that's primarily in C and C++ (especially if all they did was take one C or C++ course in college) are likely to use a C-style pointer instead of the appropriate D-style tools. We need a safeguard.
 Similarly, I am not trying to attack you, but this is terribly jejune. C and 
 C++ and pointers are no more or less hazardous than is a hammer or a syringe 
 or a stick of dynamite. If you're bashing in a nail or injecting a patient 
 or excavating a tunnel these are the best tools to have. They do not "breed" 
 bad practice. That comes from process, experience and attitude.

void surprise( in A a ) { byte *ap = cast(byte *)(a); ap[9] = 5; } If a function like that is part of a library, and I link against it, I may be in for quite a surprise. (There is code in the previous post that demonstrates the badness)
 Walter correctly sought to incorporate pointers in D as first class parts of 
 the language. In the same way that I avoid IOStreams in C++, one tends to 
 avoid pointers in D.

 Bottom line: if you're a good engineer, you're a good engineer. If you're 
 not, you're not. The language used won't affect this truth. And avoiding 
 peaking inside abstractions won't help you become one.

electrical engineers and bad programmers you are in for a void surprise(). I think you are looking at this through the eyes of someone who is an expert programmer, which you are. The fact is many people who program are not experts and you can't change that. It would be nice to have a safeguard against mistakes that they are likely to make. If you can point out why there shouldn't be a safeguard that (similar to the one in C# or a different one) I would like to hear that reason. That's exactly why I posted this thread. THE OTHER POINT: ---------------
 Further, I'd suggest that an understanding of what goes on beneath the 
 covers is actually a hazardous skill to be lacking. (You might find 
 http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative 
 of my point.)

out of my school before it became a Java prepschool. I took the weedout courses even though I had placement APs to get me out of some. You could say "I run gmake and gcc and I ain't never call malloc without calling free".
 C and 
 C++ and pointers are no more or less hazardous than is a hammer or a syringe 
 or a stick of dynamite.

"Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code."
 I'll repeat something I observed here a long time ago: the very worst coding 
 I've come across, by a country mile, was a group of Java "consultants" (from 

 cleaning tools (which, thankfully, were written in a fast language) to start 
 to clear up the junk.

effects of Java prepschools, let's start a new thread for that. I'll join you in bashing them.

Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
Pointer problems are notoriously difficult to track. Pointers are a
feature that is not necessary in 90% of production code. Hey, Joel
called them DANGEROUS. (I'm going to use that one a lot now.)

My example demonstrates a potential error that, if occurs in a library
that you don't have source for, will cause you hours of grief. My
example was carefully constructed. In it an object was passed in using
the /in/ keyword. That should guarantee that my copy of the object
doesn't change. If you are saying it is OK for it to change, then you
are basically saying that the /in/ keyword is useless (well, not really
useless but almost). I don't think that's cool.

Unknown W. Brackets wrote:
 What's going to stop them from making other mistakes, unrelated to
 pointers?  For example, the following:
 
 void surprise(in char[] array)
 {
     ubyte[100] x = cast(ubyte[100]) array;
     array[99] = 1;
 }
 
 This will compile fine, and uses zero pointers.  It's exactly the same
 concept, too.

this: main.d(3): e2ir: cannot cast from char[] to ubyte[100] Try it yourself. The rest of these aren't really pointer bugs. So, if you want to try a slippery slope and argue that all of programming is unsafe, be my guest. It isn't particularly productive though. (Sorry, I am getting cranky; it's late.) Here's another one:
 
 void surprise(in int i)
 {
     if (i == 0 || i > 30)
         return i;
     else
         return surprise(--i);
 }
 
 Oops, what happens if i is below 0?  Oh, wait, here's another common
 mistake I see:
 
 for (int i = 0; i != len; i++)
 {
     ...
 }
 
 What happens if len is negative?  I've seen this happen, a lot, in more
 than a few different people's code.  They weren't stupid, you're right,
 but it did happen.
 
 So do we mark != in fors as "unsafe"?  Recursion too?  And forget
 casting, any casting is unsafe now as well?
 
 Seems to me like you're going to end up spending longer dealing with
 their problems, if they think they can use pointers but really can't,
 than you would just reviewing their darn code.
 
 Oh wait, it's only open source where you do that "code review" thing.
 Otherwise it's considered a waste of time, except in huge corporations.
  Why bother when "unsafe" can just fix everything for you like magic?
 
 Valentine's day is coming up... good thing there are flowers, they just
 fix everything too.  I can be a jerk and all I need are flowers, right?
  Magic.
 
 -[Unknown]

Feb 12 2006
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I've read articles by Joel before, and while he's usually pretty good he 
can be off just as often.  It's not the king's word or anything.

Arrays can be passed using in and they can still change.  Only the array 
structure (length, pointer) cannot change.  There is no such guarantee 
for the data it points to (since both arrays point to the same place.)

I think the in keyword is very useful, if nothing else because of its 
semantic value.  But, even with it, something like this is still possible:

class A
{
     B b = null;
     int i = 1;
}

class B
{
     int j = 1;
}

int main()
{
     void test(in A a)
     {
         a.i = 6;
         a.b.j = 6;
     }

     A a = new A();
     a.b = new B();
     a.i = 5;
     a.b.j = 5;

     test(a);

     printf("i: %i, j: %i\n", a.i, a.b.j);

     return 0;
}

Run that and i and j will both be 6.  All that cannot happen is that a 
cannot be changed.  It really is not const.

As for the example you quoted, I'm afraid I am indeed guilty of a typo. 
  Anyway, for your enjoyment, here's a more complete example:

void surprise(in char[4] array)
{
     ubyte[] x = cast(ubyte[100]) array;
     x[99] = 1;
}

int main()
{
     char[4] char_array;
     ubyte[96] ubyte_array;

     surprise(char_array);

     foreach (ubyte u; ubyte_array)
     {
         if (u != 0)
             printf("1\n");
     }

     return 0;
}

You'll note, again, please, that I didn't use a single pointer.  Also, 
array bounds checking is enabled.  I'm doing everything great, except a 
bit of casting, since I know what it's doing behind the scenes.

This will print 1, even though ubyte_array was automatically initialized 
to 0 (one of the only things D does automatically to prevent bugs.) 
This means that I overwrote some other "innocent by-standard" variable. 
  Without even typing a single asterisk.

I didn't say they were "pointer bugs" or anything of the sort.  I said 
they were sloppy/stupid programming, and things that cannot be prevented 
by using "safe" code.

In other words: if someone doesn't know what they're doing, they 
shouldn't be doing it.  I don't see people arguing in court rooms that 
they're amateur drivers or anything inane like that, but yet it happens 
for programmers.  Driving is no simple thing, but people actually spend 
the time to master it.  It's not that different.

But if you can't drive - whether because you're blind, or simply haven't 
learned yet - you'd best get off the darn road.  Or at least be aware 
that you should avoid doing anything stupid.  If your amateur programmer 
friends can't figure this out they're not nearly as intelligent as 
you're making them out to be.

(Please note, of course, that everyone has to learn.  But that's what 
driver's ed is for, and what other things are for.  You just shouldn't 
be in production/on the road if you can't figure things out yet.)

-[Unknown]


 Pointer problems are notoriously difficult to track. Pointers are a
 feature that is not necessary in 90% of production code. Hey, Joel
 called them DANGEROUS. (I'm going to use that one a lot now.)
 
 My example demonstrates a potential error that, if occurs in a library
 that you don't have source for, will cause you hours of grief. My
 example was carefully constructed. In it an object was passed in using
 the /in/ keyword. That should guarantee that my copy of the object
 doesn't change. If you are saying it is OK for it to change, then you
 are basically saying that the /in/ keyword is useless (well, not really
 useless but almost). I don't think that's cool.
 
 Unknown W. Brackets wrote:
 What's going to stop them from making other mistakes, unrelated to
 pointers?  For example, the following:

 void surprise(in char[] array)
 {
     ubyte[100] x = cast(ubyte[100]) array;
     array[99] = 1;
 }

 This will compile fine, and uses zero pointers.  It's exactly the same
 concept, too.

this: main.d(3): e2ir: cannot cast from char[] to ubyte[100] Try it yourself. The rest of these aren't really pointer bugs. So, if you want to try a slippery slope and argue that all of programming is unsafe, be my guest. It isn't particularly productive though. (Sorry, I am getting cranky; it's late.) Here's another one:
 void surprise(in int i)
 {
     if (i == 0 || i > 30)
         return i;
     else
         return surprise(--i);
 }

 Oops, what happens if i is below 0?  Oh, wait, here's another common
 mistake I see:

 for (int i = 0; i != len; i++)
 {
     ...
 }

 What happens if len is negative?  I've seen this happen, a lot, in more
 than a few different people's code.  They weren't stupid, you're right,
 but it did happen.

 So do we mark != in fors as "unsafe"?  Recursion too?  And forget
 casting, any casting is unsafe now as well?

 Seems to me like you're going to end up spending longer dealing with
 their problems, if they think they can use pointers but really can't,
 than you would just reviewing their darn code.

 Oh wait, it's only open source where you do that "code review" thing.
 Otherwise it's considered a waste of time, except in huge corporations.
  Why bother when "unsafe" can just fix everything for you like magic?

 Valentine's day is coming up... good thing there are flowers, they just
 fix everything too.  I can be a jerk and all I need are flowers, right?
  Magic.

 -[Unknown]


Feb 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Pointer problems are notoriously difficult to track. Pointers are a
 feature that is not necessary in 90% of production code. Hey, Joel
 called them DANGEROUS. (I'm going to use that one a lot now.)
 
 My example demonstrates a potential error that, if occurs in a library
 that you don't have source for, will cause you hours of grief. My
 example was carefully constructed. In it an object was passed in using
 the /in/ keyword. That should guarantee that my copy of the object
 doesn't change. If you are saying it is OK for it to change, then you
 are basically saying that the /in/ keyword is useless (well, not really
 useless but almost). I don't think that's cool.

'in' just indicates call by value, and in the case of objects, only the reference is passed by value. No guarantee of immutability is being provided. Doesn't Ada use the same in/out/inout syntax? Sean
Feb 13 2006
parent reply nick <nick.atamas gmail.com> writes:
Sean Kelly wrote:
 nick wrote:
 Pointer problems are notoriously difficult to track. Pointers are a
 feature that is not necessary in 90% of production code. Hey, Joel
 called them DANGEROUS. (I'm going to use that one a lot now.)

 My example demonstrates a potential error that, if occurs in a library
 that you don't have source for, will cause you hours of grief. My
 example was carefully constructed. In it an object was passed in using
 the /in/ keyword. That should guarantee that my copy of the object
 doesn't change. If you are saying it is OK for it to change, then you
 are basically saying that the /in/ keyword is useless (well, not really
 useless but almost). I don't think that's cool.

'in' just indicates call by value, and in the case of objects, only the reference is passed by value. No guarantee of immutability is being provided. Doesn't Ada use the same in/out/inout syntax? Sean

Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.
Feb 13 2006
parent reply "Matthew" <nowhere noaddress.co.us> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dsrhuq$i9p$1 digitaldaemon.com...
 Sean Kelly wrote:
 nick wrote:
 Pointer problems are notoriously difficult to track. Pointers are a
 feature that is not necessary in 90% of production code. Hey, Joel
 called them DANGEROUS. (I'm going to use that one a lot now.)

 My example demonstrates a potential error that, if occurs in a library
 that you don't have source for, will cause you hours of grief. My
 example was carefully constructed. In it an object was passed in using
 the /in/ keyword. That should guarantee that my copy of the object
 doesn't change. If you are saying it is OK for it to change, then you
 are basically saying that the /in/ keyword is useless (well, not really
 useless but almost). I don't think that's cool.

'in' just indicates call by value, and in the case of objects, only the reference is passed by value. No guarantee of immutability is being provided. Doesn't Ada use the same in/out/inout syntax? Sean

Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.

Perhaps if people considered readonly, rather than const, it'd seem more workable. readonly would mean only the code seeing that decorator is prevented by the compiler from altering it. In other words, this impacts only on logical constness within the current context. readonly would have nothing whatsoever to do with physical constness. IIRC most, though not all, of Walter's objections have pertained to the physical subversion of logical constness, and how that may impact code generation and other compilery things I don't understand.
Feb 13 2006
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Matthew" <nowhere noaddress.co.us> wrote in message 
news:dsri7o$j2i$1 digitaldaemon.com...
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dsrhuq$i9p$1 digitaldaemon.com...
 Sean Kelly wrote:
 nick wrote:
 Pointer problems are notoriously difficult to track. Pointers are a
 feature that is not necessary in 90% of production code. Hey, Joel
 called them DANGEROUS. (I'm going to use that one a lot now.)

 My example demonstrates a potential error that, if occurs in a library
 that you don't have source for, will cause you hours of grief. My
 example was carefully constructed. In it an object was passed in using
 the /in/ keyword. That should guarantee that my copy of the object
 doesn't change. If you are saying it is OK for it to change, then you
 are basically saying that the /in/ keyword is useless (well, not really
 useless but almost). I don't think that's cool.

'in' just indicates call by value, and in the case of objects, only the reference is passed by value. No guarantee of immutability is being provided. Doesn't Ada use the same in/out/inout syntax? Sean

Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.

Perhaps if people considered readonly, rather than const, it'd seem more workable. readonly would mean only the code seeing that decorator is prevented by the compiler from altering it. In other words, this impacts only on logical constness within the current context. readonly would have nothing whatsoever to do with physical constness. IIRC most, though not all, of Walter's objections have pertained to the physical subversion of logical constness, and how that may impact code generation and other compilery things I don't understand.

I think that Walter is looking for something like this: http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2005.pdf It is a Javari - Java with readonly. I think that this paper of Matthew Tschantz and Michael Ernst is the most comprehensive study on the subject. This is how it should be done in ideal world. Andrew.
Feb 13 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <nowhere noaddress.co.us> wrote in message 
news:dsri7o$j2i$1 digitaldaemon.com...
 IIRC most, though not all, of Walter's objections have pertained to the 
 physical subversion of logical constness, and how that may impact code 
 generation and other compilery things I don't understand.

It's not just that. It's that there are many different definitions of const, each with its own advantages and problems. C++ uses two of them (confusingly conflated). 1) is the reference const? 2) is what the reference refers to const? 3) does (2) apply recursively? 4) is it only const by that reference, i.e. can other references to the same data concurrently modify it? 5) is it ROMable? 6) is it initialize-once? 7) is it an error to subvert const'ness, or is it legal? (Since D has pointers, one can always find a way to subvert it, the question is is that defined behavior.) 8) is there a place for 'mutable' members of const objects? 9) how does aliasing (multiple references to the same data) fit into all this? 10) does C++ have it backwards - const should be the default, and non-const should be explicit? 11) what happens when a const reference is supplied to a non-const reference? 12) is there a way to do const that can take advantage of hardware support for read-only? 13) how can const fit in with the notion of COW? 14) how does this fit in with the notion of an atomic function (a function with no side effects)? 15) how to do this in an aesthetically pleasing way that has a slap-ones-head-of-course-thats-the-way-to-do-it obviousness about it that everyone missed before? <g> I've asked a friend who's a languages expert about this, who views programming languages through the lense of academic rigor, and he unhelpfully suggested D do all variations <sigh>. My views on the failings of C++ const are pretty well documented in these n.g.'s, so I shan't repeat them. Suffice to say whatever D gets won't look or behave like that, and D is better off with no const at all than the C++ const. (I might add, however, that D does have C++'s readonly notion of const, and that works well. Just not the type modifier version.)
Feb 13 2006
next sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-13 21:40:30 -0800, "Walter Bright" <newshound digitalmars.com> said:

 
 "Matthew" <nowhere noaddress.co.us> wrote in message 
 news:dsri7o$j2i$1 digitaldaemon.com...
 IIRC most, though not all, of Walter's objections have pertained to the 
 physical subversion of logical constness, and how that may impact code 
 generation and other compilery things I don't understand.

It's not just that. It's that there are many different definitions of const, each with its own advantages and problems. C++ uses two of them (confusingly conflated). 1) is the reference const? 2) is what the reference refers to const? 3) does (2) apply recursively? 4) is it only const by that reference, i.e. can other references to the same data concurrently modify it? 5) is it ROMable? 6) is it initialize-once? 7) is it an error to subvert const'ness, or is it legal? (Since D has pointers, one can always find a way to subvert it, the question is is that defined behavior.) 8) is there a place for 'mutable' members of const objects? 9) how does aliasing (multiple references to the same data) fit into all this? 10) does C++ have it backwards - const should be the default, and non-const should be explicit? 11) what happens when a const reference is supplied to a non-const reference? 12) is there a way to do const that can take advantage of hardware support for read-only? 13) how can const fit in with the notion of COW? 14) how does this fit in with the notion of an atomic function (a function with no side effects)? 15) how to do this in an aesthetically pleasing way that has a slap-ones-head-of-course-thats-the-way-to-do-it obviousness about it that everyone missed before? <g> I've asked a friend who's a languages expert about this, who views programming languages through the lense of academic rigor, and he unhelpfully suggested D do all variations <sigh>. My views on the failings of C++ const are pretty well documented in these n.g.'s, so I shan't repeat them. Suffice to say whatever D gets won't look or behave like that, and D is better off with no const at all than the C++ const. (I might add, however, that D does have C++'s readonly notion of const, and that works well. Just not the type modifier version.)

What does const currently do? I'm not familiar with read only memory attributes, but on MacOS X I did this: char[] foo = "Hello"; and then idiotically tried to modify foo, the program segfaulted on me. The fix was to do "Hello".dup Can you make this happen at will to a portion of memory? If so I propose this syntax: const Type Name = <initializer>; //This would make the reference constant. TypeDef Name = const new Type; //This would make the data itself constant (What's this good for? Can't imagine a class which would let you readonly it. The class would need to be written in such a way as to allow it to be a readonly class.) const Type Name = const New Type; //Both the reference and data are readonlyized This is the behavior I would expect out of const. Modifying a const variable would result in your program segfaulting due to an memory access error. -S. Let me fill out your questionnaire:
 1) is the reference const?

See above
 2) is what the reference refers to const?

See above
 3) does (2) apply recursively?

No; IE a char[] in a class that was defined as const would still be writable unless the class itself defined it as const.
 4) is it only const by that reference, i.e. can other references to the 
 same data concurrently modify it?

No.
 5) is it ROMable?

Yes
 6) is it initialize-once?

Yes
 7) is it an error to subvert const'ness, or is it legal? (Since D has 
 pointers, one can always find a way to subvert it, the question is is 
 that defined behavior.)

Yes, see above
 8) is there a place for 'mutable' members of const objects?

See above about making a readonly class. I suspect it would be wise to add some kind of keyword saying this class can be a readonly class. It might even make sense to only allow structures to be const'd (Aside from the references, I'm referring to the actual heap data.)
 9) how does aliasing (multiple references to the same data) fit into all this?

*Shrug* The memory is ROMized. *BOOM*
 10) does C++ have it backwards - const should be the default, and 
 non-const should be explicit?

Nope, I don't want to have to declare the majority of what I use as mutable.
 11) what happens when a const reference is supplied to a non-const reference?

That's not a problem, since the reference is what is constant. We care that the const reference always point to the correct object, not that nothing else does.
 12) is there a way to do const that can take advantage of hardware 
 support for read-only?

Sure, if it exists.
 13) how can const fit in with the notion of COW?

How does this relate?
 14) how does this fit in with the notion of an atomic function (a 
 function with no side effects)?

Huh?
 15) how to do this in an aesthetically pleasing way that has a 
 slap-ones-head-of-course-thats-the-way-to-do-it obviousness about it 
 that everyone missed before? <g>

I like the syntax I proposed.
Feb 14 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
Yes, that's one possible design. I like the idea of being able to put 
*allocated* data into a readonly segment, but this may be difficult to 
achieve. 
Feb 14 2006
next sibling parent S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-14 11:03:04 -0800, "Walter Bright" <newshound digitalmars.com> said:

 Yes, that's one possible design. I like the idea of being able to put 
 *allocated* data into a readonly segment, but this may be difficult to 
 achieve.

I'm not sure what you mean. Also, but I forgot this part: const StructType Foo; <-- Foo's data would obviously be readonly also, (since structures don't have reference semantics by default) so if any references were created they couldn't modify it's data either. Where does this leave arrays that have psuedo reference semantics? -S.
Feb 14 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Yes, that's one possible design. I like the idea of being able to put 
 *allocated* data into a readonly segment, but this may be difficult to 
 achieve. 

This would be great if it's possible. I assume one method would be to allocate from a write-protected memory page for this purpose, but this sounds a bit slow and not terribly portable. Are there any other options? Sean
Feb 14 2006
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
  (I might add, however, that D does have C++'s readonly notion of 
 const, and that works well. Just not the type modifier version.) 
 

Yes, except that there is no way apply the readonly notion to the referenced data, only to the variable (self) value. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 16 2006
prev sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthew wrote:
I am in no way trying to attack you. I am just pointing out that C and
C++ breeds bad programming practice, and we need protection from them.

Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.

I think you didn't get his point: he's not worried that /he/ will misuse pointers, he's worried that _his colleagues_ will.
Feb 12 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
What's worse, I can use the function prototype:

void surprise(inout A a);

and the results will be exactly the same. That just seriously breaks all
the high level language features that D puts in place. So I guess my
question is: "Shouldn't there be a mechanism to deal with this?"
Feb 12 2006
next sibling parent nick <nick.atamas gmail.com> writes:
nick wrote:
 What's worse, I can use the function prototype:
 
 void surprise(inout A a);
 
 and the results will be exactly the same. That just seriously breaks all
 the high level language features that D puts in place. So I guess my
 question is: "Shouldn't there be a mechanism to deal with this?"

changed inside the function call. It's been a long day.
Feb 12 2006
prev sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-12 19:32:47 -0800, nick <nick.atamas gmail.com> said:

 What's worse, I can use the function prototype:
 
 void surprise(inout A a);
 
 and the results will be exactly the same. That just seriously breaks all
 the high level language features that D puts in place. So I guess my
 question is: "Shouldn't there be a mechanism to deal with this?"

If you're working with people who are idiots, they're going to be idiots regardless of a damn unsafe keyword, or a friggin' throws keyword, or whatever! Language do not fix people. Writing software is not subject to malicious attacks by hackers. People are not intentionally injecting bad code into your software! You do not need security features built into the language. If it were up to me I'd abolish the private and protected keywords too! They're rather stupid, their intent is to "recommend" people not to use them. Quite often, especially in .NET i want to use a protected method and end up having to subclass the F*CKING class to expose it to the rest of my program. -S.
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
S. Chancellor wrote:
 On 2006-02-12 19:32:47 -0800, nick <nick.atamas gmail.com> said:
 
 What's worse, I can use the function prototype:

 void surprise(inout A a);

 and the results will be exactly the same. That just seriously breaks all
 the high level language features that D puts in place. So I guess my
 question is: "Shouldn't there be a mechanism to deal with this?"

Language do not fix people. Writing software is not subject to malicious attacks by hackers. People are not intentionally injecting bad code into your software! You do not need security features built into the language. If it were up to me I'd abolish the private and protected keywords too! They're rather stupid, their intent is to "recommend" people not to use them. Quite often, especially in .NET i want to use a protected method and end up having to subclass the F*CKING class to expose it to the rest of my program. -S.

Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea. I'm just going to quote Joel here: "Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code." http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html
 If you're working with people who are idiots, they're going to be idiots
 regardless of a damn unsafe keyword, or a friggin' throws keyword, or
 whatever!

same thing. Some individuals who write code are mathematicians, physicists, or electrical engineers by training. Programming languages aren't just for hardcore experts like Matthew or Walter. Most programmers are amateurs; you're not going to change that. Furthermore, humans are prone to error. If you think that safeguards aren't for you, then maybe you should double-check the list of D features: in/out/inout, nested functions, typesafe variadic arguments, contract programming, guaranteed initialization, and others. Are you telling me that all those should be thrown out because they are just there to prevent mistakes?
Feb 12 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas gmail.com> wrote:

 Now you're talking crazy talk. Throws declarations may be a bad idea - I
 agreed after having read up on it. I have yet to hear a good reason why
 the unsafe keyword or some other safeguard against dangerous pointer
 code is a bad idea.

Then would 'delete' be 'unsafe'? Even though it nulls the reference, other places may still be referencing it, hence making it unsafe.
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
Chris Miller wrote:
 On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas gmail.com> wrote:
 
 Now you're talking crazy talk. Throws declarations may be a bad idea - I
 agreed after having read up on it. I have yet to hear a good reason why
 the unsafe keyword or some other safeguard against dangerous pointer
 code is a bad idea.

Then would 'delete' be 'unsafe'? Even though it nulls the reference, other places may still be referencing it, hence making it unsafe.

That seems to be an implementation detail. However, my immediate reaction is that delete probably should be unsafe; however, I am not sure. It all depends on how much it is needed for mainstream software development and how much damage it tends to cause. Of course, if you are talking about overriding new and then calling delete, that's a different story. By allocating memory manually you are preventing a good garbage collector from optimizing your heap, so you should be avoiding that in most cases. The upshot of using "unsafe" is that all code that messes with the memory manually would get marked unsafe. So, someone working on OS features may end up having to put an "unsafe:" at the top of every file and compiling with the --unsafe flag (or something to that effect). It seems like a small price to pay for preventing amateurs from screwing up your code. It seems to me that most people who write code don't need pointers. Both D and C++ are languages that provide high-level and low-level access. You are going to get both experts who need the pointers and amateurs who don't need them. Both Bjarne and Matthew seem to think that people should just "learn to code well". Despite admitting that most coders are not experts, Bjarne says: "The most direct way of addressing the problems caused by lack of type safety is to provide a range-checked Standard Library based on statically typed containers and base the teaching of C++ on that". <http://public.research.att.com/~bs/rules.pdf> I must disagree. There are too many people to teach. In some cases it is a lot easier to modify a language than to teach everyone not to use a feature. This may be one of those cases. I think experts tend to forget that a language is there to help programmers develop software and to reduce chances of human error.
Feb 12 2006
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
By implementation detail, are you speaking to it nulling the pointer?  I 
was pretty sure that was in the spec, and not in the implementation.

Delete is needed if you ever want to immediately call a destructor.  If 
used wisely, it can also decrease the memory usage of your software, and 
reduce garbage collection runs (if the GC won't run unless there's more 
than X to collect.)

Overriding new and delete would definitely fit into the same class as 
pointers, recursion, casting, != in fors, and delete.  They're all scary.

-[Unknown]


 Chris Miller wrote:
 On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas gmail.com> wrote:

 Now you're talking crazy talk. Throws declarations may be a bad idea - I
 agreed after having read up on it. I have yet to hear a good reason why
 the unsafe keyword or some other safeguard against dangerous pointer
 code is a bad idea.

other places may still be referencing it, hence making it unsafe.

That seems to be an implementation detail. However, my immediate reaction is that delete probably should be unsafe; however, I am not sure. It all depends on how much it is needed for mainstream software development and how much damage it tends to cause. Of course, if you are talking about overriding new and then calling delete, that's a different story. By allocating memory manually you are preventing a good garbage collector from optimizing your heap, so you should be avoiding that in most cases. The upshot of using "unsafe" is that all code that messes with the memory manually would get marked unsafe. So, someone working on OS features may end up having to put an "unsafe:" at the top of every file and compiling with the --unsafe flag (or something to that effect). It seems like a small price to pay for preventing amateurs from screwing up your code. It seems to me that most people who write code don't need pointers. Both D and C++ are languages that provide high-level and low-level access. You are going to get both experts who need the pointers and amateurs who don't need them. Both Bjarne and Matthew seem to think that people should just "learn to code well". Despite admitting that most coders are not experts, Bjarne says: "The most direct way of addressing the problems caused by lack of type safety is to provide a range-checked Standard Library based on statically typed containers and base the teaching of C++ on that". <http://public.research.att.com/~bs/rules.pdf> I must disagree. There are too many people to teach. In some cases it is a lot easier to modify a language than to teach everyone not to use a feature. This may be one of those cases. I think experts tend to forget that a language is there to help programmers develop software and to reduce chances of human error.

Feb 12 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dsp8bc$143b$1 digitaldaemon.com...
 I must disagree. There are too many people to teach. In some cases it is
 a lot easier to modify a language than to teach everyone not to use a
 feature. This may be one of those cases. I think experts tend to forget
 that a language is there to help programmers develop software and to
 reduce chances of human error.

On the one hand, I agree with you. Often, when I show that feature X of D will eliminate a certain common class of errors one gets with C++, the response I get back is that "yes, but one can follow this procedural rigor with C++ and not get that error." Well, sure, if everyone is a god-like programmer. But they aren't, and if you're an employer, you'll inevitably be hiring mere mortal programmers, and if you work on a team, they'll be mere mortals too, despite being a god oneself <g>. On the other hand, having powerful (but dangerous) features are just too useful to ignore. How do we solve this? We can't. But we can try to mitigate it, and D does so by: 1) Trying to make the natural thing to do the right way to do it. D's arrays and reference objects are good examples of this. 2) Making practices that often lead to bugs be more visible in the code, so that code reviews can zero in on them, or even so that they're more greppable. Going from the C-style cast to requiring a 'cast' keyword is an example of this. 3) Finding attractive alternatives to common uses of unsafe practices - out and inout parameters are a good example here. C# had a similar idea with the 'unsafe' keyword. It has some advantages - being keyword based, it can be flagged by the compiler if so desired, and it can be grepped for. It has one big disadvantage, though - it's just awful <g>. I find it grating to be forced to label code as "unsafe" when, as a programmer, I know it's perfectly safe. It's patronizing. It makes the language feel like it is not for professionals. Although D eliminates maybe 90% of the need for explicit pointers, they're still needed here and there. I'd like to go that last 10%, but I don't think 'unsafe' is the right way to do it, even if its heart is in the right place.
Feb 13 2006
parent reply nick <nick_member pathlink.com> writes:
In article <dspn17$1lbq$1 digitaldaemon.com>, Walter Bright says...
3) Finding attractive alternatives to common uses of unsafe practices - out 
and inout parameters are a good example here.

comes to objects, I am not sure sure the semantics are the best at the moment. For example, given this code: class A{ public int q;} void surprise( in A a ){a.q = 5;} a call to surprise(a) will change the value of 'a'. Is there no way to guarantee that the value of 'a' doesn't change in a function?
C# had a similar idea with the 'unsafe' keyword. It has some advantages - 
being keyword based, it can be flagged by the compiler if so desired, and it 
can be grepped for. It has one big disadvantage, though - it's just awful 
<g>. I find it grating to be forced to label code as "unsafe" when, as a 
programmer, I know it's perfectly safe. It's patronizing. It makes the 
language feel like it is not for professionals.

Then we can feel good about using it; I know I would. = )
Although D eliminates maybe 90% of the need for explicit pointers, they're 
still needed here and there. I'd like to go that last 10%, but I don't think 
'unsafe' is the right way to do it, even if its heart is in the right place. 

a 'const type*', that would help.
Feb 13 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick_member pathlink.com> wrote in message 
news:dsqr3t$2seg$1 digitaldaemon.com...
 I think that if we changed the semantics of /in/ or provided some 
 equivalent of
 a 'const type*', that would help.

I agree, but in investigating this it turned out to be quite a quagmire, so I abandoned it for now.
Feb 13 2006
parent reply John Demme <me teqdruid.com> writes:
The ability to protect not a reference, but the memory a reference points to
is a feature that (at least a few) people have been asking for for some
time.  (Think: real constant arrays.)  Walter, this is something you've
said is a 2.0 feature, yes?  Nick, this would satisfy your issue with a
reference "in" parameter?

~John Demme

Walter Bright wrote:

 
 "nick" <nick_member pathlink.com> wrote in message
 news:dsqr3t$2seg$1 digitaldaemon.com...
 I think that if we changed the semantics of /in/ or provided some
 equivalent of
 a 'const type*', that would help.

I agree, but in investigating this it turned out to be quite a quagmire, so I abandoned it for now.

Feb 13 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:dsrn2u$m91$2 digitaldaemon.com...
 The ability to protect not a reference, but the memory a reference points 
 to
 is a feature that (at least a few) people have been asking for for some
 time.  (Think: real constant arrays.)  Walter, this is something you've
 said is a 2.0 feature, yes?

Yes.
Feb 13 2006
prev sibling parent nick <nick.atamas gmail.com> writes:
John Demme wrote:
 The ability to protect not a reference, but the memory a reference points to
 is a feature that (at least a few) people have been asking for for some
 time.  (Think: real constant arrays.)  Walter, this is something you've
 said is a 2.0 feature, yes?  Nick, this would satisfy your issue with a
 reference "in" parameter?
 
 ~John Demme
 
 Walter Bright wrote:
 
 "nick" <nick_member pathlink.com> wrote in message
 news:dsqr3t$2seg$1 digitaldaemon.com...
 I think that if we changed the semantics of /in/ or provided some
 equivalent of
 a 'const type*', that would help.

so I abandoned it for now.


Thanks, John. That pretty much solves my problems.
Feb 14 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
On Tue, 14 Feb 2006 07:44:45 +1100, nick <nick_member pathlink.com> wrote:

 In article <dspn17$1lbq$1 digitaldaemon.com>, Walter Bright says...
 3) Finding attractive alternatives to common uses of unsafe practices -  
 out
 and inout parameters are a good example here.

when it comes to objects, I am not sure sure the semantics are the best at the moment. For example, given this code: class A{ public int q;} void surprise( in A a ){a.q = 5;} a call to surprise(a) will change the value of 'a'. Is there no way to guarantee that the value of 'a' doesn't change in a function?

Sorry to interrupt, but its important to get some terms strightened out here. The 'in' qualifier does in fact protect the value of the parameter passed. In your example, it does protect the value of 'a'; that is it does not permit any changes to the object reference to be returned to the caller. However, the 'in' qualifier does *not* protect the object to which 'a' refers. In short, it protects the reference but not the referred. For example, when passed to your example, 'a' is the address of a class instance - it is not the instance itself, just its RAM address. Any changes you make to that address is not returned to the caller. The only way (currently) to protect the object itself, is to take a copy of it and work with the copy. This applies to class instances and to arrays.
 I think that if we changed the semantics of /in/ or provided some  
 equivalent of a 'const type*', that would help.

I'd only go as way as saying that I'd like to see some form of syntax to alert the compiler and maintainer of the intention of the coder and thus warn us of overt or explicit attempts to change data inside such a 'protected' object or array. This should still allow other methods to modify objects but not make it easy to do. -- Derek Parnell Melbourne, Australia
Feb 13 2006
prev sibling next sibling parent reply "Matthew" <nowhere noaddress.co.us> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dsp5ak$s35$1 digitaldaemon.com...
 S. Chancellor wrote:
 On 2006-02-12 19:32:47 -0800, nick <nick.atamas gmail.com> said:

 What's worse, I can use the function prototype:

 void surprise(inout A a);

 and the results will be exactly the same. That just seriously breaks all
 the high level language features that D puts in place. So I guess my
 question is: "Shouldn't there be a mechanism to deal with this?"

Language do not fix people. Writing software is not subject to malicious attacks by hackers. People are not intentionally injecting bad code into your software! You do not need security features built into the language. If it were up to me I'd abolish the private and protected keywords too! They're rather stupid, their intent is to "recommend" people not to use them. Quite often, especially in .NET i want to use a protected method and end up having to subclass the F*CKING class to expose it to the rest of my program. -S.

Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea. I'm just going to quote Joel here: "Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code." http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html
 If you're working with people who are idiots, they're going to be idiots
 regardless of a damn unsafe keyword, or a friggin' throws keyword, or
 whatever!

same thing. Some individuals who write code are mathematicians, physicists, or electrical engineers by training. Programming languages aren't just for hardcore experts like Matthew or Walter.

LOL! This appelation never fails to make my brain do a "what, you mean me!?!" double-take. Same feeling as getting caught nicking one of mum's cakes, or in-flagrante with one's girlfriend, perhaps. ;-)
 When will people finally realize that stupid an unexperienced aren't the
 same thing. . . . Most
 programmers are amateurs; you're not going to change that. Furthermore,
 humans are prone to error.

True. But you can't hobble "production" programmers to cater for hobbyists. That's just not a go-er. Isn't it better to do what D has done, and allow for the low down and dirty while fostering and promoting a generally more suitable higher-level of abstraction? Type-safety, const-correctness, and all such things are very good. Basically, whatever you can get the compiler to do for you is a good thing. Just as long as you can circumvent it when you need to. In both these areas, I think D has some way to go, but it's better than most.
Feb 12 2006
parent Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dsp5ak$s35$1 digitaldaemon.com...
 
 When will people finally realize that stupid an unexperienced aren't the
 same thing. . . . Most
 programmers are amateurs; you're not going to change that. Furthermore,
 humans are prone to error.

True. But you can't hobble "production" programmers to cater for hobbyists. That's just not a go-er. Isn't it better to do what D has done, and allow for the low down and dirty while fostering and promoting a generally more suitable higher-level of abstraction? Type-safety, const-correctness, and all such things are very good. Basically, whatever you can get the compiler to do for you is a good thing. Just as long as you can circumvent it when you need to. In both these areas, I think D has some way to go, but it's better than most.

Agreed. And frankly, I would be fine with using an 'unsafe' attribute so long as doing so didn't prevent me from being as evil as the situation demanded. However, I reserve the right to complain if it's annoying to use ;-) Sean
Feb 13 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, it's clearly not helping them, is it?  Most programmers may or may 
not know what in the world they're doing, but most of the programmers I 
want to hire or have work with me will.

All of the features you listed are there to help people who are sensible 
detect errors.  Lovely things they are, too.  But they don't just get 
used, you have to use them.  If you don't, you're no better off than if 
you didn't.

Mistakes happen, but gross mistakes shouldn't.  If they do, the person 
needs to go back and bake in training/school/less important projects for 
a while.  No language can change this, however many keywords or flags it 
adds.

-[Unknown]


 Most programmers are amateurs; you're not going to change that.

Feb 12 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 12 Feb 2006 22:33:25 -0800, Unknown W. Brackets wrote:

 Most programmers are amateurs; you're not going to change that.


More indication that we could really do with a 'lint' program for D. It could warn about pointer usage too. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 13/02/2006 5:44:24 PM
Feb 12 2006
parent nick <nick.atamas gmail.com> writes:
Derek Parnell wrote:
 On Sun, 12 Feb 2006 22:33:25 -0800, Unknown W. Brackets wrote:
 
 Most programmers are amateurs; you're not going to change that.


More indication that we could really do with a 'lint' program for D. It could warn about pointer usage too.

be an in-language solution to the /in/ parameter problem. That seems to be unacceptable (see my previous posts for the details). There is a lint-like project for Java called Find Bugs. Bill Pugh at UMCP is leading it. I happen to know Dr. Pugh; he taught one of my courses and sponsored my senior C.S. project. If someone decides to work on a lint-like tool, I will be happy to introduce them to Dr. Pugh.
Feb 13 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
Unknown W. Brackets wrote:
 Well, it's clearly not helping them, is it?  Most programmers may or may
 not know what in the world they're doing, but most of the programmers I
 want to hire or have work with me will.
 
 All of the features you listed are there to help people who are sensible
 detect errors.  Lovely things they are, too.  But they don't just get
 used, you have to use them.  If you don't, you're no better off than if
 you didn't.
 
 Mistakes happen, but gross mistakes shouldn't.  If they do, the person
 needs to go back and bake in training/school/less important projects for
 a while.  No language can change this, however many keywords or flags it
 adds.
 
 -[Unknown]
 
 
 Most programmers are amateurs; you're not going to change that.


That's an easy one. You can't do unsafe things without wrapping your code in the unsafe keyword. That's fairly easy to add, if you ask me. However, when that amateur gets the compiler error, he/she will look it up. Once they do, there will be a big notice "DANGER, USE THIS INSTEAD". I work with a lot of EEs who only had one or two programming courses. They get a job mainly based on their hardware architecture knowledge. Now they have I have to work with them and write a hardware simulator. Oh, I don't know if you realize this, but essentially removed /in/out/inout from the D spec with my example; please go read it. If you think that people are going to use the language the RIGHT way when there is such a tempting wrong way, I suggest you look at C++ and its operator overloading.
Feb 12 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
When I went into Computer Science, practically the first thing the 
teacher showed us was "cout".  Luckily, I already knew programming well 
enough to know that was stupid, and ended up teaching a large portion of 
the students in the class basic programming concepts.

When the first thing you see is a bad example, it's really hard to fix 
things.  Agreed, D has its flukes and its documentation is not perfect, 
but I haven't seen any code encouraging the abuse of pointers, 
references, for loops, casts, or asserts for that matter.

Most amateur programmers are copy-and-paste programmers, or are being 
taught by someone else.  In either case, they usually don't really 100% 
understand what they are doing, and a "danger use this instead" notice 
won't help them.

Consider, for example, if for always suggested that you use foreach 
instead.  You are guaranteed in bounds and you can't make as many 
mistakes, after all... right?  You know what would happen, right? 
People would do this:

int for_loop[1000];
foreach (int i, int ignore; for_loop)
    writefln(i);

Isn't that the better way?  No mistakes there... just a lot more memory 
usage.  Who cares about that anyway, right?  Computers are loaded these 
days.

I don't see any example where you removed anything from any spec. 
Everything seems to work as I expected in all the examples you've given.

There's really just one way to fix mistakes.  And it's not bandaids or 
notices.  And half the point of Joel's article, which you so carefully 
chose to ignore, was that learning to understand pointers is crucial to 
general understanding and principles.

-[Unknown]


 Unknown W. Brackets wrote:
 Well, it's clearly not helping them, is it?  Most programmers may or may
 not know what in the world they're doing, but most of the programmers I
 want to hire or have work with me will.

 All of the features you listed are there to help people who are sensible
 detect errors.  Lovely things they are, too.  But they don't just get
 used, you have to use them.  If you don't, you're no better off than if
 you didn't.

 Mistakes happen, but gross mistakes shouldn't.  If they do, the person
 needs to go back and bake in training/school/less important projects for
 a while.  No language can change this, however many keywords or flags it
 adds.

 -[Unknown]


 Most programmers are amateurs; you're not going to change that.


That's an easy one. You can't do unsafe things without wrapping your code in the unsafe keyword. That's fairly easy to add, if you ask me. However, when that amateur gets the compiler error, he/she will look it up. Once they do, there will be a big notice "DANGER, USE THIS INSTEAD". I work with a lot of EEs who only had one or two programming courses. They get a job mainly based on their hardware architecture knowledge. Now they have I have to work with them and write a hardware simulator. Oh, I don't know if you realize this, but essentially removed /in/out/inout from the D spec with my example; please go read it. If you think that people are going to use the language the RIGHT way when there is such a tempting wrong way, I suggest you look at C++ and its operator overloading.

Feb 13 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Unknown W. Brackets wrote:
 Consider, for example, if for always suggested that you use foreach 
 instead.  You are guaranteed in bounds and you can't make as many 
 mistakes, after all... right?  You know what would happen, right? People 
 would do this:
 
 int for_loop[1000];
 foreach (int i, int ignore; for_loop)
    writefln(i);
 
 Isn't that the better way?  No mistakes there... just a lot more memory 
 usage.  Who cares about that anyway, right?  Computers are loaded these 
 days.
 

Ok, I really don't see why foreach should/would use more memory? Or I didn't understand something?
Feb 13 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Creating the array would use more memory.  Consider:

int for_loop[] = new int[some_undetermined_int];
...

That could use, right there, 5 megabytes.  It probably wouldn't, but it 
could.  Even so, what's the point of using the extra 4k from my initial 
example?

My meaning was that someone might create an array, and use it entirely 
and ONLY for the use of foreaching over it.  After that, the array, and 
its contents, would be ignored and not used.  Further, because delete is 
unsafe, it would not be deleted until the garbage collector picked it up.

Obviously this example is a bit out there, but I was trying to be 
illustrative.

-[Unknown]


 Unknown W. Brackets wrote:
 Consider, for example, if for always suggested that you use foreach 
 instead.  You are guaranteed in bounds and you can't make as many 
 mistakes, after all... right?  You know what would happen, right? 
 People would do this:

 int for_loop[1000];
 foreach (int i, int ignore; for_loop)
    writefln(i);

 Isn't that the better way?  No mistakes there... just a lot more 
 memory usage.  Who cares about that anyway, right?  Computers are 
 loaded these days.

Ok, I really don't see why foreach should/would use more memory? Or I didn't understand something?

Feb 13 2006
prev sibling parent S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-12 21:26:48 -0800, nick <nick.atamas gmail.com> said:

 S. Chancellor wrote:
 On 2006-02-12 19:32:47 -0800, nick <nick.atamas gmail.com> said:
 
 What's worse, I can use the function prototype:
 
 void surprise(inout A a);
 
 and the results will be exactly the same. That just seriously breaks all
 the high level language features that D puts in place. So I guess my
 question is: "Shouldn't there be a mechanism to deal with this?"

Language do not fix people. Writing software is not subject to malicious attacks by hackers. People are not intentionally injecting bad code into your software! You do not need security features built into the language. If it were up to me I'd abolish the private and protected keywords too! They're rather stupid, their intent is to "recommend" people not to use them. Quite often, especially in .NET i want to use a protected method and end up having to subclass the F*CKING class to expose it to the rest of my program. -S.

Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea. I'm just going to quote Joel here: "Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code." http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html

I frankly do not care about Joel or what his opinion is.
 
 If you're working with people who are idiots, they're going to be idiots
 regardless of a damn unsafe keyword, or a friggin' throws keyword, or
 whatever!


 When will people finally realize that stupid an unexperienced aren't the
 same thing. Some individuals who write code are mathematicians,
 physicists, or electrical engineers by training. Programming languages
 aren't just for hardcore experts like Matthew or Walter. Most
 programmers are amateurs; you're not going to change that. Furthermore,
 humans are prone to error.

For your information I'm a physicist, and I have absolutely no problem with pointers.
 If you think that safeguards aren't for you, then maybe you should
 double-check the list of D features: in/out/inout, nested functions,
 typesafe variadic arguments, contract programming, guaranteed
 initialization, and others. Are you telling me that all those should be
 thrown out because they are just there to prevent mistakes?

Sure! I end up getting annoyed when private interfaces have functions I need to use all the time. I end up having to modify the library myself, or subclass the damn thing if it's protected. It would be nice if I could just tell the compiler to shut the hell up and let me call the protected member instead. The point of those keywords are to help keep people from doing things that were not intended, not to prevent them from doing it when it is intended. And quite obviously people get too gung-ho about this and I end up having to modify the interface to the library to use a damn private method. Nonsense. Removing pointers from a systems programming language is just dumb. End - of - story. Pointers are not something you accidently do. They are not like shoving the wrong type of variable into the wrong place in an arguments list (Which typedef protects from, and no implicit conversions) or calling an internal interface accidently (Which private/protected protect from.) or calling an int with a value out of range when the interface designer wanted a discreet subset (what enums protect against) You already have to go out of your way to use pointers by using the little * symbol, that's your unsafe keyword for you right there. -S.
Feb 14 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I will skip the "pointers are unsafe" rigmarole.

 Should D provide something analogous to the C# unsafe keyword?

If "safe" means "managed" and "unsafe" means "unmanaged" then answer is no. By definition as D code is "unmanaged". To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you. Andrew.
Feb 12 2006
parent reply nick <nick.atamas gmail.com> writes:
Andrew Fedoniouk wrote:
 I will skip the "pointers are unsafe" rigmarole.

 Should D provide something analogous to the C# unsafe keyword?

If "safe" means "managed" and "unsafe" means "unmanaged" then answer is no. By definition as D code is "unmanaged". To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you. Andrew.

I didn't say I had a solution, I just said I have a problem. The "unsafe" thing is just some syntax that looked pretty cool in C#. If c-style pointers are left the way they are now, you might as well not have in/out/inout parameters. To save you from reading the rest of the thread, here is an example: CODE: ----- import std.stdio; class A { private int data[]; public this() { data.length = 10; } public void printSelf() { writefln("Data: ", this.data); } } void surprise(in A a) { byte *ap = cast(byte *)(a); ap[9] = 5; } int main() { A a = new A(); a.printSelf(); surprise(a); a.printSelf(); return 0; } OUTPUT: ------- Data before surprise: [0,0,0,0,0,0,0,0,0,0] Data after surprise: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,216,1245184,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855552,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,8855680,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855808, <..SNIP..> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
Feb 12 2006
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
All in does is effect the parameter in question.  In this case, said 
parameter is a pointer (reference, whatever you want to call it) to an 
instance of A.  You can change said instance all you like; you just 
cannot change the pointer.

Please read the documentation more carefully.

-[Unknown]


 Andrew Fedoniouk wrote:
 I will skip the "pointers are unsafe" rigmarole.

 Should D provide something analogous to the C# unsafe keyword?

If "safe" means "managed" and "unsafe" means "unmanaged" then answer is no. By definition as D code is "unmanaged". To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you. Andrew.

I didn't say I had a solution, I just said I have a problem. The "unsafe" thing is just some syntax that looked pretty cool in C#. If c-style pointers are left the way they are now, you might as well not have in/out/inout parameters. To save you from reading the rest of the thread, here is an example: CODE: ----- import std.stdio; class A { private int data[]; public this() { data.length = 10; } public void printSelf() { writefln("Data: ", this.data); } } void surprise(in A a) { byte *ap = cast(byte *)(a); ap[9] = 5; } int main() { A a = new A(); a.printSelf(); surprise(a); a.printSelf(); return 0; } OUTPUT: ------- Data before surprise: [0,0,0,0,0,0,0,0,0,0] Data after surprise: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,216,1245184,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855552,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,8855680,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855808, <..SNIP..> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

Feb 13 2006
prev sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-12 23:12:26 -0800, nick <nick.atamas gmail.com> said:

 Andrew Fedoniouk wrote:
 I will skip the "pointers are unsafe" rigmarole.
 
 Should D provide something analogous to the C# unsafe keyword?

If "safe" means "managed" and "unsafe" means "unmanaged" then answer is no. By definition as D code is "unmanaged". To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you. Andrew.

I didn't say I had a solution, I just said I have a problem. The "unsafe" thing is just some syntax that looked pretty cool in C#. If c-style pointers are left the way they are now, you might as well not have in/out/inout parameters. To save you from reading the rest of the thread, here is an example: CODE: ----- import std.stdio; class A { private int data[]; public this() { data.length = 10; } public void printSelf() { writefln("Data: ", this.data); } } void surprise(in A a) { byte *ap = cast(byte *)(a); ap[9] = 5; } int main() { A a = new A(); a.printSelf(); surprise(a); a.printSelf(); return 0; } OUTPUT: ------- Data before surprise: [0,0,0,0,0,0,0,0,0,0] Data after surprise: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,216,1245184,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

0,0,0,0,0,0,0,0,0,0,0,8855680,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855808, <..SNIP..> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] Good
 

trouble you had to go through to do it! You had to first convert it to a pointer, and then set a byte of the object to something different intentionally! I don't see how you think this can be done accidentally. It's not like "Oops, shit! I just cast that object to a pointer and randomly set a byte in it to something else!" On the other hand many of the other security features D includes helps prevent "Oops" errors. Welcome to a systems programming language. If your co-workers are intentionally doing things like this, then I am very sorry for you. -S.
Feb 14 2006
parent reply Boogeyman <Boogeyman_member pathlink.com> writes:
In article <dssk1o$1gd0$2 digitaldaemon.com>, S. Chancellor says...
On 2006-02-12 23:12:26 -0800, nick <nick.atamas gmail.com> said:

 Andrew Fedoniouk wrote:
 I will skip the "pointers are unsafe" rigmarole.
 
 Should D provide something analogous to the C# unsafe keyword?

If "safe" means "managed" and "unsafe" means "unmanaged" then answer is no. By definition as D code is "unmanaged". To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you. Andrew.

I didn't say I had a solution, I just said I have a problem. The "unsafe" thing is just some syntax that looked pretty cool in C#. If c-style pointers are left the way they are now, you might as well not have in/out/inout parameters. To save you from reading the rest of the thread, here is an example: CODE: ----- import std.stdio; class A { private int data[]; public this() { data.length = 10; } public void printSelf() { writefln("Data: ", this.data); } } void surprise(in A a) { byte *ap = cast(byte *)(a); ap[9] = 5; } int main() { A a = new A(); a.printSelf(); surprise(a); a.printSelf(); return 0; } OUTPUT: ------- Data before surprise: [0,0,0,0,0,0,0,0,0,0] Data after surprise: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,216,1245184,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

0,0,0,0,0,0,0,0,0,0,0,8855680,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855808, <..SNIP..> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] Good
 

trouble you had to go through to do it! You had to first convert it to a pointer, and then set a byte of the object to something different intentionally! I don't see how you think this can be done accidentally. It's not like "Oops, shit! I just cast that object to a pointer and randomly set a byte in it to something else!" On the other hand many of the other security features D includes helps prevent "Oops" errors. Welcome to a systems programming language. If your co-workers are intentionally doing things like this, then I am very sorry for you. -S.

Pointers are scary!
Feb 14 2006
parent reply Don Clugston <dac nospam.com.au> writes:
 Pointers are scary! 

I've heard this for decades, and I still don't really understand it. I've never found pointers to be worse than uninitialised variables. (in fact, I think many problems attributed to pointers are actually caused by uninitialised variables). And the absolute worst is languages that don't require you to declare a variable before you use it. That's _really_ scary.
Feb 21 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 Pointers are scary! 

I've heard this for decades, and I still don't really understand it. I've never found pointers to be worse than uninitialised variables. (in fact, I think many problems attributed to pointers are actually caused by uninitialised variables). And the absolute worst is languages that don't require you to declare a variable before you use it. That's _really_ scary.

I agree on both counts. And as for the latter... it's why I think languages like Lua are next to useless, as debugging them is an absolute nightmare. Sean
Feb 21 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Wed, 22 Feb 2006 03:04:19 +1100, Don Clugston <dac nospam.com.au> wrote:


 And the absolute worst is languages that don't require you to declare a  
 variable before you use it. That's _really_ scary.

When you say 'before', are you saying that forward references are not a good thing? Or do you just mean 'before' in a temporal sense. -- Derek Parnell Melbourne, Australia
Feb 21 2006
parent Don Clugston <dac nospam.com.au> writes:
Derek Parnell wrote:
 On Wed, 22 Feb 2006 03:04:19 +1100, Don Clugston <dac nospam.com.au> wrote:
 
 
 And the absolute worst is languages that don't require you to declare 
 a variable before you use it. That's _really_ scary.

When you say 'before', are you saying that forward references are not a good thing? Or do you just mean 'before' in a temporal sense.

In a temporal sense. You can strike out the words "before you use it".
 
 --Derek Parnell
 Melbourne, Australia

Feb 21 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Why don't you give them access to a scripting language?  Perhaps 
something like Python/Ruby or even DMDScript?

If performance is an issue, just make sure the scripting language 
doesn't allow eval (which is so much more evil than pointers, by the 
way) and you should be able to convert easily.

-[Unknown]


 Note: I did a search for this and didn't come up with any threads. If it
 has been discussed before... my apologies.
 
 
 Recently I introduced D to a friend of mine (a C.S. grad student at
 Purdue). His reaction was the usual "wow, awesome". Then he became
 concerned about pointer safety. D allows unrestricted access to pointers.
 
 I will skip the "pointers are unsafe" rigmarole.
 
 Should D provide something analogous to the C# unsafe keyword?

Feb 12 2006