bearophile Wrote:
Now, back to the topic: putting arguments into a single () or {} instead of a
(){ return ;} (or with the = of C#) helps the eye see a single visual object
isntead of two, this helps the human parsing of the code, improving visual
chunking and reducing noise.
I also
My point is that it's a redundant check. Whether it is there or not, the result
is the same--the program will halt. Maybe the error message form enforce will
look nicer, but that's about it.
Brad Roberts Wrote:
Bartosz Milewski wrote:
Of course, enforce(mdgt); is there only for
Weed Wrote:
The code on C++ is also approximately in 6 times faster a code with
classes on D. (I do not give an example on C++ because classes on C++
work just as structures in D.)
class C {
int i;
real[5] unused; // to prevent returning this object in registers
C opAdd( C
Denis Koroskin Wrote:
Could be used as follows:
foo( (i) { ++i; } );
Holy shi-
Now feel some real power, Luke. :)
foo( i = ++i );
foo((i){ ++i; }); // error
foo((i){ ++i; return;}); // unambiguous
foo((i){ return ++i;}); // unambiguous
On Mon, 09 Feb 2009 13:24:46 +0300, Kagamin s...@here.lot wrote:
Denis Koroskin Wrote:
Could be used as follows:
foo( (i) { ++i; } );
Holy shi-
Now feel some real power, Luke. :)
foo( i = ++i );
foo((i){ ++i; }); // error
foo((i){ ++i; return;}); // unambiguous
foo((i){
I vote yes.
I was pretty sure the topic was refering to the ability to specify a pointer
that could not be set to 0.
I totally agree with this rule, and enforce it in all my C++ code with smart
pointers.
class X
{
};
X x; //in D
or X * x; //in C++
Setting x to zero or any other value that
Jason House:
Non-nullable types should be implicitly castable to nullable types when
making function
calls that don't support them.
An explicit cast may be better/safer.
Bye,
bearophile
I think it makes no sense to have nullable pointers in a high level language
like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
If the class has a ctor then we can write X x(32); instead of X x
Alex Burton:
( actually why don't I start a new thread about this)
I suggest you to start a new thread (and to try to explain yourself a bit
better).
Bye,
bearophile
Denis Koroskin Wrote:
That was just an example. Those short lambdas are often used as predicates.
Compare:
findAll(array, (i) { i 3; });
findAll(array, (int i) { return i 3; });
well... you pwnd me :)
Weed Wrote:
Well, D class code here is not equivalent to C++ class code. D code has
more features, namely, it's polymorphic: C.opAdd is able to work with
classes, derived from C, while corresponding C++ code is unable to do so.
It is really true?
Of course.
There opAdd is only for
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to
mean X x = 0; then we can have X x; mean X
On 2009-02-08 23:19:55 -0500, Brian digitalm...@brianguertin.com said:
On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
So, let's ask the community: Would you like to see nullable types in D?
http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
by voting multiple
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level language
like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
If the class has a ctor then we can write X
On 2009-02-08 23:43:13 -0500, Weed resume...@mail.ru said:
Michel Fortin пишет:
On 2009-02-08 09:30:08 -0500, Weed resume...@mail.ru said:
Let's assume, polymorphism is necessary to these objects
Polymorphism doesn't work very well while passing objects by value, even
in C++. This is
On 2009-02-09 06:41:59 -0500, Ary Borenszweig a...@esperanto.org.ar said:
How would you do this?
X x;
if(someCondition) {
x = new SomeX();
} else {
x = new SomeOtherX();
}
Well, the declaration could be transformed to this:
X x = new X;
But since x is not used before being
Ary Borenszweig wrote:
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to
mean X x = 0; then we can have X x; mean X x = new X;
If the class has a
On 2009-02-09 07:00:56 -0500, Weed resume...@mail.ru said:
No. By forbiding the cases that leads to slicing, like returning a
polymorphic object by value.
Let's think, can there are other ways to solve problem?
Here, for example my reasons:
Weed Wrote:
Well, D class code here is not equivalent to C++ class code. D code has
more features, namely, it's polymorphic: C.opAdd is able to work with
classes, derived from C, while corresponding C++ code is unable to do so.
But I do not understand in what here problem. In C++ is
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
The slicing problem exists in spades in this example, or better put its
converse (your code will fire asserts when it shouldn't). The reason is
rather subtle, so please try the code out to edify yourself.
You're referring to the automatically
Daniel Keep wrote:
I've used ref arguments in the past to wrap a C api that expects
pointers. I'm fine with this so long as there is a way to break out of
it (in regular D, at least) that makes it abundantly clear you need to
know what you're doing.
Something like:
void wrapSomeCApi(ref Foo
Denis Koroskin wrote:
On Mon, 09 Feb 2009 11:24:09 +0300, Bartosz Milewski
bart...@relisoft.com wrote:
My point is that it's a redundant check. Whether it is there or not,
the result is the same--the program will halt. Maybe the error message
form enforce will look nicer, but that's about
Brian wrote:
On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
So, let's ask the community: Would you like to see nullable types in D?
http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
by voting multiple time)
Explain your reasoning in newsgroups. Thank you.
Brian wrote:
On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
So, let's ask the community: Would you like to see nullable types in D?
http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
by voting multiple time)
Explain your reasoning in newsgroups. Thank you.
Michel Fortin wrote:
On 2009-02-09 07:00:56 -0500, Weed resume...@mail.ru said:
No. By forbiding the cases that leads to slicing, like returning a
polymorphic object by value.
Let's think, can there are other ways to solve problem?
Here, for example my reasons:
Christopher Wright Wrote:
Daniel Keep wrote:
I've used ref arguments in the past to wrap a C api that expects
pointers. I'm fine with this so long as there is a way to break out of
it (in regular D, at least) that makes it abundantly clear you need to
know what you're doing.
Michel Fortin wrote:
On 2009-02-09 06:41:59 -0500, Ary Borenszweig a...@esperanto.org.ar said:
How would you do this?
X x;
if(someCondition) {
x = new SomeX();
} else {
x = new SomeOtherX();
}
Well, the declaration could be transformed to this:
X x = new X;
But since x is not
Weed wrote:
And if I need some different such combinations? For each it is necessary
to write such 8-10 lines? This is terrible!
You need to add those lines for every method you need virtual dispatch
with for your value type. It's an overhead of three lines per method,
two for the interface
Kagamin wrote:
Christopher Wright Wrote:
D:
void foo(void delegate(int) dg);
C#:
delegate void SomeName(int i);
void foo(SomeName dg);
Does C# 3 fix this? I've seen the new syntax for defining delegates, but
not for using them.
C# got anough rope for this :)
Kagamin:
Well, D class code here is not equivalent to C++ class code. D code has more
features, namely, it's polymorphic: C.opAdd is able to work with classes,
derived from C, while corresponding C++ code is unable to do so. If you can't
use polymorphism, why do you use classes?
I'd like to
Michel Fortin пишет:
On 2009-02-09 07:00:56 -0500, Weed resume...@mail.ru said:
No. By forbiding the cases that leads to slicing, like returning a
polymorphic object by value.
Let's think, can there are other ways to solve problem?
Here, for example my reasons:
Christopher Wright пишет:
Weed wrote:
And if I need some different such combinations? For each it is necessary
to write such 8-10 lines? This is terrible!
You need to add those lines for every method you need virtual dispatch
with for your value type. It's an overhead of three lines per
Ary Borenszweig wrote:
How would you do this?
X x;
if(someCondition) {
x = new SomeX();
} else {
x = new SomeOtherX();
}
One option is the turn everything into an expression route. This is
what Nemerle (think a functional superset of C#) did, and it's just
BEAUTIFULLY
On Mon, Feb 9, 2009 at 3:19 AM, Bartosz Milewski bart...@relisoft.com wrote:
bearophile Wrote:
Now, back to the topic: putting arguments into a single () or {} instead of
a (){ return ;} (or with the = of C#) helps the eye see a single visual
object isntead of two, this helps the human
Weed wrote:
Christopher Wright пишет:
Weed wrote:
And if I need some different such combinations? For each it is necessary
to write such 8-10 lines? This is terrible!
You need to add those lines for every method you need virtual dispatch
with for your value type. It's an overhead of three
Denis Koroskin wrote:
Christopher Wright Wrote:
Daniel Keep wrote:
I've used ref arguments in the past to wrap a C api that expects
pointers. I'm fine with this so long as there is a way to break out of
it (in regular D, at least) that makes it abundantly clear you need to
know what
Jarrett Billingsley:
auto r = find!(\a - a.Weight 100)(range);
[...]
something(\a, b
{
stmt1;
stmt2;
});
This looks better to me (but I don't know if this is the best syntax, it's just
an idea):
// syntax for lambda that contains a single expression, implicit return (this
is
// syntax for lambda that contains a single expression, implicit return (this
is the most common case):
auto r = find!(a = a.Weight 100)(range);
I really like this one, but I'd prefer something like
auto r = find(range, {a - a.Weight 100});
Note the - instead of the =, to avoid any
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level language
like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
If the class has a ctor then we can write X
Daniel Keep wrote:
One option is the turn everything into an expression route. This is
what Nemerle (think a functional superset of C#) did, and it's just
BEAUTIFULLY expressive.
X x = if( someCondition ) new SomeX(); else new SomeOtherX();
Failing that, there's always this (note: didn't do
Christopher Wright Wrote:
Michel Fortin wrote:
On 2009-02-09 06:41:59 -0500, Ary Borenszweig a...@esperanto.org.ar said:
How would you do this?
X x;
if(someCondition) {
x = new SomeX();
} else {
x = new SomeOtherX();
}
Well, the declaration could be transformed
grauzone Wrote:
I really like this one, but I'd prefer something like
auto r = find(range, {a - a.Weight 100});
Note the - instead of the =, to avoid any ambiguities with the
comparison operator.
Let's play more; then what do you think about (all the following are legal):
auto r1 =
bearophile:
auto r1 = range.find((ArrayType1!(typeof(range)) x) { return x.weight 100;
});
Better:
auto r1 = range.find((BaseType1!(typeof(range)) x) { return x.weight 100; });
Of course, you have to specify range twice there, and that's not good.
Bye,
bearophile
bearophile wrote:
grauzone Wrote:
I really like this one, but I'd prefer something like
auto r = find(range, {a - a.Weight 100});
Note the - instead of the =, to avoid any ambiguities with the
comparison operator.
Let's play more; then what do you think about (all the following are
Walter Bright wrote
Don wrote:
The irony is that's Walter's the biggest goto advocate I know, other than
Linus Torvalds.
I don't mind being compared to Linus g.
If you like, I can name several not-so-spectacular coders that I know who
like to use goto ;)
-Steve
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
The slicing problem exists in spades in this example, or better put its
converse (your code will fire asserts when it shouldn't). The reason is
rather subtle, so please try the code out to edify yourself.
You're referring to the automatically
Daniel Keep wrote:
I've used ref arguments in the past to wrap a C api that expects
pointers. I'm fine with this so long as there is a way to break out of
it (in regular D, at least) that makes it abundantly clear you need to
know what you're doing.
Something like:
void wrapSomeCApi(ref Foo
bearophile wrote:
Jason House:
Non-nullable types should be implicitly castable to nullable types when making
function
calls that don't support them.
An explicit cast may be better/safer.
Non-nullable types are proper subtypes of nullable types. There is no
added safety in requiring a
Denis Koroskin wrote:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to
mean X x = 0; then we
Andrei Alexandrescu Wrote:
Jason House wrote:
What constitutes escaping?
The callee tucks away the address of the ref parameter, or the address
of a direct field of it.
Ok, so this is head-escape analysis instead of transitive escape analysis.
Still, there are a few issues that I can
Steven Schveighoffer wrote:
Andrei Alexandrescu wrote
The compiler's escape detection mechanism can't help quite a lot here
because the escape hatch is rather indirect.
Initially I thought SafeD should prevent such escapes, whereas D allows
them. Now I start thinking the pattern above is
Frits van Bommel wrote:
Daniel Keep wrote:
One option is the turn everything into an expression route. This is
what Nemerle (think a functional superset of C#) did, and it's just
BEAUTIFULLY expressive.
X x = if( someCondition ) new SomeX(); else new SomeOtherX();
Failing that, there's
Andrei Alexandrescu Wrote:
Denis Koroskin wrote:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take away the
Andrei Alexandrescu:
Non-nullable types are proper subtypes of nullable types. There is no
added safety in requiring a cast.
Yes, sorry, often I misunderstood (I was thinking of the opposite situation).
Bye,
bearophile
On Mon, 09 Feb 2009 04:19:55 +, Brian wrote:
On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
So, let's ask the community: Would you like to see nullable types in D?
http://www.micropoll.com/akira/mpview/539369-138652 (please, don't
abuse by voting multiple time)
Explain
Christopher Wright wrote:
Oh, and I vote no. I think it's needless complexity. I code without any
special care for null objects, and I get a segfault or
NullReferenceException maybe once a week, probably less. I've always
been able to track down the bug very quickly.
That misses the point
On Mon, 09 Feb 2009 18:20:56 +, Brian wrote:
well, at the very least id like to see a (optional) warning/error for
uninitialized pointers. This way I can be certain there are absolutely
zero null pointers unless the null keyword itself is used. A quick
search for 'null' would be guaranteed
What bothers me is that this is equivalent to saying that a seg fault caused by
null dereference can be caught only if the programmer puts explicit runtime
checks before it happens. I would say that reaks of C philosophy, except that
in most C++ implementation I've been working with you can
On Mon, 09 Feb 2009 15:53:59 +0300, Don nos...@nospam.com wrote:
Michel Fortin wrote:
On 2009-02-09 07:00:56 -0500, Weed resume...@mail.ru said:
No. By forbiding the cases that leads to slicing, like returning a
polymorphic object by value.
Let's think, can there are other ways to solve
Andrei Alexandrescu wrote:
So the problem exists since you are trusting the programmer to avoid it.
The slicing problem exists in the sense that it is possible for a bad
programmer to accidentally slice an object. However:
- This is not a problem with the language, but an avoidable programmer
Ary Borenszweig Wrote:
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean
X x = 0; then we can have X x; mean X x = new X;
If
On Mon, 09 Feb 2009 14:41:59 +0300, Ary Borenszweig a...@esperanto.org.ar
wrote:
[skip]
How would you do this?
X x;
if(someCondition) {
x = new SomeX();
} else {
x = new SomeOtherX();
}
Note: I am not talking about an X x(42); shortcut now, see the subject.
This is a good question,
On 2009-02-09 16:02:10 -0500, Denis Koroskin 2kor...@gmail.com said:
The one case I could think of was the strategy pattern: no data is
added (including, no virtual functions) -- the only thing that's added
is a different implementation of an existing virtual function. In such
a situation,
Denis Koroskin wrote:
Andrei Alexandrescu Wrote:
Denis Koroskin wrote:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit redundant, if we take
Daniel Keep Wrote:
Alex Burton wrote:
Daniel Keep Wrote:
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
Oh, and how do you intend to make linked lists? Or trees? Or any
non-trivial data structure?
I am not
/** Just a simple hack to have interfaces implemented by structs ...
because I can :P
Tested on DMD 1.039 [win32], GDC (various versions) [linux32] and
codepad.org
Output:
Entering main
Foo.func1 called ; val1 = 3.141590, val2 = Hello, world!
Foo.func2 called ; val1 = 3.141590, val2 = Hello,
Chad J wrote:
Hawt!
I take it this can be done without assembly?
Should be doable, but with more pain and overhead (the generated
functions would need to pass all parameters to the real ones and you'd
have to take care of ref-ness).
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic
Daniel Keep wrote:
Denis Koroskin wrote:
Andrei Alexandrescu Wrote:
Denis Koroskin wrote:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
In D :
X x = new X;
This is a bit
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Daniel Keep wrote:
Denis Koroskin wrote:
Andrei Alexandrescu Wrote:
Denis Koroskin wrote:
On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton alex...@mac.com wrote:
I think it makes no sense to have nullable
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Sure. My suggested framework is one in which you'd use malloc for those
allocations. Then you can free. But plopping delete in the midst of a GC
system... that's just uncalled for.
Andrei
But then, you
BCS wrote:
Hello Tom,
The concept is pretty simple. The mixin creates a vtable which points
to
a set of generated functions of the form { adjust the 'this' ptr; jump
to the real function; }. Finally, the InterfaceName
asInterfaceName()
functions generated inside the struct return pointers to
Hello Tom,
BCS wrote:
Hello Tom,
The concept is pretty simple. The mixin creates a vtable which
points
to
a set of generated functions of the form { adjust the 'this' ptr;
jump
to the real function; }. Finally, the InterfaceName
asInterfaceName()
functions generated inside the struct return
Besides safety concerns, what does forbidding manual deletion enable GC
implementations to do?
Chad J wrote:
Besides safety concerns, what does forbidding manual deletion enable GC
implementations to do?
Foregoing delete affords the GC more implementation options.
Andrei
BCS wrote:
Hello Tom,
BCS wrote:
Hello Tom,
The concept is pretty simple. The mixin creates a vtable which
points
to
a set of generated functions of the form { adjust the 'this' ptr;
jump
to the real function; }. Finally, the InterfaceName
asInterfaceName()
functions generated inside the
Andrei Alexandrescu wrote:
Chad J wrote:
Besides safety concerns, what does forbidding manual deletion enable GC
implementations to do?
Foregoing delete affords the GC more implementation options.
Andrei
Such as?
I'm not trying to be antagonistic--manual deletion is a nifty feature to
Daniel Keep daniel.keep.li...@gmail.com wrote in message
news:gmpd71$8u...@digitalmars.com...
Alex Burton wrote:
I think it makes no sense to have nullable pointers in a high level
language like D.
Oh, and how do you intend to make linked lists? Or trees? Or any
non-trivial data
grauzone n...@example.net wrote in message
news:gmpe6g$ad...@digitalmars.com...
Alex Burton wrote:
For structs, use opCall() to initialize them. opCall is the best way to
initialize a struct, because struct literal are totally utterly useless.
If you use opCall to initialize classes as
Alex Burton alex...@mac.com wrote in message
news:gmqrec$2va...@digitalmars.com...
I would propose that library writers have to use the X * x pointer
notation to do their null pointer low level library implementation stuff,
and the rest of us use X x which becomes more difficult (not
Daniel Keep Wrote:
Burton Radons wrote:
I'm writing a couple of modules for dealing with database values (well
really it's just storage of aggregates) in a native fashion from within D,
using D 2.023. I have a tuple called FieldTypes which contains the D-side
types. I'm trying to
80 matches
Mail list logo
