D - two questions
↑ ↓ ← → "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
These appeared when trying to actually write a simple
program in D, so somewhat more practical...
Is there a simple and (probably) fast way to add a
value at the end of a dynamic array? Documentation
doesn't say anything about that specifically, although
there are mentions of append() method when describing
strings. Does it work on any arrays? Is there a method
that removes last element of dynamic array?
Can "const" attribute be applied to function's return
type? An example:
class Component
{
public const Component[] Children() { return children; }
private Component[] children;
}
As you can see, I want children[] to be readable, but not
writeable from outside of class (so that noone can add
child components but the component itself). Can it be
implemented this (or any other) way?
And an idea. I suggest that using enumerations when declaring
arrays would declare arrays with number of elements equal
to number of enumeration members:
enum color { red, green, blue };
bit[color] c; // equal to bit[color.max].c;
Sometimes this can be useful, especially with bit arrays.
It also serves as at least partial emulation of Pascal sets.
↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:
Pavel \"EvilOne\" Minayev wrote:
These appeared when trying to actually write a simple
program in D, so somewhat more practical...
Is there a simple and (probably) fast way to add a
value at the end of a dynamic array? Documentation
doesn't say anything about that specifically, although
there are mentions of append() method when describing
strings. Does it work on any arrays? Is there a method
that removes last element of dynamic array?
I believe that Perl uses negative array indices to mean
"back from the end", so array[-1] refers to the last
valid element of the array. With bounds-controlled arrays,
I would think that negative indices would be free for
this use, though it would occasionally turn an erroneous
index calculation into a valid-yet-incorrect access (or,
looked at another way, it turns a bounded array into a
partial circular array). I can see a lot of arguments
against including this construct in D. :)
-RB
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"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;
Is there a method
that removes last element of dynamic array?
a = a[0..a.length - 1];
Can "const" attribute be applied to function's return
type? An example:
No. Const is a storage class in D, not a type modifier.
class Component
{
public const Component[] Children() { return children; }
private Component[] children;
}
As you can see, I want children[] to be readable, but not
writeable from outside of class (so that noone can add
child components but the component itself). Can it be
implemented this (or any other) way?
The way to do that is to make it private and access it through get/set
member functions.
And an idea. I suggest that using enumerations when declaring
arrays would declare arrays with number of elements equal
to number of enumeration members:
enum color { red, green, blue };
bit[color] c; // equal to bit[color.max].c;
Sometimes this can be useful, especially with bit arrays.
It also serves as at least partial emulation of Pascal sets.
That's a great idea, but it conflicts with the syntax of associative arrays.
↑ ↓ ← → "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9sth7s$194b$1 digitaldaemon.com...
I'm looking at:
int a[];
a[] ~= 3;
But wouldn't it interfere with the rule that:
"In general, (a[n..m] op e) is defined as:
for (i = n; i < m; i++)
a[i] op e;"
Could lead to confusion...
Is there a method
that removes last element of dynamic array?
a = a[0..a.length - 1];
I believe it's not a special, optimized case recognized
by the compiler. I mean something to remove the element
without actually relocating the entire array - in other
words, something that simply decreases its "virtual" size
without actually changing anything.
As you can see, I want children[] to be readable, but not
writeable from outside of class (so that noone can add
child components but the component itself). Can it be
implemented this (or any other) way?
The way to do that is to make it private and access it through get/set
member functions.
But that's exactly what I did! I just want it to be indexed,
but not changed. And yes, I know that I could just write
some methods for that... but wouldn't it be better to provide
common syntax for all such cases? And since I can't overload
operator[], there is no way to do it other than expose the
array itself.
Maybe some special attribute similar to C/C++ const specially
for arrays & pointers?
And an idea. I suggest that using enumerations when declaring
arrays would declare arrays with number of elements equal
to number of enumeration members:
That's a great idea, but it conflicts with the syntax of associative
Oh, sorry, I missed the point. Maybe for bit arrays only (I mean,
associative bit arrays in D are not different from int ones... or
are they?)
↑ ↓ ← → "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
Maybe some special attribute similar to C/C++ const specially
for arrays & pointers?
One more thing.
It seems quite strange to me that, while D provides
ways to declare variable passed to function as read-only
in that function, it doesn't have analogous construct
for what function returns...
↑ ↓ ← → Aaron <arh14 cornell.edu> writes:
Well, I haven't checked out the D spec in a while, but the way Java does
it, and apparently the way D also does it, is that arrays are actually
mutable objects, so you can't just make them const. Making them const
just means the *reference* cannot be modified, not the *contents* of the
reference. There is no real way around this in Java except, as Walter
says, you make the array private, and write your own getters, and simply
don't provide setters.
Passing something *in* as read only, AFAICT, is simply equivalent to
pass-by-value instead of pass-by-reference. I don't think variables
themselves should own these access flags - who knows what some method
down the road will want to do with a variable that at some point was
marked "read-only". If you want something to be read only, the best
thing to do is simply to pass a copy instead of the actual thing (this
is already done for primitives, it just needs to be done for complex
objects).
Aaron
Pavel \"EvilOne\" Minayev wrote:
Maybe some special attribute similar to C/C++ const specially
for arrays & pointers?
One more thing.
It seems quite strange to me that, while D provides
ways to declare variable passed to function as read-only
in that function, it doesn't have analogous construct
for what function returns...
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3C3EF365.24975587 cornell.edu...
Passing something *in* as read only, AFAICT, is simply equivalent to
pass-by-value instead of pass-by-reference. I don't think variables
Yep, you are right here. "in" is the default, and means that
argument is passed by value.
themselves should own these access flags - who knows what some method
down the road will want to do with a variable that at some point was
marked "read-only". If you want something to be read only, the best
thing to do is simply to pass a copy instead of the actual thing (this
is already done for primitives, it just needs to be done for complex
objects).
I have just forgotten that functions can return arrays and
associative arrays as well. With this, no problems.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Aaron" <arh14 cornell.edu> wrote in message
news:3C3EF365.24975587 cornell.edu...
Well, I haven't checked out the D spec in a while, but the way Java does
it, and apparently the way D also does it, is that arrays are actually
mutable objects, so you can't just make them const. Making them const
just means the *reference* cannot be modified, not the *contents* of the
reference. There is no real way around this in Java except, as Walter
says, you make the array private, and write your own getters, and simply
don't provide setters.
Sorry, forgot one important thing...
I don't understand why arrays cannot be const? I just want to give a list
of controls to user, so he may index it, get its length etc, but isn't
able to add/delete/modify items. Of course this can be done with methods
(these won't be settors), like:
Control item(int n) { return m_items[n]; }
Control itemCount() { return m_items.length; }
...
for (int i = 0; i < window.itemCount(); i++)
window.item(i).visible = false;
However, it looks quite different from a typical D array.
With const arrays this would be absolute transparent to user:
const Control[] items() { return m_items; }
...
for (int i = 0; i < window.items.length; i++)
window.item[i].visible = true;
There are some other properties that arrays have, for
example "dup"... methods are required to implement them
all, and it won't look like normal array.
Well anyhow Walter explained why he didn't made it in D,
so we have to live with it...
↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel \"EvilOne\" Minayev wrote:
"Walter" <walter digitalmars.com> wrote in message
news:9sth7s$194b$1 digitaldaemon.com...
I'm looking at:
int a[];
a[] ~= 3;
But wouldn't it interfere with the rule that:
"In general, (a[n..m] op e) is defined as:
for (i = n; i < m; i++)
a[i] op e;"
Could lead to confusion...
Is there a method
that removes last element of dynamic array?
a = a[0..a.length - 1];
I believe it's not a special, optimized case recognized
by the compiler. I mean something to remove the element
without actually relocating the entire array - in other
words, something that simply decreases its "virtual" size
without actually changing anything.
Why not
a.length--;
--
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))) ]
↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:
Pavel \"EvilOne\" Minayev wrote:
"Walter" <walter digitalmars.com> wrote in message
news:9sth7s$194b$1 digitaldaemon.com...
Is there a method
that removes last element of dynamic array?
a = a[0..a.length - 1];
I believe it's not a special, optimized case recognized
by the compiler. I mean something to remove the element
without actually relocating the entire array - in other
words, something that simply decreases its "virtual" size
without actually changing anything.
It's presumably as easy, or easier, for Walter to make the
compiler recognize the a = a[0..X] case and optimize it as
it would be for him to add syntax for a special case of same.
If the initial index of the slice is computed, furthermore,
the slice generator could notice a computed zero at runtime
that couldn't be guaranteed at compile time.[1]
Finally, it saves the programmer having to learn, remember, and
appropriately-use a new feature.
-RB
[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).
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"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.
↑ ↓ ← → Axel Kittenberger <axel dtone.org> writes:
The way to do that is to make it private and access it through get/set
member functions.
I don't see how get/set functions would help this, okay you do not need to
return 'const obj **' (C speaking) an array of constant objects... but you
would still need to return the object beeing requested by
get_obj(object_number), like in your case 'obj *' (C speaking again), but
how can I tell the caller without a const attribute in the sense of
"contract programming" "please just look, but don't touch that object"?
- Axel
--
|D) http://www.dtone.org
↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:
"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 []?
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.
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.
Sean
↑ ↓ ← → Axel Kittenberger <axel dtone.org> writes:
What's wrong with:
--a.size;
Oh... probably not writable.
or maybe:
a.resize(a.size-1);
No, too wordy. Perhaps:
a--;
There is always a philsophic discussion how "decorated" a standard API
should be, minimal (small is beautiful) or enlarged with a function for
every possible task (even is reduntant.
I personally think the most intuative way would be
a.shrink(1);
- Axel
--
|D) http://www.dtone.org
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"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> writes:
"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
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
what the problem is with people not looking up the declarations of
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
It's not a problem for the compiler to optimize away the copy.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9t130m$1egm$3 digitaldaemon.com...
Overloading + with both addition and concatenation works well in most
but there are a few maddening ones where it just is hopelessly ambiguous.
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.
↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:
"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
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> writes:
"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.
Does it matter? Debug builds are for debugging the algorithms. You kind of
expect them to be bloated and slow <g>.
↑ ↓ ← → Axel Kittenberger <axel dtone.org> writes:
Sean L. Palmer wrote:
"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
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
Take a look at the GNU toolchain if you want to. gdb and gcc are together
perfectly able to directly debug optimized code, with gcc/gdb it is
generally not necessary to turn of the optimizer to be able to debug, at
last I've never had to. With the advantage you can debug the thing like it
really is. The only time I personally encountered debug builds vs. real
builds was in the micrsoft toolchain, and how often did it happen that the
application runs perfectly as debug build, but crashes as release?
- Axel
--
|D) http://www.dtone.org
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"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
what the problem is with people not looking up the declarations of
they're unfamiliar with.
Overloading + with both addition and concatenation works well in most
but there are a few maddening ones where it just is hopelessly ambiguous.
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?
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"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.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"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?
↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF54058.8FF6F560 deming-os.org...
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 :)
Noooooo!!!
(I hate Perl "."-concatenating!)
↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
???
I'd be interested why it's so bad. I have only a little experience with PERL,
but it seemed to work fairly well as a syntax.
--
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))) ]
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF55275.C595CC1D deming-os.org...
I'd be interested why it's so bad. I have only a little experience with
but it seemed to work fairly well as a syntax.
First of all, I don't see any "meaning" in it... using "+"
for concatenation seems most logical, "&" - "and" - is
not the worst choice as well. But definitely not "."
The second thing is that in D context, dot is already
used for other purpose. In fact, it could lead to confusion:
char[] a;
char length;
a[].length; // concatenate
a.length; // get length of a
↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF55275.C595CC1D deming-os.org...
I'd be interested why it's so bad. I have only a little experience with
but it seemed to work fairly well as a syntax.
First of all, I don't see any "meaning" in it... using "+"
for concatenation seems most logical, "&" - "and" - is
not the worst choice as well. But definitely not "."
The second thing is that in D context, dot is already
used for other purpose.
I'll just point out here that while both those arguments
are valid in the D context, neither is valid in the Perl
context[1].
-RB
[1] Strings and numbers are automatically convertible,
so that "1.0" + "2.0" = "3.0" (or maybe just "3" or "3."),
likewise &, so those aren't free for concatenation.
Perl generally uses {} or -> for object membership.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BF58CF9.62606AF3 estarcion.com...
First of all, I don't see any "meaning" in it... using "+"
for concatenation seems most logical, "&" - "and" - is
not the worst choice as well. But definitely not "."
The second thing is that in D context, dot is already
used for other purpose.
I'll just point out here that while both those arguments
are valid in the D context, neither is valid in the Perl
context[1].
I know about the second (but we were talking about
D, no?). Still, I don't see any reason for using dot,
whether it is in Perl or in any other language. It's
not intuitive.
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
My problem with . as concatenation is the . binary operator is already in
use, and I was afraid the . would be too small.
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF55275.C595CC1D deming-os.org...
???
I'd be interested why it's so bad. I have only a little experience with
but it seemed to work fairly well as a syntax.
--
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))) ]
↑ ↓ ← → a <a b.c> writes:
Pavel Minayev wrote:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF54058.8FF6F560 deming-os.org...
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 :)
Noooooo!!!
(I hate Perl "."-concatenating!)
Um, I second this. I liked it enough in perl, but the timing is wrong
if perl is the justification. Perl 6 is supposed to use the binary .
operator for member dereferencecs. They are planning to have an _
operator I believe. It will require white space before and after it.
Dan
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t30p7$1rn5$1 digitaldaemon.com...
"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.
Yes.
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?
D needed an operator token that was not already in use.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9t4v38$13t3$3 digitaldaemon.com...
That's now no longer true. Looks like I missed fixing that in the doc.
Yes.
And what about string concatenation? Is "~" used for this
as well?
D needed an operator token that was not already in use.
Why? You can't add anything to char in D (since it's not
integer), or ain't I right?
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t53i1$16mq$2 digitaldaemon.com...
"Walter" <walter digitalmars.com> wrote in message
news:9t4v38$13t3$3 digitaldaemon.com...
That's now no longer true. Looks like I missed fixing that in the
So now the ~= syntax is used on strings as well?
Yes.
And what about string concatenation? Is "~" used for this
as well?
As a binary operator, yes.
D needed an operator token that was not already in use.
integer), or ain't I right?
Sure you can add to chars. That's how to convert upper case to lower case!
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9t6hcs$24ek$1 digitaldaemon.com...
As a binary operator, yes.
Oh my god... =)
My point here: don't introduce completely new things. Not
only C-heads will misunderstand you, but also most other
programmers - whose experience tells that ~ is a "not".
Use some existing solution. For example, Lua uses ..
for string concatenation, and I remember I saw it somewhere
else, so we have another candidate. And there might be
other suggestions here...
Sure you can add to chars. That's how to convert upper case
to lower case!
I always thought that the proper way to convert upper case to
lower case is to set or reset the appropriate bit, since it
works correctly even on already lower(upper)-cased chars...
so is it possible to use & and | on chars?
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t6j40$25c8$1 digitaldaemon.com...
My point here: don't introduce completely new things. Not
only C-heads will misunderstand you, but also most other
programmers - whose experience tells that ~ is a "not".
Use some existing solution. For example, Lua uses ..
for string concatenation, and I remember I saw it somewhere
else, so we have another candidate. And there might be
other suggestions here...
.. is already in use as the array slice operator. I'm not wedded to ~, it
just seems the best compromise.
Sure you can add to chars. That's how to convert upper case
to lower case!
lower case is to set or reset the appropriate bit, since it
works correctly even on already lower(upper)-cased chars...
so is it possible to use & and | on chars?
Yes. All the arithmetic ops work on them.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9t9hht$rtp$1 digitaldaemon.com...
.. is already in use as the array slice operator. I'm not wedded to ~,
it just seems the best compromise.
Maybe "$" then?
Yes. All the arithmetic ops work on them.
Then what's the difference between char and ubyte?
↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:
Several printable ascii symbols are not used by D: $, #, , \
(backslash), and ` (back quote)
I vote for # or ## to be the concatenation operator, since that is what it
did in the C preprocessor. Fits, and it's fairly close to home as D is
based on C/C++. Then append could be #= or ##= !
It'd probably be good to have one of these indicate an identifier or keyword
that is a compiler-dependent language extension.
Alternatively one of these could be allowed in a user-defined identifier.
This would be useful for instance in settor member functions and
constructors like so:
class Foo
{
int a;
int b;
this(int a, int b) { a = a; b = b; }
void seta(int a) { a = a; }
void setb(int b) { b = b; }
}
Maybe is too ugly. But if _x is the form system identifiers take, then
user identifiers must use some other means to denote things such as x' =
f(x) etc. Maybe backquote... int x` = f(x);
I'm all for getting rid of case sensitivity in identifiers, it causes
problems in day-to-day programming. Not hard problems usually, but annoying
sometimes... mainly "I'm used to this capitalization style but the library
uses that capitalization style." But with case sensitivity you can at least
do: int X = f(x);
Sean
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9ta55f$1760$1 digitaldaemon.com...
"Walter" <walter digitalmars.com> wrote in message
news:9t9hht$rtp$1 digitaldaemon.com...
.. is already in use as the array slice operator. I'm not wedded to ~,
it just seems the best compromise.
Maybe "$" then?
Yes. All the arithmetic ops work on them.
Then what's the difference between char and ubyte?
↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:
"Sean L. Palmer" wrote:
Several printable ascii symbols are not used by D: $, #, , \
(backslash), and ` (back quote)
I vote for # or ## to be the concatenation operator, since that is what it
did in the C preprocessor. Fits, and it's fairly close to home as D is
based on C/C++. Then append could be #= or ##= !
I second this nomination, preferring # for binary string concatenation
and #= being appendature.
-RB
↑ ↓ ← → "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:9ta55f$1760$1 digitaldaemon.com...
"Walter" <walter digitalmars.com> wrote in message
news:9t9hht$rtp$1 digitaldaemon.com...
.. is already in use as the array slice operator. I'm not wedded to ~,
it just seems the best compromise.
Reasons?
Yes. All the arithmetic ops work on them.
Then what's the difference between char and ubyte?
You can overload them independently.
↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9tajkt$1gne$1 digitaldaemon.com...
Maybe "$" then?
Reasons?
It doesn't yet have any meaning in C/C++ context, so no
chance of understanding its wrong.
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next