On Thursday, October 23, 2014 11:47:04 Shriramana Sharma via
Digitalmars-d-learn wrote:
Oh OK here it is:
http://dlang.org/deprecate.html#Variable%20shadowing%20inside%20functions
But it says "it is an error to use the feature" by 2.061 and
I'm using
2.066!
Doesn't the scope of that deprecati
Oh OK here it is:
http://dlang.org/deprecate.html#Variable%20shadowing%20inside%20functions
But it says "it is an error to use the feature" by 2.061 and I'm using 2.066!
Doesn't the scope of that deprecation cover struct members too? In
general it should be like "variables in inner scopes should
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 silentl
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 o
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 no
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 /
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 ;
> impor
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
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 cleaned up. :-) I'm
finicky lik
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 sup
Hi Jonathan and thanks again for your kind replies.
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
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 object where it's initially constr
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_ ; writeln
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:
# in
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
o
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
go
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 Sco
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 guess)
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 tel
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 t
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 reli
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
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
elsewher
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
http://dlang.org/phobos/std_ascii.html#.white
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
http://forum.dlang.org/post/mailman
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 startin
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 argume
On Wed, 22 Oct 2014 18:44:26 +
via Digitalmars-d-learn 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. documentation examples using
> > 'auto
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 dangero
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 th
On Wed, 22 Oct 2014 18:03:44 +
anonymous via Digitalmars-d-learn
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 C();
> > dest
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_ptr foo = std::make_unique();
>
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 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, consid
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 de
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 t
On Wed, 22 Oct 2014 16:49:20 +0100, eles 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.
Structs are speci
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.
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_ptr foo = std::make_unique();
std::unique_ptr bar = std
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 together
On Wed, 22 Oct 2014 07:58:49 +
Kagamin via Digitalmars-d-learn
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 anyway with it's CTFE magic. and ge
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 minim
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 l
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 inadequat
It's how COM casts objects
http://msdn.microsoft.com/en-us/library/ms687230.aspx
The idea is that the object you work with is responsible for
casting itself to an interface you need.
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 d
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:
data.schwartzSort!
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. Picki
47 matches
Mail list logo
