Sounds like we are singing from the same hymn sheet. I am all for the compiler doing optimmisation wherever poss as opposed to language tweaks. Far better to have lots of compiler optimisation settings hidden away in some "RB Pro" build preference panel, instead of language.
But yes -lots more stuff to make accessing memoryblocks containing C arrays would be very nice. I am not saying that "pointer" based stuff should enter the"core" langage, but for people using the Ptr, Struct and memoryblock features a lot like I have to, they would help to make code more readable and hopefully faster. >whats to make your index any faster than the byte > offsets? the simplest way to add what you requested would likely be > slower than the byte offsets. Not sure I agree - there might be ways in which the compiler can use the CPU address calculation hardware in ways inaccessible by code. On 14/9/06 20:29, "Mike Woodworth" <[EMAIL PROTECTED]> wrote: > > On Sep 14, 2006, at 2:59 PM, Daniel Stenning wrote: > >> It depends on how carefully and elegantly it is implemented. There >> is no >> reason why such stuff need be inelegant or cluttered. >> >> All I am asking for is enough language/ compiler enhancements to >> allow >> developers to build and fine tune apps to the maximum. If RB is to >> attract >> as wide as possible a base of programmers it has to be able to enable >> professionals to optimise the code, as well as being easy for >> beginners. >> >> What I want to avoid is the "if you cant do it in RB fast enough, >> build a >> plugin" philosophy. >> >> I am of the opinion that in a truly "industrial strength" >> language , the >> only time one should have to resort to using libraries such as >> plugins, >> built in C - would be where one needs ASSEMBLER to achieve the >> necessary >> performance. Anything other performance optimisations should be >> achievable >> in the language itself. >> >> Many developers writing commercial apps avoid 3rd party libraries >> because of >> all the dependency issues and support etc. In order to attract such >> developers to the RB platform one would have to assure such >> developers that >> one can do the majority of the coding in the language itself and >> not have to >> continually resort to extra plugins or libraries to get the desired >> performance. > > I'm soooo in your camp on the need for high performance constructs in > RB... but i think we need RS to focus on makign what they have > faster, rather than hoping that additional syntax will yield faster > compiled code... whats to make your index any faster than the byte > offsets? the simplest way to add what you requested would likely be > slower than the byte offsets. > > Over the years I've heard lots of requests for syntax changes to make > things run faster - as long as the compiler isnt optimizing, there's > very little chance that new syntax will yield any speed bump. I > think our best bet is to phrase the questions such as: can we have a > way to access our memoryblocks faster - this yielded ptrs (something > which direct requests for were lambasted on this list - often by RB > folks.) > > that said... i'd like to see ptrs sped up even more... perhaps quick > ways to increment them, a way to copy arbitrary runs of bytes between > ptrs ala memcpy. even a way to alloc a ptr/memoryblock without > zeroing could come in handy and help speed up some situations. > > 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>
