|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D - Array operation for computing the dot product?
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
Hello Don,
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Make it an intrinsic?
--
<IXOYE><
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
--
Michiel Helvensteijn
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
<m.helvensteijn.remove gmail.com> wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
Weirder:
x · y
I vote obscure unicode character \u2743: heavy chevron snowflake
x ❆ y
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
<m.helvensteijn.remove gmail.com> wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
x.dot(y)
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
x · y
x ❆ y
or why not: x ♣ y;
no wait that would delete y and assign x to it.
--
<IXOYE><
BCS wrote:
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
<m.helvensteijn.remove gmail.com> wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
x.dot(y)
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
x · y
x ❆ y
or why not: x ♣ y;
no wait that would delete y and assign x to it.
Before we solve the difficult problem of naming the thing could we first
go through the trivial part of optimizing it under its current name.
http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
Andrei
Andrei Alexandrescu:
Before we solve the difficult problem of naming the thing could we first
go through the trivial part of optimizing it under its current name.
In this case finding a good syntax before D2 is out of alpha stage is more
important than implementing that efficiently.
The user interface is often very important for the usage and success of a
machine. And the interface of a computer language is its syntax.
Bye,
bearophile
Ellery Newcomer wrote:
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
<m.helvensteijn.remove gmail.com> wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
Weirder:
x · y
I vote obscure unicode character \u2743: heavy chevron snowflake
x ❆ y
Considering TeX was invented (in part) to handle typesetting of
mathematical formulae, one might imagine it would be a good idea to use
its syntax...
x \mdot y
Yeah, maybe not...
Before we solve the difficult problem of naming the thing could we first
go through the trivial part of optimizing it under its current name.
http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
it's not like it couldn't be done in parallel :)
Michiel Helvensteijn wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
Fine stuff.
This reminds me of a discussion we had a year or more ago about offering
abstract operators purely for the purpose of overloading. We can use
things like (+), (*), (-), (&), and so on. It'd probably be fine to use
one for dot product. Probably a dream though. It looks like it's very
hard to get new tokens/syntax into the language at this point. I
suppose annotations and exponentiation managed it, but with no shortage
of blood, sweat, and tears.
Hello bearophile,
Don:
Indeed. The difficult question is, what would the syntax be?
x.dot(y)
How about: x.y;
It reads correctly.
OK, bad idea. :)
--
<IXOYE><
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
Don wrote:
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
As is std.numeric.dotProduct(x, y) without language _or_ library change :o).
Andrei
Unicode operators are good for Fortress, but not for D.
x.dot(y) is good because it's short and easy to read&understand.
Another silly possibility:
x ^^^ y
:-)
Bye,
bearophile
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn =
<m.helvensteijn.remove gmail.com> wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
Weirder:
x =C2=B7 y
-- =
Simen
Wed, 03 Feb 2010 20:55:46 +0100, Don wrote:
Trass3r wrote:
I wonder if an array operation could be reasonably included. It's a
quite common case and there are direct SSE instructions for it since
SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
a · b
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
This would be achieved by adding array aggregate properties, an idea
that has cropped up a few times, though I can't seem to find anything
other than
http://www.digitalmars.com/webnews/newsgroups.php?art_group=D&article_id=21671
at the moment.
And then add using these properties as something you can do with array
operations besides slice assignment.
It's much more general than inventing a new operator just for dot product.
But there are more important things to do than adding yet more features
to the language....
Stewart.
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
Some time ago I really
wanted to write a wikibook about D. I also wanted to write a new
compiler. It's just that D is a shitty language to work with because even
the stable version is a moving target and/or many features are
unspecified.
How is D1 a moving target?
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
or dark corner cases.
Some time ago I really wanted to write a wikibook about D. I also
wanted to write a new compiler. It's just that D is a shitty language
to work with because even the stable version is a moving target and/or
many features are unspecified.
How is D1 a moving target?
Nobody knows how D actually works. Due to the incomplete specification,
it's like a blackbox. All you can do is to give dmd some code using
under-specified features, and when dmd accepts it, people have to assume
the program is correct.
Also, I have regressions in almost any dmd release. (I always have to
change my code, or wait for later bug fixes. Sometimes the outcome is
that a specific thing just wasn't supposed to work.)
Even more so, D1 seems like a dead horse, and D2 just again is a really
fast moving target. Give us a stable language, Walter! And by stable, I
don't just mean an arbitrary frozen "snapshot" of the language. It has
to be stable, but alive. Other languages are also doing it without
breaking backward compatibility to all existing programs.
I'm already hysterically laughing from the thought of an incompatible D3
in some years.
grauzone wrote:
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
or dark corner cases.
Being in Bugzilla means they will not be forgotten, and will eventually
get addressed. All spec problems are answerable by anyone willing to
make the effort, and supply a documentation patch.
How is D1 a moving target?
Nobody knows how D actually works. Due to the incomplete specification,
it's like a blackbox. All you can do is to give dmd some code using
under-specified features, and when dmd accepts it, people have to assume
the program is correct.
There's more that can be done than that - file the issue in bugzilla. If
you want to go further, include a patch to the specification.
Also, I have regressions in almost any dmd release. (I always have to
change my code, or wait for later bug fixes. Sometimes the outcome is
that a specific thing just wasn't supposed to work.)
It's true that sometimes bug fixes will cause other bugs, this isn't
just a spec problem. It's a problem that the test suite isn't thorough
enough.
Even more so, D1 seems like a dead horse, and D2 just again is a really
fast moving target. Give us a stable language, Walter! And by stable, I
don't just mean an arbitrary frozen "snapshot" of the language. It has
to be stable, but alive. Other languages are also doing it without
breaking backward compatibility to all existing programs.
It's not possible to have a stable language that gets regular new
features. Even innocuous new features risk breaking things in unexpected
ways. Even just a new keyword.
Other languages do it by taking many years to fold in even very minor
changes.
retard wrote:
The funny thing about D is that if you start writing a book about it,
there's a high desire to change the core features and add more of
the community.
I have started writing a D book in June and have not desired to change
much about the language. I did find the half-reference behavior of
slices weird and voiced my opinion about it.
If you meant Andrei's book; he is not changing the language just because
he is writing a book about it. The design of the language and the book
happen together.
My book targets the Turkish speaking novice programmer, and I am sure is
tainted by my C++ experience. D is an excellent language to teach
programming with. There is very little cruft in the language when doing
the simple things. There is very little to make novice mistakes with.
It's just that D is a shitty language to work with because even
the stable version is a moving target and/or many features are
unspecified.
I did need to change my text only a few times, e.g. when constant-sized
arrays became value types.
Shitty is in the eye of the beholder. Someone else may call C++ shitty
just for the opposite reason: it is too stable. Years go by without any
addition to the language. Even more years go by for the compiler vendors
to catch up. That's not productive.
D is great because it is being designed openly by great programmers: the
person with the longest C++ compiler writing experience, the person who
has pushed C++ templates beyond their limits and introduced needs for
stronger templates, many others who contribute to the language at
various levels. Heck, even my naive voice has an effect on the language.
D2 obviously must stabilize before being useful; but it is great that it
moves fast before that happens.
Ali
On 2010-02-05 14:35:20 -0500, Ali ehreli <acehreli yahoo.com> said:
D2 obviously must stabilize before being useful; but it is great that
it moves fast before that happens.
D2 is already useful for small scale projects. I wrote the system to
manage license codes for my Mac shareware (Magic Launch) with D2. It's
in production since January running as a CGI on my website, and is
working great. My only wish in relation to that is that SafeD be more
usable.
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Michel Fortin wrote:
My only wish in relation to that is that SafeD be more
usable.
I know safe D isn't fully implemented, but can you say which missing
part of it you need?
On 2010-02-05 15:22:44 -0500, Walter Bright <newshound1 digitalmars.com> said:
Michel Fortin wrote:
My only wish in relation to that is that SafeD be more usable.
I know safe D isn't fully implemented, but can you say which missing
part of it you need?
First, I'd like to say that language itself isn't too bad. I think
SafeD as currently implemented has the right design, except when it
comes to passing delegates and functions as arguments to templates or
functions. But I abandoned using this so it's not a pressing need for
me currently. Still, I think that's an important issue to solve
otherwise it'll be difficult to make std.algorithm safe and at the same
time usable from unsafe code (as it relies heavily on predicates).
So basically in the implementation there's just one big annoyance for
me right now (but the workaround is easy):
http://d.puremagic.com/issues/show_bug.cgi?id=3636
Most of the problems come from Phobos not being safe. I'm using a
couple of things scattered in std.range, std.string, std.file,
std.stdio, std.path, and to!X in std.conv.
So what's the plan? Should everything theoretically safe in Phobos be
trusted to avoid complains about unnecessary checks in programs that
don't bother about safety? Or should we make things safe and promote
them to trusted (for performance) only after a careful review? I'm a
proponent of not making anything trusted in Phobos until it has been
reviewed and approved by someone else than the author.
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Michel Fortin wrote:
So what's the plan? Should everything theoretically safe in Phobos be
trusted to avoid complains about unnecessary checks in programs that
don't bother about safety? Or should we make things safe and promote
them to trusted (for performance) only after a careful review? I'm a
proponent of not making anything trusted in Phobos until it has been
reviewed and approved by someone else than the author.
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
Walter Bright Wrote:
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
I am sorry if this is totally stupid, but shouldn't it be possible for the
compiler to do this? addition to -profile maybe
It might also be interesting if the compiler were to generate the most
restrictive protection attributes for everything, which would still compile or
course ;)
== Quote from strtr (strtr spam.com)'s article
Walter Bright Wrote:
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
It might also be interesting if the compiler were to generate the most
course ;)
Actually, more generally a generate-attributes flag for the compiler might be a
pretty useful thing. I have no idea how feasible this would be at an
implementation level, but it would definitely work at a theoretical level
(except
for trusted, which needs to be checked manually). It would spit out the same
source files, but with any attribute that would compile added. For example, all
functions that would compile as pure would be marked pure. All functions that
would compile as nothrow would be marked nothrow. All unannotated member
functions that would compile as const would be marked inout (once inout is
implemented for member functions). All function parameters that could be const
without breaking anything would be marked as such. This assumes that noone
overloaded const and non-const versions of some member function to do
semantically
different things, but if they did they deserve what they get.
On 2010-02-05 18:59:00 -0500, Walter Bright <newshound1 digitalmars.com> said:
Michel Fortin wrote:
So what's the plan? Should everything theoretically safe in Phobos be
trusted to avoid complains about unnecessary checks in programs that
don't bother about safety? Or should we make things safe and promote
them to trusted (for performance) only after a careful review? I'm a
proponent of not making anything trusted in Phobos until it has been
reviewed and approved by someone else than the author.
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
But is it okay to label most of Phobos safe knowing that it'll reduce
performance? I was under the impression that we would want to make most
of Phobos trusted for performance.
Also, I'm now realizing that safe might be difficult to add to many
templates. For instance, this template function from std.range doesn't
know if the functions it calls on the range (length, empty, popFront)
are safe or not. Labeling it safe will make it not work with unsafe
ranges while not labeling it safe will make it uncallable from safe
functions (and making it trusted will make it blindly trust the range),
neither of which is very compelling.
size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
if (isInputRange!(Range))
{
static if (hasLength!(Range))
{
return range.length;
}
else
{
size_t result;
for (; result < upTo && !range.empty; range.popFront) ++result;
return result;
}
}
I'm starting to think that templates should inherit the safe attribute
from the context they're instantiated in, not from where they're
defined. This would solve the above problem nicely as well as the
problem of string predicates in std.algorithm:
sort!"a < b"(array);
// whether "a < b" needs to be safe depends on the context
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
package).
I see. I only noticed now that dmd actually does enforce this rule in
some cases. Unfortunately the rule is checked only statically when it can
be checked. If you access the object via base class or interface type
reference, a runtime check is not made unlike in c++.
There must be some misunderstanding here. There are no runtime access
checks in C++, it is all done statically at compile time.
retard wrote:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
of package).
some cases. Unfortunately the rule is checked only statically when it
can be checked. If you access the object via base class or interface
type reference, a runtime check is not made unlike in c++.
checks in C++, it is all done statically at compile time.
Thanks. It seems I have been testing this with a buggy c++ compiler or
can't remember what was the problem previously. I now tried with gcc
4.4.3 and this is how D and C++ differ:
---
class Foo {
public:
void bar() {}
};
class Bar : private Foo {
};
int main() {
Foo *a = new Bar();
a->bar();
}
test.cpp: In function ‘int main()’:
test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’
---
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
That's a bug in dmd. It should behave like the C++ does.
// Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Walter Bright wrote:
retard wrote:
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
That's a bug in dmd. It should behave like the C++ does.
It would be different from C++ if everything were in the same module, right?
If I understand it correctly, private is not honored for the code in the
same module. Is that for all uses of private?
Ali
Ali Çehreli wrote:
It would be different from C++ if everything were in the same module,
right?
Right.
If I understand it correctly, private is not honored for the code in the
same module. Is that for all uses of private?
Yes.
On 2/6/10 01:25, retard wrote:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
of package).
I see. I only noticed now that dmd actually does enforce this rule in
some cases. Unfortunately the rule is checked only statically when it
can be checked. If you access the object via base class or interface
type reference, a runtime check is not made unlike in c++.
There must be some misunderstanding here. There are no runtime access
checks in C++, it is all done statically at compile time.
Thanks. It seems I have been testing this with a buggy c++ compiler or
can't remember what was the problem previously. I now tried with gcc
4.4.3 and this is how D and C++ differ:
---
class Foo {
public:
void bar() {}
};
class Bar : private Foo {
};
int main() {
Foo *a = new Bar();
a->bar();
}
test.cpp: In function ‘int main()’:
test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’
---
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
// Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Is there any use to make the base class non public in D? I mean you will
also make the Object part inaccessible. Another thing to remove in D2?
Jacob Carlborg wrote:
Is there any use to make the base class non public in D? I mean you will
also make the Object part inaccessible. Another thing to remove in D2?
It's possible it's a useless feature. Apparently, nobody has found a use
for it yet in D.
Walter Bright Wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
I didn't know I could protect a superclass like that, where can I read about
this?
Fri, 05 Feb 2010 02:42:53 +0000, Stewart Gordon wrote:
Trass3r wrote:
I wonder if an array operation could be reasonably included. It's a
quite common case and there are direct SSE instructions for it since
SSE 4.1.
This would be achieved by adding array aggregate properties, an idea
that has cropped up a few times, though I can't seem to find anything
other than
http://www.digitalmars.com/webnews/newsgroups.php?
at the moment.
And then add using these properties as something you can do with array
operations besides slice assignment.
It's much more general than inventing a new operator just for dot
product.
But there are more important things to do than adding yet more features
to the language....
The funny thing about D is that if you start writing a book about it,
there's a high desire to change the core features and add more of them in
the community. You can't even list all the D1 features at the moment,
because we don't know what they are. Example:
class bar {}
class foo : private bar {}
Another one:
pragma(msg, mystruct.tupleof.stringof);
I can easily come up with 100 other such features. Some time ago I really
wanted to write a wikibook about D. I also wanted to write a new
compiler. It's just that D is a shitty language to work with because even
the stable version is a moving target and/or many features are
unspecified.
Fri, 05 Feb 2010 03:20:35 -0800, Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
OK
Some time ago I really
wanted to write a wikibook about D. I also wanted to write a new
compiler. It's just that D is a shitty language to work with because
even the stable version is a moving target and/or many features are
unspecified.
How is D1 a moving target?
Bugfixes in specification make those programs break that had to rely on
broken semantics.
What about the simper:
x.dot(y)
change.
As is std.numeric.dotProduct(x, y) without language _or_ library change
:o).
That's why I wondered if it could be reasonably included (without
introducing a ton of new stuff to the language).
so it should be usable like x.dotProduct(y), right?
sounds fine for me.
Unfortunately I can't even try to implement it cause my Core 2 is slightly
too old ;)
Was introduced with Penryn architecture.
Fri, 05 Feb 2010 11:35:20 -0800, Ali Çehreli wrote:
I did need to change my text only a few times, e.g. when constant-sized
arrays became value types.
You can easily check from the changelogs what happened between dmd 1.00
and 1.056. Quite a lot changed. You could even write a 200 page book
about the changes.
D is great because it is being designed openly by great programmers: the
person with the longest C++ compiler writing experience, the person who
has pushed C++ templates beyond their limits and introduced needs for
stronger templates, many others who contribute to the language at
various levels. Heck, even my naive voice has an effect on the language.
Heh, whatever. But the problem is, when I write a book about C, C++,
Java, or some other language, I do know how it behaves. I can write
informal programming books for novices or exact academic text with full
description of the grammar rules, type system, and e.g. denotational or
operational semantics. A D book is like a c++0x, Java7 or Haskell 2010
book - you constantly need to update it to reflect the changes in the
next spec update.
Now with D this isn't the case. I have to participate in the spec writing
process no matter what I do. I do know how lazily Walter responds to
queries and I do know that even though many have complained about
semantics of the protection attributes in class inheritance several times
during the past 10 years, nothing has changed. I don't want to write
books that say
1. Classes
----------
1.1. Inheritance
----------------
Classes in D can inherit from a base class. [snip] The syntax below shows
how to do this:
class {classname} : {protection-attr} {baseclassname} {
}
{classname} == name of the new class, represents the type name
{baseclassname} == name of the base class
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does and neither does anyone
else but isn't this a cool feature that somehow proves that D is very
practical language and also implementing your own compiler is so damn easy
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
I see. I only noticed now that dmd actually does enforce this rule in
some cases. Unfortunately the rule is checked only statically when it can
be checked. If you access the object via base class or interface type
reference, a runtime check is not made unlike in c++.
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
of package).
I see. I only noticed now that dmd actually does enforce this rule in
some cases. Unfortunately the rule is checked only statically when it
can be checked. If you access the object via base class or interface
type reference, a runtime check is not made unlike in c++.
There must be some misunderstanding here. There are no runtime access
checks in C++, it is all done statically at compile time.
Thanks. It seems I have been testing this with a buggy c++ compiler or
can't remember what was the problem previously. I now tried with gcc
4.4.3 and this is how D and C++ differ:
---
class Foo {
public:
void bar() {}
};
class Bar : private Foo {
};
int main() {
Foo *a = new Bar();
a->bar();
}
test.cpp: In function ‘int main()’:
test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’
---
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
// Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
On Sat, 06 Feb 2010 01:43:27 +0100, strtr <strtr spam.com> wrote:
Walter Bright Wrote:
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
I am sorry if this is totally stupid, but shouldn't it be possible for
the compiler to do this? addition to -profile maybe
It might also be interesting if the compiler were to generate the most
restrictive protection attributes for everything, which would still
compile or course ;)
Theoretically possible, yes. However, that would require whole-program
analysis, which is not always possible.
--
Simen
|
|
C & C++
DMDScript
BCS <none anon.com> 