Re: using a binary tree container
On 02/13/2011 01:18 AM, Ali Çehreli wrote: On 02/11/2011 04:55 PM, spir wrote: Also, trees are not always O(logN): tries () are O(1) for access, relative to number of elements, in fact their search is not related to that factor, just like hash table instead to the length of keys (O(log(length)). Yep. I should know: I had written a patricia trie in the context of a networking ASIC. :) In D, not only there is no way (for me) to even approach builtin AA perf with tries (even with some search for optimisation), but those deadly flash-fast AAs are worth it as early as with a few items! Thank you. It's very good to know that D's AAs are very fast. I had no idea. :) Beware: I'm not saying this as an absolute truth out of extensive measures. Just comparing plain arrays of (key,value) pairs versus tries versus hashed AAs in the same language, done in 2 languages only (D and freepascal). Denis -- _ vita es estrany spir.wikidot.com
Re: Number of references to a Class Object
However, it's not generally an issue, because you shouldn't normally be keeping references around for stuff that isn't used anymore. The garbage collector is smart enough to deal with circular references and the like, so the biggest cases where you'd normally need weak references aren't actually a problem. You're trying to do something fairly abnormal here. Thanks Jonathon, with some effort I hope to wriggle out of the situation. Regards - Cherry
Error: this for ~this needs to be type foo not type foo[1u][1u]
Greetings
I am getting this error when I am instantiating a struct array with a
single element inside another class and only if there is the
destructor for the struct is explicitly defined. Is it a known error?
Here is a minimized snippet that gives error:
$ rdmd --main -unittest test.d
Error: this for ~this needs to be type foo not type foo[1u][1u]
Error: this for ~this needs to be type foo not type foo[1u]
// test.d
struct foo {
int foofoo;
~this() { // no error if explicit destructor not
// defined
}
}
class bar {
foo fred;
foo[2][2] foofoo;
foo[1] frop; // this gives error
foo[1][1] fropfrop; // this too
}
unittest {
foo frop;
foo[1][1] fropfrop; // this works
bar burp;
}
Re: using a binary tree container
Am 12.02.2011 00:02, schrieb spir: On 02/11/2011 10:33 PM, Mafi wrote: I allways try to import 'algorythm' because of the german word 'Algorythmus'. When this happend for the first time, I spent about five minutes to find out what's wrong. It is spelled Algorithmus in German, no ypsilon ;-) http://de.wiktionary.org/wiki/Algorithmus The word is not from greek, but from arabic/persian etymology (like many words starting in al-). From wiktionary: http://en.wiktionary.org/wiki/algorithm: From French algorithme; from the Old French algorisme (the Arabic numeral system), a modification likely due to a mistaken connection with Greek ἀριθμός (number); from Medieval Latin algorismus, a transliteration of the name of the Persian mathematician al-Khwārizmī (Arabic: الخوارزمي, native of Khwarezm.) denis Holly shit! I feel ashamed now. :( I'm going to correct all my personal notes about algorithms. Mafi
Re: BigInt problem
tsukikage: For curiosity, would you explain/guess a possible reason for that? I leave the answer to Don, I don't know the internals of D BigInts. Multi-precision integers are basic bricks used to build many other programs. How can you be sure they don't contain bugs that break your heavy numeric code? This is a big problem. Bye, bearophile
Double-dispatch
I remember in C++, I had to do double-dispatch using the visitor pattern. This
is cumbersome, just because each subclass has to have the exact same
singly-dispatched code that looks like:
void dispatch(Base other)
{
other.dispatch(*this);
}
Is there a nicer way to do this in D, or am I stuck with the same thing?
Re: Double-dispatch
Sean Eskapp eatingstap...@gmail.com wrote:
I remember in C++, I had to do double-dispatch using the visitor
pattern. This
is cumbersome, just because each subclass has to have the exact same
singly-dispatched code that looks like:
void dispatch(Base other)
{
other.dispatch(*this);
}
Is there a nicer way to do this in D, or am I stuck with the same thing?
Andrei Alexandrescu (yes, the same one) wrote a generic implementation of
multimethods[1] for his book Modern C++ Design[2]. You might want to take
a look at that. If you decide to re-implement it in D, it might also be
worth incorporating in Phobos.
[1]:
http://loki-lib.cvs.sourceforge.net/loki-lib/loki/include/loki/MultiMethods.h?view=markup
[2]: http://www.amazon.com/a/dp/0201704315/
--
Simen
Re: Double-dispatch
Sean Eskapp wrote:
I remember in C++, I had to do double-dispatch using the visitor pattern.
This is cumbersome, just because each subclass has to have the exact same
singly-dispatched code that looks like:
void dispatch(Base other)
{
other.dispatch(*this);
}
Is there a nicer way to do this in D, or am I stuck with the same thing?
There isn't really, but you can take out some of the boilerplate with a
mixin, which goes a long way:
// The template parameter Visitor is not actually needed, depending on
// what you want to do
mixin template Accept(Visitor)
{
void accept(Visitor v)
{
v.visit(this);
}
}
class Stuff
{
mixin Accept!IStuffVisitor;
}
With some ctfe it's also not too hard to take out the boilerplate of
creating the visitor interface with a bit of code generation, though I'm not
sure if it's worth it.
produce standard notation for strings
Hello, I need to write one or more tool functions that produce standard notation for strings. Something like python's repr(s). For instance: `abc def ghi jkl` -- abc\ndef\t\ghi\ jkl which, fed back into D code, reproduces the original string. I have actually several formats in mind, depending on which class(es) of chars are conserved literally or not (eg only \x20..\x7f), including a hex-only one. First, is there something like that in stock (phobos or not) and I haven't searched well? Else, I wonder about the best way to do it? Use replace(), manually iterate, use regexes (with replace func)? What else. How would you do it? Thank you, Denis -- _ vita es estrany spir.wikidot.com
Re: Double-dispatch
Sean Eskapp: Is there a nicer way to do this in D, or am I stuck with the same thing? Andrei has recently said no one needs double dispatch (in D) :-) So Andrei will be interested in your use case. Bye, bearophile
Re: Double-dispatch
== Quote from bearophile (bearophileh...@lycos.com)'s article Sean Eskapp: Is there a nicer way to do this in D, or am I stuck with the same thing? Andrei has recently said no one needs double dispatch (in D) :-) So Andrei will be interested in your use case. Bye, bearophile The age-old collision handling problem is how I'm using it.
Opt-out polymorphism?
Is there a way to specify that a function is nonvirtual, but can still be
overriden in base classes? e.g.
class A
{
void foo()
{
writeln(A);
}
}
class B : A
{
void foo()
{
writeln(B);
}
}
void main()
{
(new A).foo();
(new B).foo();
}
Should output:
A
B
Is there a way to do this?
Read non-UTF8 file
Hey guys,
I've the following source:
module filereader;
import std.file;
import std.stdio : writeln;
void main(string[] args) {
File f = new File(myFile.ext, FileMode.In);
while(!f.eof()) {
writeln(convertToUTF8(f.readLine()));
}
f.close();
}
string convertToUTF8(char[] text) {
string result;
for (uint i=0; itext.length; i++) {
wchar ch = text[i];
if (ch 0x80) {
result ~= ch;
} else {
result ~= 0xC0 | (ch 6);
result ~= 0x80 | (ch 0x3F);
}
}
return result;
}
It compiles and works as long as the returned char-array/string of f.readLine()
doesn't contain non-UTF8 character(s). If it contains such
chars, writeln() doesn't write anything to the console. Is there any chance to
read such files?
Thanks a lot!
traits: how to split parametrized type into basic type and parameters
Hi,
I'm implementing a generic Vector!(uint d, T) struct (wrapping a T[d] array).
For readability:
alias Vector!(4u,float) float4;
alias Vector!(4u,int) int4;
I'd like to be able to cast a float4 variable explicitly to an int4
(component-wise casting):
auto f4 = float4(1,2,3,4);
auto i4 = cast(int4) f4;
So when implementing opCast!NewType() in Vector!(d,T), I need a signature
constraint: NewType must be a Vector!(d2,T2), with d2 == d isNumeric!T2.
The problem is that I don't know how to split NewType into the basic type
(Vector) and its parameters ({uint d2, T2}) as I didn't find anything related
in the std.traits documentation. I currently use a custom casting method, but
am not happy with it (I prefer the clean casting syntax preceding the
expression):
Vector!(d,T2) castTo(T2)() if (isNumeric!T2) { ... }
// e.g., auto i4 = f4.castTo!int();
Thanks in advance for any hints. Already falling in love with D after 2 days
of experimenting :)
Re: traits: how to split parametrized type into basic type and parameters
I realize a parametrized constructor would be a better option:
this(T2)(const(Vector!(d,T2)) rhs) if (isNumeric!T2) { ... }
// e.g., auto i4 = int4(f4);
but I'd still prefer the casting syntax if possible.
Re: Opt-out polymorphism?
On Sunday 13 February 2011 13:34:04 Sean Eskapp wrote:
Is there a way to specify that a function is nonvirtual, but can still be
overriden in base classes? e.g.
class A
{
void foo()
{
writeln(A);
}
}
class B : A
{
void foo()
{
writeln(B);
}
}
void main()
{
(new A).foo();
(new B).foo();
}
Should output:
A
B
Is there a way to do this?
No. It's potentially error-prone to do that, and allowing the programmer to
specificy that sort of thing complicates things. C# allows you to choose
whether
a function is derived or not in a fairly clear manner, and C++ allows you to do
it in a somwhat poor manner, but in D, the compiler makes all of the decisions
about whether a function is virtual or not. That definitely simplifies things,
and
since in virtually all cases, you want virtual functions, it's not generally an
issue.
The only ways that you're likely to be able to make a function non-virtual in a
class are by making it private (which may or may not continue to make functions
non-virtual, since that contradicts TDPL) and if you make a function final. But
D
takes the tact of either it's overridable and virtual, or it's non-overridable
and non-virtual. So, you can't do what you're trying to do.
And honestly, in most cases, I think that what you're trying to do is just
plain
begging for bugs. It is kind of cool that C# found a relatively clean way to
deal with it, but I honestly don't know what it's useful for. I'd be worried
about a program which overrode non-virtual functions. It's highly likely to
cause bugs.
Jonathan M Davis
Re: Opt-out polymorphism?
Jonathan M Davis: And honestly, in most cases, I think that what you're trying to do is just plain begging for bugs. It is kind of cool that C# found a relatively clean way to deal with it, but I honestly don't know what it's useful for. I'd be worried about a program which overrode non-virtual functions. It's highly likely to cause bugs. C# designers are _not_ stupid or ignorant people :-) Bye, bearophile
Re: Opt-out polymorphism?
Generalizing the original question to *all* member functions, it can be
desirable to to have non-polymorphic inheritance, at least not *runtime*
polymorphic. I get the impression that it wouldn't be used much by most
people who post on these newsgroups, but there are application areas it
can be very useful.
For example, in tightly embedded applications it can be important to
minimize code-bloat in the use of templates in C++, so presumably also
applicable to parametized classes/structs in D. In C++ the idiom I'm
refering to has the template inherit the
template-parameter-type-independent (common) code from a non-template
base. An example plucked out of the air could be a linked list, the
link logic with no payload could be encapsulated in a non-template base
and the payload logic added in a template class that derives from it. I
expect that it would also be useful in D if embedded application
programming were an area that D were serious about catering for.
The criterion that determines whether it needs to be runtime polymorphic
or not is whether the resulting object is intended to be used through
its base class (polymorphic) interface or its derived class
(non-polymorphic) interface.
Aside: this distinction is the reason for Herb Sutter's C++ guideline
Always make base class destructors virtual and public or nonvirtual and
protected from his book More Exceptional C++.
Steve
On 14/02/11 11:59, Jonathan M Davis wrote:
On Sunday 13 February 2011 13:34:04 Sean Eskapp wrote:
Is there a way to specify that a function is nonvirtual, but can still be
overriden in base classes? e.g.
class A
{
void foo()
{
writeln(A);
}
}
class B : A
{
void foo()
{
writeln(B);
}
}
void main()
{
(new A).foo();
(new B).foo();
}
Should output:
A
B
Is there a way to do this?
No. It's potentially error-prone to do that, and allowing the programmer to
specificy that sort of thing complicates things. C# allows you to choose whether
a function is derived or not in a fairly clear manner, and C++ allows you to do
it in a somwhat poor manner, but in D, the compiler makes all of the decisions
about whether a function is virtual or not. That definitely simplifies things,
and
since in virtually all cases, you want virtual functions, it's not generally an
issue.
The only ways that you're likely to be able to make a function non-virtual in a
class are by making it private (which may or may not continue to make functions
non-virtual, since that contradicts TDPL) and if you make a function final. But
D
takes the tact of either it's overridable and virtual, or it's non-overridable
and non-virtual. So, you can't do what you're trying to do.
And honestly, in most cases, I think that what you're trying to do is just plain
begging for bugs. It is kind of cool that C# found a relatively clean way to
deal with it, but I honestly don't know what it's useful for. I'd be worried
about a program which overrode non-virtual functions. It's highly likely to
cause bugs.
Jonathan M Davis
