On Wednesday, 22 October 2014 at 02:09:53 UTC, Jonathan M Davis
wrote:
The usual suggestion that I've heard given (without any
particular language in mind) is to start by tracking down and
fixing a bug in it
This is how I usually do it too, though you don't even need to
find a bug in it.
neal:
data.sort!q{ to!int(a[4]) to!int(b[4]) };
This code fixes my problem! Thanks for the quick responses
guys. you rock!
That converts string-int many more than once for each string. So
if memory is not a problem, consider using a
decorate-sort-undecorate pattern:
On Wednesday, 22 October 2014 at 02:42:38 UTC, safety0ff wrote:
On Wednesday, 22 October 2014 at 01:21:19 UTC, Freddy wrote:
Is there any advice/tips for reading medium/big D codebases?
Somewhat D specific: I would consider an IDE/editor like
Eclipse with DDT that can give an outline of the
The idea is that the object you work with is responsible for
casting itself to an interface you need.
It's how COM casts objects
http://msdn.microsoft.com/en-us/library/ms687230.aspx
On Tuesday, 21 October 2014 at 21:58:09 UTC, ketmar via
Digitalmars-d-learn wrote:
start from using templates as generics, then add some sugar,
some type
consitions, some CTFE and so on. with C# we will stop right
after
generics, 'cause there is no other things there.
That's quite inadequate
On Thursday, 16 October 2014 at 22:26:51 UTC, RBfromME wrote:
I'm a newbie to programming and have been looking into the D
lang as a general purposing language to learn, yet the D
overview indicates that java would be a better language to
learn for your first programming language. Why? Looks
On Tuesday, 21 October 2014 at 12:19:43 UTC, ketmar via
Digitalmars-d-learn wrote:
templates arent about FP only. yet i agree that Scheme is a
very good starting point, SICP rocks.
It is available for free online:
http://mitpress.mit.edu/sicp/
Scheme is good for teaching because it is a
On Wed, 22 Oct 2014 07:58:49 +
Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
That's quite inadequate criticism. If you don't know, what
features generics have, you can't criticize them.
i'm don't saying that generics are bad, i'm saying that D has alot
more
I think there is a bigger issue with the mentioned example.
The command cannot work:
dmd test mydll.lib -g
test.d has an import statement to mydll. mydll has to be included
in the command. But as mydll not only contains the exported dll
functions but also DllMain, it cannot be compiled
C++ versions:
{ //displays ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
std::cout std::endl;
{ //displays ~C~B~A
std::unique_ptrA foo = std::make_uniqueA();
std::unique_ptrB bar =
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version with structs:
{ //display ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
as expected.
On Wed, 22 Oct 2014 16:49:20 +0100, eles e...@eles.com wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version with structs:
{ //display ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
as expected.
On Wednesday, 22 October 2014 at 16:55:41 UTC, Regan Heath wrote:
The garbage collector is not guaranteed to run the destructor
for all unreferenced objects. Furthermore, the order in which
the garbage collector calls destructors for unreference objects
is not specified. This means that when
On Wednesday, 22 October 2014 at 17:13:35 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 22 October 2014 at 16:55:41 UTC, Regan Heath
So why wasn't the eles' destructor order in reverse if Scoped
is a struct and calls explicit destroy(B) then destroy(A)?
Maybe it's the writeln() inside the
On Wednesday, 22 October 2014 at 07:38:01 UTC, bearophile wrote:
neal:
data.sort!q{ to!int(a[4]) to!int(b[4]) };
This code fixes my problem! Thanks for the quick responses
guys. you rock!
That converts string-int many more than once for each string.
So if memory is not a problem,
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
{ //displays ~A~B~C
A foo = scoped!(A)();
B bar = scoped!(B)();
C caz = new C();
destroy(caz);
}
Why the objects are not destroyed in the inverse order of their
On 10/22/2014 08:45 AM, eles wrote: C++ versions:
{ //displays ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
std::cout std::endl;
{ //displays ~C~B~A
std::unique_ptrA foo = std::make_uniqueA();
On Wed, 22 Oct 2014 18:03:44 +
anonymous via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
{ //displays ~A~B~C
A foo = scoped!(A)();
B bar = scoped!(B)();
C caz = new
Neal:
Interesting! Thank you. Memory isn't a problem
Unfortunately currently the sort-decorate-undercorate in Phobos
is not very fast.
but I would still
like to learn how to write more efficient programs. If i posted
my code would you be able to give me some advice?
There is far more
On Wednesday, 22 October 2014 at 18:14:54 UTC, ketmar via
Digitalmars-d-learn wrote:
yes, this is the case. i believe that this should be explicitly
documented in `scoped` ddocs. documentation examples using
'auto', but there is no mention that this is what *must* be
used.
This is too
On Wed, 22 Oct 2014 18:44:26 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 22 October 2014 at 18:14:54 UTC, ketmar via
Digitalmars-d-learn wrote:
yes, this is the case. i believe that this should be explicitly
documented in `scoped` ddocs.
On Tuesday, 21 October 2014 at 08:04:13 UTC, bearophile wrote:
If your text is ASCII, then there is std.ascii.whitespace that
can be given as argument to std.string.tr.
Bye,
bearophile
http://dlang.org/phobos/std_ascii.html#.whitespace
is of string but
std.string.tr needs [string] as
Hello people. I'm once more looking at D since I participated here a
bit last year. Since I'm still not 100% sure about committing myself
to using D i.o. C++ for my work, I'd really like to resurrect this
thread to clear my lingering doubts (the full thread is at
Hello. See http://dlang.org/attribute. 3 attributes starting at
http://dlang.org/attribute#disable have a @ in front. Apparently safe,
trusted and system also do, though these are documented elsewhere:
http://dlang.org/function.html#function-safety.
Why are some language-defined attributes
On Wednesday, 22 October 2014 at 19:00:36 UTC, Nordlöw wrote:
On Tuesday, 21 October 2014 at 08:04:13 UTC, bearophile wrote:
If your text is ASCII, then there is std.ascii.whitespace that
can be given as argument to std.string.tr.
Bye,
bearophile
On Wednesday, 22 October 2014 at 19:13:58 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
Hello. See http://dlang.org/attribute. 3 attributes starting at
http://dlang.org/attribute#disable have a @ in front.
Apparently safe,
trusted and system also do, though these are documented
On Wednesday, 22 October 2014 at 19:13:58 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
Hello people. I'm once more looking at D since I participated
here a
bit last year. Since I'm still not 100% sure about committing
myself
to using D i.o. C++ for my work, I'd really like to resurrect
Hello, I have an idea about a small code tool related to the
application resources.
It would rely on the assumption that some global variabled,
sharing the same type and attributes, declared in group, are
contiguous.
In short I need to know if the following assertions are always
true and
On Wednesday, 22 October 2014 at 20:29:58 UTC, Cjkp wrote:
Hello, I have an idea about a small code tool related to the
application resources.
It would rely on the assumption that some global variabled,
sharing the same type and attributes, declared in group, are
contiguous.
In short I need
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
`foo` should be a `Scoped!A`. When it's typed as `A`, the
`Scoped!A` that is returned by `scoped`, is destructed
immediately (and the reference leaks, I guess).
Just
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
`foo` should be a `Scoped!A`. When it's typed as `A`, the
`Scoped!A` that is returned by `scoped`, is destructed
immediately (and the reference leaks, I
On 10/22/2014 04:05 PM, eles wrote:
And the compiler swallows this without even barking?
The compiler must obey an alias this inside Scoped.
I've thinking for a way do disallow this but haven't been able to spend
much time on it today.
Why Scoped!A is convertible to A, then?
So that
I thought D was beyond carrying historical baggage. DMD 2.x is not
necessarily language-compatible with DMD 2.(x+1) since the language is
still evolving. You can deprecate one syntax and enforce the other in
a later version.
I submit that the syntax for attributes should be streamlined. Shall I
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
I thought D was beyond carrying historical baggage. DMD 2.x is
not
necessarily language-compatible with DMD 2.(x+1) since the
language is
still evolving. You can deprecate one syntax and enforce the
Hello. Please see the following code:
import std.stdio ;
struct Pair {
int x, y ;
this (int x, int y) { x = x ; y = y ; }
}
void main() {
auto P = Pair(1, 2) ;
writeln(P.x, ' ', P.y) ;
}
This outputs 0 0, whereas the equivalent C++ code outputs 1 2 correctly:
#
IIUC the whole deal with not allowing ref parameters to point to
rvalues is the fear that they may be returned outside the function,
but it seems this is already possible:
module reftest ;
import std.stdio ;
struct Pair {
int x, y ;
this (int x_, int y_) { x = x_ ; y = y_ ;
Hi Jonathan and thanks again for your kind replies.
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
That will result in a move operation. No copying will take place.
And it technically, it may not actually move anything it all and
just use the
On Thu, Oct 23, 2014 at 10:33:53AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
Hello. Please see the following code:
import std.stdio ;
struct Pair {
int x, y ;
this (int x, int y) { x = x ; y = y ; }
Please don't write code like this. How is the compiler supposed
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
So, yes, we do have historical baggage, albeit nowhere near as
much as C++ does.
OK understood, but I may just go and file that bug so that if there is
a future D 3 series, then stuff like this can be
On Thu, Oct 23, 2014 at 10:39:34AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
IIUC the whole deal with not allowing ref parameters to point to
rvalues is the fear that they may be returned outside the function,
but it seems this is already possible:
module reftest ;
import
On Thursday, 23 October 2014 at 02:22:41 UTC, Jonathan M Davis
wrote:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
LOL. I understand the sentiment, but it's a waste of time.
Jonathan,
I agree It's impossible to debate such thing with Walter
Hello. I perfectly realize that it's not advisable to take advantage
of shadowing. In fact, I asked the question because I thought D
specifically *didn't* allow shadowing, but here it is, being silently
permitted to mishappen... I seem to read to have read that (D didn't
allow shadowing) but I'm
On Thu, Oct 23, 2014 at 10:50:07AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
[...]
So I agree with you that for now this is not an urgent need. I guess
when we clean out all that ! = stuff this can be done too, or
something like that...
[...]
I believe those flying-saucer
On Thu, Oct 23, 2014 at 11:01:10AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
Hello. I perfectly realize that it's not advisable to take advantage
of shadowing. In fact, I asked the question because I thought D
specifically *didn't* allow shadowing, but here it is, being silently
45 matches
Mail list logo
