There are lots of ways in which we can already do "unsafe" things - particularly using ptr or memoryblock in conjunction with declares.
But im fine with that. Those features are for fairly advanced use anyway, and with caveats, I'd rather have the freedom to use this stuff rather than do without it, merely so RB can apply its normal safety net. I agree it would be nice to add type safety to pointers by typing them like C , but from what I've gleaned so far, RS does not want to go down that path. I kind of agree about this too to some extent - I wouldnt want pointers to become part of mainstream RB - but it would be very useful to have just enough in order to deal with memory blocks and ptr when needed, either for performance reasone when absolutely required, or just readability. The key issue in my mind should be to add just enough to allow us to achieve C- like performance or better - ( and memory flexibility when needed ) when that is needed. I think there could be some provision added to give some optional primitive bounds checking - maybe something like Dim p as Ptr bounds 512 This would make the RB compiler prevent any operation on p that falls beyond 512 bytes of the pointer - whenever #bounds checking has been enabled in the compiler. Another possibility might be dot notation: p.bound = 512 but since ptr isnt a reference type I'm not sure how this would be done. I am all for the dim p as ptr(uint8) = m.ptr(0) The c = *p++ heresy of course :) I do wish we had the ++ and -- keywords, they would make life Easier, but NOT with postincrement or preincrement confusion, Simply to be able to write I++ on a single line would be enough ( I note that VB.net now += and -= , shouldn't that mean the RS supports this too eventually for compatibiity ? ) On 15/9/06 00:35, "Theodore H. Smith" <[EMAIL PROTECTED]> wrote: >> From: Daniel Stenning <[EMAIL PROTECTED]> >> Date: Thu, 14 Sep 2006 22:33:04 +0100 >> >> Currently to use pointers for speed we would do something like : >> ( or use malloc() ) >> >> dim m as new MemoryBlock(800) >> dim p as ptr = m.Ptr(0) > > I'm not using RB2007 or whatever the number is, but I'm curious... > Does this ptr allow you to corrupt the RAM? > > Without this "feature", I don't think I'd be interested ;) > > Also, will RB allow for typed pointers? > > So you can do stuff like this: > > dim c as uInt8 > dim p as ptr(uint8) = m.ptr(0) > > c = *p++ // :) > > Also, seeing as RB is heading down this very perilious and "unsafe" > path... > > Shouldn't RB add some kind of "safe" keyword? I think MS's C# has > such a keyword. It lets you distinguish between code which cannot > possibly corrupt RAM, and code which could. > > The way RB is heading, one of the biggest complaints about plugins, > which is the idea that they are unstable... RB code itself will be > causing such RAM corruptions with a proper pointer class. > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
