I honestly think that the only way RB can attain some kind of "ubiquity" against the behemoth of Microsoft and entrenched "pro" cachet of C++, is to free advanced RB professional developers from having to resort to C just to get the desired speed. There is no reason why RB cannot be both an easy language to learn AND one that provides enough options to do things the C way where it is desired.
I would put all the pointer and Declare related stuff into the "Pro" version and leave the basic RB nice and simple for learners. RB is natively compiled already. It has a language that has many aspects similar to C without some of the "nasties". Borland Delphi gained a lot of respect for such facilities. One could even build DLLS and ActiveX objects using it. Once the nightmare of Universal Binary and Cocoa is over for the RB developers, I think there should be a push towards making RB a tool suitable for ANY usage. RB should not be a language that STOPs developers from doing "dangerous" things if they want. That means RB should be the best tool to produce DLLS, Drivers, system software and plugins. RB should also entirely eat its own dog food. RB will never leverage its cross-platform and RAD USP to yield a significant user base unless it can replace NOT only VB and Java, but also C and C++. RB needs to have C style templates, all the C range of operator overloads. ++,--, <<, += etc, Plus all those optimisation where possible. On 25/9/06 23:25, "Mike Woodworth" <[EMAIL PROTECTED]> wrote: > > On Sep 25, 2006, at 2:32 PM, Theodore H. Smith wrote: > >>> yeah, the number one trick is to work in the lowest res you can. >> >> And use a modern computer... old computers could probably do just >> as well, if you worked in C. >> >>> there are tons of other tricks, like processing every pixel in a >>> frame at once via veclib, >> >> Which is probably written in C. >> >>> or converting picture objects directly to >>> ptrs to remove RB's image access overhead. its all pretty declare >>> heavy though. >> >> To libraries written in C. >> >>> now that RB has ptrs, I've found my coding tricks have >>> changed a lot - i'm doing more and more in tight loops byte by byte. >> >> Which is doing low level stuff, like you'd do in C. >> >>> but for blurs / distortions/ fft etc, the vImage and vDSP libraries >>> on mac offer huge speed gains. And lately I've been moving more and >>> more processing to the GPU via opengl. >> >> I think you can guess my point on this one also ;) >> >> Basically, the image processing code you made in RB, you are either >> getting from using stuff made in C, or getting because RB in some >> ways is starting to overlap C's approach. >> >> All we really need is some nice proper typed pointers, a few >> syntaxy stuff like *p++ , and the compiler to optimise pointer work. >> > > so? are you trying to say you'd like the speed of C but not have to > work hard (like would still need to in C)? this kind of work isn't > ever going to be entry level. (well, not for the next few years) > personally, i'm not gonna wait around for RB to add a stereoscopic > vision control. and i think you gain very little at this point > coding projects like this in C. > > now, in the interest of harmony, i agree we should get more stuff to > help users do high speed apps. i'd suggest some compiler > optimizations for ptrs. and the one problem i see with RB that > periodically makes me pine for Xcode, is the lack of a multiprocessor > friendly framework. the fact that simple object allocations and > string operations aren't thread safe is a major PITA. > > mike > -- > Mike Woodworth > [EMAIL PROTECTED] > > > _______________________________________________ > 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>
