Hello,
I'm quite new to D, and it seems to be a great language for me.
But I've some questions:
Why is it good to treat functions as property, it make the code quite
unreadable. With a simple property keyword the things were much clear, like:
class Foo {
property prop {
int get {
re
Thanks, i've found it.
Gzp
Hello,
Iám new to D so i might be all wrong. Given the code:
class Foo {
int opApply( int delegate(ref real) dg ) {...} //A.
int opApply( int delegate(real) dg ) {...} // B,
}
...
Foo foo = new Foo;
foreach( a; foo ) {...} // 1.
foreach( ref a; foo ) {..
I've tried to implement a const, non-const accessor for a class similar to c++:
a& at(int) const;
a at(i);
With class it works as expected
class C1
{
int a;
const int foo() { return 2; }
ref int foo() { return a; }
}
Than I wanted to do it using interfaces:
inte
It has some bug for sure, or the interface should be reconsidered:
interface I1 { int foo(); }
interface I2 { const int foo(); }
class C1 : I2,I1{
int foo() { return 0; }
const int foo() { return 1; }
}
class C2 : I1,I2{
int foo() { return 0; }
const int foo() { return 1; }
}
C1 won't comp
language_fan írta:
Thu, 15 Oct 2009 02:04:09 -0400, Chad J thusly wrote:
I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently and
in incompatible ways (all of the Vec2D, Vec3D, etc ever). Also
aggravating is w
Walter Bright írta:
The purpose of T[new] was to solve the problems T[] had with passing T[]
to a function and then the function resizes the T[]. What happens with
the original?
I've tried to follow the T[], T[new], T+slice discussion, but i'm lost,
I don't think if it's a good idea, to extend
.
I like many features of D (and dislike some - but it's ok, cannot have a
language that fits all the desires for everybody ), but while it's in a
so mutable state, it`s hard to use it. I have to wait while most
features are made immutable (and not const, that can be altered through
some nasty const_cast proposals :) ).
Regards,
Gzp
Thanks for all. Well, it seems as all of my concerns are answered somewhere on
the net. So than i have only one more request left, please update the web pages
on the http://www.digitalmars.com/d/2.0/... to have references to the more
verbose net sources (and not just at the additional links)
Ex
[] can
int[new] is the array itself (i'm not sure)
int[new] a = new int[100];
int[] slice_a = a;
assert( slice_a.array.ptr == a.ptr );
Gzp.
l programming they might also help, since for slice
access the array structure cannot change so a read access is sufficient
for the array structure (sometimes it's better to calculate something
twice, and write it twice from different threads).
And for the array use, we know, the structure might also be changed,
thus it have to be guarded by critical sections as well.
Gzp
ar syntax ? If so
what about the e++ and ++e operators? How they are distinct ? Or is the
latter eliminated from the language ?
Though, I like the idea, just a quick look at a code and you can see all
the operators in a place.
Bye, Gzp
eliminated from the language ?
Though, I like the idea, just a quick look at a code and you can see
all the operators in a place.
Bye, Gzp
I think user code should only define ++e. Then the compiler can use that
to define e++.
Andrei
Thanks, that's great.
Gzp
, but
distinct the two object:
1. have array those contains the element + structure, that can be
resized: RandomAccessArray!(int)
2. have slices (ranges) of array, where the structure cannot be altered
only the elements: Rang!(int)
3. decide if int[] stands for a short version for either
RandomAccessArray!(int) or Range!(int), but DO NOT have a mixed meaning.
Gzp
ly needed to have a new, MODERN language for scientific
programmers as well. (Don't even dare to mention FORTRAN or matlab :) )
Gzp
nt)
Maybe it's treated like this and has the same view in the head of
everybody, but for me it was not stated like this before.
The compiler also should provide readably output of the generated code.
ex. generated documentation of the generated code (see the !// comment
in the sample)
Regards, Gzp
Denis Koroskin írta:
On Tue, 01 Dec 2009 17:02:40 +0300, Nick Sabalausky wrote:
"Gzp" wrote in message
news:hf2k9a$2l5...@digitalmars.com...
The compiler also should provide readably output of the generated code.
I'm not sure if this is what you mean, but I definitely
"Gzp" wrote in message
news:hf2k9a$2l5...@digitalmars.com...
So to designing template(generic) code, a simplified language should be
created that generates the actual source. So the border b/n the two
language can be made more explicit and fewer questions arose.
The problem
CTFE is used for optimization, but it is *also* used for metaprogramming:
char[] genDecl(char[][] names)
{
char[] ret;
foreach(char[] name; names)
ret ~= "int "~name~";";
return ret;
}
void main()
{
mixin( genDecl( ["foo"[], "a", "b"] ) );
a = 2;
b = 3;
fo
ations itself:) )
Thanks: Gzp
compiler/memory barriers and atomic had to be implemented
differently for each platform and the programmer could only hope
that compiler won't f*ck up everything during optimization.
I don't know if D compiler is aware of the fences and won't move
out/in instructions from guarded areas.
Thanks: gzp
I am fairly sure it isn't, but why is this needed if you use a
parallelism oriented approach to the architecture and design?
Sorry to repeat but whilst there are circumstances where this
stuff is needed (operating systems), most other applications
should be written without the need for locks, m
Actually I've just found an isue from 2015 (still in NEW state):
https://issues.dlang.org/show_bug.cgi?id=15007
I've updated and linked this forum.
23 matches
Mail list logo
