Les Baker wrote:
>>What if this "symmetric" indexing is done through a separate property?
>>The [] operator remains the same, and you invent a new property such as:
>>
>>char a = str.at(i);
> I second this. Just three more characters than a normal array access.
>>This new property would do symmetric indexing, and ... well ... upper
> bounds
>>checking?
> 
> I kinda thought the "ring" property was neat too, but I don't know how that
> would fit into this scheme (would "at" do that kind of access? probably
> not...). I do think that this is great; C++'s vector does this same thing,
> its [] operator is direct access and its .at() function is exactly like
> this. It's a clear bonus for D because C++ would be using the same syntax,
> and Walter seems concerned about attracting & transitioning those users to
> D, so those users would be immediately comfortable with this syntax.

A negative indexing method should still do bounds checking, so .at and .ring would have different semantics.  I can see the methods as being:

a.at (x) = a [x < 0 ? x + a.length : x];
a.ring (x) = a [((x % a.length) + a.length) % a.length];
a.saturate (x, y) = a [x < 0 ? y : x >= a.length ? y : a [x])
a.mirror (x) = bloody complex

>>I think this combination would result in maximum runtime performance.
>>If we don't have the opportunity to build own dynamic array types (lack of
>>[] operator overload),
>>then the built-in array type should be feature-rich.
> 
> Since the basic array type cannot be overloaded (and that's kinda good in a
> way for consistency, but bad for extending it), I think that is why everyone
> is concerned about the built in array type(s) being just right; it has to be
> "good enough" for 99.5% of situations, and I don't see a STL for D coming
> along (for that 0.5% of code) unless D gets really popular.

Then I hope D never becomes popular.  :-)

> Now a question: according to the "Memory Model" document, dynamic arrays
> have their first dword pointing to the start of the data, so (for example)
> an array located in memory at 0xF0000000 would have as its first four bytes
> 0xF0000008. When doing an array access why can't it be *assumed* that the
> array data starts eight bytes into the array. So say you coded "aNumber =
> myIntegers[5];", then the value at (pointer to array) + (element number *
> type scalar + 8 bytes) would be accessed. Then the unused first four bytes
> could be used for other things. I know there's probably a good reason for
> the current setup, I just don't know what it is, or I could be missing
> something entirely.

The memory model page is wrong; it should distinguish between stack objects and heap objects.  Arrays are stack objects that take eight bytes, a length and then a data pointer (in the opposite order to the memory model page); the data they point to are just a flat array with no information.  If any data were stored in the array you wouldn't be able to do slicing.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:anf85d$1c99$1@digitaldaemon.com...
> >
> >Basic is a fine language if your program is less than 24 lines long. I
don't
> >see it as a competitor for C++ or D, it serves a completely different
need.
> >Even if VB vanished tomiorrow, VB programmers won't switch to C++.
They'll
> >switch to javascript, Perl, Python or something similar.
> >
>
> You missed my point completely here.  The point was that Visual Basic
fails
> catastrophically on all benchmark performance tests, yet conquered the
market.

D is meant to be a sucessor to C++ not VB, so whether D is fast enough for people using VB is irelevant, what is important is whether it is fast enough to attract people using C++.


> The fact that VB users would switch to Python, not C++, only proves the
point
> more emphatically:  performance is not the trump suit.  It does not prove
that
> they serve different needs at all.

Your argument is like saying 'some people walk to work so therefore most people dont care how long it takes otherwise they would be in cars!' All you prove is that VBers car little about speed, not progranmers in general. There are even some of us still using assembler ;) Speed is important to many people.

chris

I rewrote two functions in assembler yesterday for PS2 VU0.  :)  Got down to only taking about half the time pretty easily.

When you do need performance, you absolutely do need it.  Having to resort to extern "C" or asm isn't a good solution and should be reserved for last resort.  That means D should be pretty damn fast by default.  If some language feature is going to sac performance it should be avoidable.  Right now you can avoid virtual function call overhead (if you use structs or global functions).  You should be able to avoid negative index checking.

