On 23.11.2010 01:22, Jesse Phillips wrote:
wrzosk Wrote:
The problem i see is that in funcptr there is real entry point for
method used, not the index in virtual table, so the polymorphism can't
work with that.
As I have written - i don't know whether it is correct use for delegate.
Possibly t
I have just found some slides that show DataRush, a library that allows to use
in Java another programming paradigm (dataflow programming):
http://qconsf.com/sf2010/file?path=/qcon-sanfran-2010/slides/JimFalgout_DataflowProgrammingAScalableDataCentricApproachToParallelism.pdf
The dataflow code f
bearophile wrote:
Per Ångström:
I haven't yet found the official document describing the naming standard
for D,
http://www.digitalmars.com/d/2.0/dstyle.html
That's not really authoritative. That was written by Walter, without any
consultation with anybody else. Consider it to be a draft, r
wrzosk Wrote:
> The problem i see is that in funcptr there is real entry point for
> method used, not the index in virtual table, so the polymorphism can't
> work with that.
>
> As I have written - i don't know whether it is correct use for delegate.
> Possibly the ptr, funcptr should be both
Is there any way to save pointer to class method, and call it later?
I know about ptr, and funcptr properties of delegates. I tried to change
ptr and or funcptr manually after delegate was obtained. It worked in
some situations. I don't know if it is a correct use of delegate:
import std.writ
Michal Minich wrote:
It is very! interesting to have look at the history of D, thanks to forum
archives. CTFE was first introduced in DMD 1.006...
Yes, that's when interpret.c appeared, which implements it.
spir Wrote:
> === mod.d ==
> import std.stdio;
>
> struct S {
> int i;
> void speak() {writeln("i: ",this.i);}
> }
> === __trials__.d ===
> import mod;
>
> auto s = S();
> s.speak();
> s.i = 1;
> writeln(s.i);
>
> void main () {
> }
Others have answered how to initialize variables, bu
On Mon, 22 Nov 2010 15:11:29 -0500
bearophile wrote:
> spir:
>
> > More generally, I find myself unable to define structured objects at a
> > modules's top level. for instancz:
>
> I suggest to declare global variables and then initialize them in a "static
> this() {...}". But generally I sug
On 11/22/2010 08:18 PM, spir wrote:
Hello,
Let us say I have a parsing library. Now, I want to define parsers in
stand-alone modules -- for code structuration and reusability. Then, import
them from apps that need them.
Is there another way than defining the parser (== list of patterns) at the
spir:
> More generally, I find myself unable to define structured objects at a
> modules's top level. for instancz:
I suggest to declare global variables and then initialize them in a "static
this() {...}". But generally I suggest you to minimize the number of global
variables.
Bye,
bearophil
Hello,
Let us say I have a parsing library. Now, I want to define parsers in
stand-alone modules -- for code structuration and reusability. Then, import
them from apps that need them.
Is there another way than defining the parser (== list of patterns) at the
module's top-level. I have nothing a
Per Ångström:
> I haven't yet found the official document describing the naming standard
> for D,
http://www.digitalmars.com/d/2.0/dstyle.html
> but there are other conventions that are equally valid, in my view.
I agree. But the point of a standard is to use just one.
Bye,
bearophile
On Fri, 19 Nov 2010 16:48:50 -0500, Michal Minich
wrote:
On Fri, 19 Nov 2010 21:37:45 +, div0 wrote:
On 19/11/2010 21:22, Jonathan M Davis wrote: At runtime, the runtime
type info for classes forms a DAG.
As D only allows single inheritance it should be trivial to find the
most derive
On 2010-11-22 13:20, bearophile wrote:
Per Ångström:
Surely this must be more of a convention than a rule. Unless you are
writing a standard library I think you should be able to use whatever
capitalization standard you find appropriate.
If you live in a cave and there is zero probability tha
Am 21.11.2010, 19:47 Uhr, schrieb Peter Federighi :
I'd still like to know if there's a better way/native way to trap C
style signals
in D. Or is there a D way of programming a timer and finding terminal
window size
changes?
I don't think there are any D libraries to handle posix signals.
V Mon, 22 Nov 2010 16:38:11 +, Manfred_Nowak wrote:
> Michal Minich wrote:
>
>> I want get somehow to type *Derived2* at CT
>
> I miss the motivation: why would one wnat to have that at compile time?
>
> -manfred
http://www.google.com/search?q=curiously+recurring+template
Michal Minich wrote:
> I want get somehow to type *Derived2* at CT
I miss the motivation: why would one wnat to have that at compile time?
-manfred
On Sun, 21 Nov 2010 05:58:30 -0500, Nrgyzer wrote:
Hello guys,
I have an enumeration which contains symbols of different currencies
like the following:
enum CURRENCY : wchar {
DOLLAR = '$',
EURO = '�',
YEN = ...
}
When I try to append it to a string like
char[] myS
On Fri, 19 Nov 2010 16:05:40 -0500, Jonathan M Davis
wrote:
On Friday 19 November 2010 12:56:38 Steven Schveighoffer wrote:
On Fri, 19 Nov 2010 15:54:08 -0500, Michal Minich
wrote:
> On Fri, 19 Nov 2010 20:50:13 +, Michal Minich wrote:
>> How do I solve this, without parametrizing clas
Pelle Månsson wrote:
'auto' is not a placeholder for a type, but the default storage class.
IOW, 'int n;' == 'auto int n;'. This does however not compile,
complaining that it has no effect.
Specifying just the storage class signals the compiler to use type
inference. Try it:
const x = 4;
immu
On 11/22/2010 04:12 PM, Simen kjaeraas wrote:
spir wrote:
On Sun, 21 Nov 2010 20:21:14 -0500
bearophile wrote:
If in a D2 program I have an array of mutable items I may want to
iterate on them but not modify them, so I'd like the iteration
variable to be const. This is possible, but it seem
spir wrote:
On Sun, 21 Nov 2010 20:21:14 -0500
bearophile wrote:
If in a D2 program I have an array of mutable items I may want to
iterate on them but not modify them, so I'd like the iteration variable
to be const. This is possible, but it seems I lose type inference:
void main() {
On Sun, 21 Nov 2010 20:21:14 -0500
bearophile wrote:
> If in a D2 program I have an array of mutable items I may want to iterate on
> them but not modify them, so I'd like the iteration variable to be const.
> This is possible, but it seems I lose type inference:
>
>
> void main() {
> int
Per Ångström:
> Surely this must be more of a convention than a rule. Unless you are
> writing a standard library I think you should be able to use whatever
> capitalization standard you find appropriate.
If you live in a cave and there is zero probability that I will see and use the
D code yo
On 2010-11-21 23:39, bearophile wrote:
Gareth Charnock:
string Compile_not_ovloaded() {
return "expression";
}
Note that [...] in D method names start with a lower case.
Surely this must be more of a convention than a rule. Unless you are
writing a standard
25 matches
Mail list logo
