"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BF2B193.5F072C80@estarcion.com...
> [1] In fact, if you want to get really ambitious, the internal "start of allocated buffer" and "array-zero-base" pointers could actually be separate, and things like:
>
> a = a[2..a.length];
>
> could simply alter the length and zero-base pointers without doing a realloc (since saving two bytes hardly seems worth the time and potential fragmentation).

That's exactly how it does work. It's so much more efficient to do slicing this way than the C way of copy and append a 0.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9t016v$303d$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9sth7s$194b$1@digitaldaemon.com...
> >
> > "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9srme1$331$1@digitaldaemon.com...
> > > Is there a simple and (probably) fast way to add a
> > > value at the end of a dynamic array?
> >
> > I'm looking at:
> >     int a[];
> >     a[] ~= 3;
>
> You sure you wouldn't it rather be more like this?:
>
> a ~= 3;
>
> It seems a, being the identifier representing the entire array, known to
the
> compiler to be dynamic, wouldn't need the []?

You might be right. I'm going to have to think carefully about that.


> Why ~=, out of curiosity?  += isn't ambiguous in that context.  I don't
see
> what the problem is with people not looking up the declarations of
variables
> they're unfamiliar with.

Overloading + with both addition and concatenation works well in most cases, but there are a few maddening ones where it just is hopelessly ambiguous. I decided that ~ as a binary operator would disambiguate it, and it will be obvious by inspection if a concatenation or an addition is happening.


> > >Is there a method
> > > that removes last element of dynamic array?
> >
> > a = a[0..a.length - 1];
>
> What's wrong with:
>
> --a.size;
>
> Oh... probably not writable.
> or maybe:
>
> a.resize(a.size-1);
>
> No, too wordy.  Perhaps:
>
> a--;
>
> The "copying" syntax you suggest seems to leave it up to the compiler to realize it can avoid the copy.  Debug builds could get very slow like
that.

It's not a problem for the compiler to optimize away the copy.

"Walter" <walter@digitalmars.com> wrote in message news:9t130m$1egm$3@digitaldaemon.com...

> Overloading + with both addition and concatenation works well in most
cases,
> but there are a few maddening ones where it just is hopelessly ambiguous.
I
> decided that ~ as a binary operator would disambiguate it, and it will be obvious by inspection if a concatenation or an addition is happening.

I believe that syntax proposed resolves this:

    a[] += 1;    // increase all elements of a by 1
    a += 1;      // add 1 at the end of a

Should be clear to everybody.

> It's not a problem for the compiler to optimize away the copy.

Still... a-- seems a good idea to me. Short and clear.

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9t0b0e$che$1@digitaldaemon.com...

> I personally think the most intuative way would be
>
>     a.shrink(1);

And a short form - a-- - then =)

"Walter" <walter@digitalmars.com> wrote in message news:9t130m$1egm$3@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message
> > The "copying" syntax you suggest seems to leave it up to the compiler to realize it can avoid the copy.  Debug builds could get very slow like
> that.
>
> It's not a problem for the compiler to optimize away the copy.

But will it do so in a debug build?

Seems a debug build could at least do a little "safe" optimization such as
(a = a + b) ==> (a += b)

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9t130m$1egm$3@digitaldaemon.com...

> > Why ~=, out of curiosity?  += isn't ambiguous in that context.  I don't
> see
> > what the problem is with people not looking up the declarations of
> variables
> > they're unfamiliar with.
>
> Overloading + with both addition and concatenation works well in most
cases,
> but there are a few maddening ones where it just is hopelessly ambiguous.
I
> decided that ~ as a binary operator would disambiguate it, and it will be obvious by inspection if a concatenation or an addition is happening.

One more thing:

"D overloads the operators ... += for char and wchar arrays to mean concatenate and append"

Since strings already work this way, why use different syntax for other arrays?

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9t15tn$1j79$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9t130m$1egm$3@digitaldaemon.com...
> > It's not a problem for the compiler to optimize away the copy.
> But will it do so in a debug build?


Does it matter? Debug builds are for debugging the algorithms. You kind of expect them to be bloated and slow <g>.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9t1aud$1qnf$1@digitaldaemon.com...
> "D overloads the operators ... += for char and wchar arrays to mean concatenate and append"

That's now no longer true. Looks like I missed fixing that in the doc.

"Walter" <walter@digitalmars.com> wrote in message news:9t2kmn$16ah$2@digitaldaemon.com...

> That's now no longer true. Looks like I missed fixing that in the doc.

So now the ~= syntax is used on strings as well?

Kinda weird. If I didn't know that it means append, and
saw it for the first time, I would rather think of it
as of remove substring from a string... or something
like that. But definitely not append. Maybe &= then -
since BASIC already uses & for string concatenation?

Use PERL's syntax, since it's C-style and PERL is a common language that includes string concatenation.

Use . as the array concatenation operator, and .= as the array append opeator :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]