Sean

"chris jones" <flak@clara.co.uk> wrote in message news:ankh38$t5e$1@digitaldaemon.com...
>
> Your argument is like saying 'some people walk to work so therefore most people dont care how long it takes otherwise they would be in cars!' All
you
> prove is that VBers car little about speed, not progranmers in general. There are even some of us still using assembler ;) Speed is important to many people.
>
> chris

Hi Chris and Sean!


Chris wrote:
> D is meant to be a sucessor to C++ not VB, so whether D is fast enough for people using VB is irelevant, what is important is whether it is fast enough to attract people using C++.

I did not say that D is an heir to VB.  I said that if D wants to succeed in the marketplace, then certain issues come into play, and VB offers important lessons about those issues.


Chris wrote:
> Your argument is like saying 'some people walk to work so therefore most people dont care how long it takes otherwise they would be in cars!' All you prove is that VBers car little about speed, not progranmers in general.

No.  The success of VB shows that lots of "programmers in general" -- not just "some" -- consider other things than speed in selecting a language.  This fact is easy to quantify.  Monster.com is one of the top job boards in the nation. Keyword "Visual Basic" yields 2853 jobs, while "C++" yields 2543 jobs.  That is better than 1:1 in favor of VB.


Sean wrote:
> When you do need performance, you absolutely do need it.  Having to resort to extern "C" or asm isn't a good solution

I call your five and raise you five:  when you absolutely need to finish a project, you absolutely need the language features to finish it.


Regards-

Mark

You are right.  Just try not to unnecessarily degrade global program performance ala SEH.  ;)

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:anlu5i$2aa4$1@digitaldaemon.com...
> Sean wrote:
> > When you do need performance, you absolutely do need it.  Having to
resort
> > to extern "C" or asm isn't a good solution
>
> I call your five and raise you five:  when you absolutely need to finish a project, you absolutely need the language features to finish it.
>
>
> Regards-
>
> Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:anf85d$1c99$1@digitaldaemon.com...
> People are doing a lot more with VB than writing 24-line programs.
Serious,
> real-world programs are written with VB all day long, and people make good
money
> doing it.

Of course you're right. What I think happens is that people get sucked into VB because it's so easy to write 24 line programs in it, and just keep extending things from Inertia. The larger a program is the more important the organizational abilities of the language become. VB doesn't offer much of that. I think it takes a far better programmer to make a 30000 line VB program work than a 30000 line C++ program.

And I think it takes a far better programmer to make a 30000 line C++ program work than a 30000 line D program (even including the fact that D can represent the same algorithm with a lot fewer lines of code).

>What I think happens is that people get sucked into
>VB because it's so easy to write 24 line programs in it, and just keep
>extending things from Inertia

It's easy to write 24 line program in any language.  My VB developer friends also know C++, but use VB for its RAD qualities -- the ability to write quickly something large enough to do useful work.  From their viewpoint it's actually the larger programs that matter, not the 24-line toys.

I hope that D can manage to attract VB programmers as well as C++ programmers. It's also worth remembering that C++ hasn't won any language design beauty contests, either.

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ano8se$2edq$1@digitaldaemon.com...
> I hope that D can manage to attract VB programmers as well as C++
programmers.

That would be possible only if some VB-like RAD environment was added.

> It's also worth remembering that C++ hasn't won any language design beauty contests, either.

I find any non-trivial C++ template code to be very hard to examine, which was a big motivator to try and come up with a better syntax for D.

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:an9rsm$1co6$1@digitaldaemon.com...
> One of the problems I have with "ease of programming" over performance is
that
> if I have a language that provides performance, I can make inline
functions to
> provide functionality.  But if my language forces the functionality on me
at the
> expense of performance, I cannot get the performance back without
resorting to a
> lower level language.

Yes, my thoughts exactly.

I answered this remark in an earlier post.  Let's give programmers choices where possible.  Don't think in terms of a zero-sum game.

Mark