On 6/13/2014 8:15 PM, Mathias LANG wrote:
On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote:
13-Jun-2014 04:31, Walter Bright пишет:
https://github.com/D-Programming-Language/dmd/pull/3655
Heh, I had been under the impression was already Boost. :P
It's probably nice to have
On Saturday, 14 June 2014 at 06:07:08 UTC, Nick Sabalausky wrote:
I doubt it. First, it's the backend that's not technically OSI,
frontend was (apparently) GPL. Second, I can't imagine any
Linux distro rejecting GPL - they'd have to boot the kernel and
core utils, too.
Actually, the frontend
On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu
wrote:
On 6/12/14, 6:34 AM, Dicebot wrote:
It was decided and 100% certain - virtual is not going in.
Need to
remove it from DMD before this release is out.
Yes please. -- Andrei
Since we didn't seem to have a pull request for
14-Jun-2014 04:46, Walter Bright пишет:
On 6/13/2014 4:31 AM, Dmitry Olshansky wrote:
It's probably nice to have less restrictive license, but what we aim
to achieve
with that?
I do not want to come across as rude but from pragmatic standpoint it's
not interesting. I'm not opposing it
On Thursday, 12 June 2014 at 16:42:38 UTC, Dmitry Olshansky wrote:
It's always nice to ask something on D NG, so many good answers
I can hardly choose whom to reply ;) So this is kind of
broadcast.
Yes, the answer seems spot on - reflection! But allow me to
retort.
I'm not talking about
On 6/14/14, 8:05 AM, Dicebot wrote:
Adoption - yes. Production usage - less so (though still important).
Difference between 1 second and 5 seconds is very important. Between 10
seconds and 1 minute - not so much.
Wait, what? -- Andrei
Nick Sabalausky, el 14 de June a las 02:06 me escribiste:
It's probably nice to have less restrictive license, but what we aim
to achieve with that?
Make commercial companies contribute to DMD more freely?
There is no problem even with GPL.
Let them build and sell their own products out
On Saturday, 14 June 2014 at 15:25:11 UTC, Andrei Alexandrescu
wrote:
On 6/14/14, 8:05 AM, Dicebot wrote:
Adoption - yes. Production usage - less so (though still
important).
Difference between 1 second and 5 seconds is very important.
Between 10
seconds and 1 minute - not so much.
Wait,
14-Jun-2014 19:05, Dicebot пишет:
On Thursday, 12 June 2014 at 16:42:38 UTC, Dmitry Olshansky wrote:
[snip]
Well, I'm biased by heavy-handed ones. Say I have a (no longer) secret
plan of doing a next-gen parser generator in D. Needless to say swaths
of non-trivial code generation. I'm all for
Dmitry Olshansky, el 14 de June a las 18:18 me escribiste:
14-Jun-2014 04:46, Walter Bright пишет:
On 6/13/2014 4:31 AM, Dmitry Olshansky wrote:
It's probably nice to have less restrictive license, but what we aim
to achieve
with that?
I do not want to come across as rude but from
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella
wrote:
OK, as a side effect of this, this might encourage companies
not to use
D but to develop tools based on DMDFE, but companies that are
too lazy
or to BAD not to contribute the changes back, which I'm not
sure is such
a good
On 6/14/2014 3:58 AM, Joakim wrote:
On Saturday, 14 June 2014 at 06:07:08 UTC, Nick Sabalausky wrote:
I doubt it. First, it's the backend that's not technically OSI,
frontend was (apparently) GPL. Second, I can't imagine any Linux
distro rejecting GPL - they'd have to boot the kernel and core
On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
14-Jun-2014 04:46, Walter Bright пишет:
3. Harmonization with usage of Boost in the runtime library
In other words simplify licensing, but again compiler and runtime
library do not have to have anything in common. There is no issue to
begin
On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella
wrote:
OK, as a side effect of this, this might encourage companies
not to use
D but to develop tools based on DMDFE, but companies that are
too lazy
or to BAD not to
On 6/14/2014 11:03 AM, Nick Sabalausky wrote:
I'll take B, thanks. ;)
Right on, Nick.
And there's another advantage I neglected to mention - it allows DMDFE code to
be moved into Phobos without issues.
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote:
And there's another advantage I neglected to mention - it
allows DMDFE code to be moved into Phobos without issues.
I don't think Nick's argument is particularly compelling, but the
DDMD - Phobos connection definitely makes the
On 14 June 2014 19:03, Nick Sabalausky via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
14-Jun-2014 04:46, Walter Bright пишет:
3. Harmonization with usage of Boost in the runtime library
In other words simplify
14-Jun-2014 22:03, Nick Sabalausky пишет:
On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
14-Jun-2014 04:46, Walter Bright пишет:
3. Harmonization with usage of Boost in the runtime library
In other words simplify licensing, but again compiler and runtime
library do not have to have anything
On 6/14/2014 9:02 AM, Leandro Lucarella wrote:
Not really, the standard library is included into user code (because of
the templates), and that's the reason why it needs to be under a very
permissive license. The compiler, on the other hand, doesn't, and one
could agree is good to force people
On 6/14/2014 2:47 PM, David Nadlinger wrote:
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote:
And there's another advantage I neglected to mention - it allows DMDFE
code to be moved into Phobos without issues.
I don't think Nick's argument is particularly compelling,
Granted,
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella
wrote:
No free license restrict commercial use. What using boost
enable is only
proprietary use, i.e. changing the DMD FE and keeping the
changes
private, even if you distribute the binary with the compiled
DMDFE. As I
said before,
Very nice, thanks. I'm looking forward to trying it out when I can find
the time. I'm not a big fan of bindings/wrappers.
Jim
As it happens I am writing a kind of DFIX on top of DScanner
right at the moment.
There are a few details to sort out. But I should have some small
demo pretty soon.
Regrards, Stefan
On 6/14/2014 2:52 PM, Dmitry Olshansky wrote:
14-Jun-2014 22:03, Nick Sabalausky пишет:
Scenario A:
--
Them: What license does D use?
Me: WAT? Language is not a product in itself.
While that's technically true, people often think of them as complete
products
On Fri, 13 Jun 2014 12:00:39 -0700
Andrei Alexandrescu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On 6/13/14, 10:15 AM, Nick Sabalausky wrote:
On 6/13/2014 12:49 PM, Andrei Alexandrescu wrote:
Being able to negate the final:
label is nice to have but not a
Kapps, el 14 de June a las 18:19 me escribiste:
On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella
wrote:
OK, as a side effect of this, this might encourage companies not
to use
D but to develop tools based on DMDFE, but
David Nadlinger, el 14 de June a las 18:47 me escribiste:
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote:
And there's another advantage I neglected to mention - it allows
DMDFE code to be moved into Phobos without issues.
I don't think Nick's argument is particularly
Joakim, el 14 de June a las 19:31 me escribiste:
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote:
No free license restrict commercial use. What using boost enable
is only
proprietary use, i.e. changing the DMD FE and keeping the changes
private, even if you distribute the
On 6/14/2014 5:49 PM, Jonathan M Davis via Digitalmars-d-announce wrote:
and it becomes a question of whether the familiarity of using
virtual instead of !final or final(false) (or whatever we come up with) is
worth adding another keyword
FWIW, I don't think virtual is all that valuable as a
These are cool. 1,5, and 6 I thought were the best. These are
just drafts though, right? Maybe needs a little color or atleast
a greyscale gradient going on.
The main thing to change would be to make the hooks on each
face of the cube have a stronger or more obvious 'D' shape though.
In this post:
http://forum.dlang.org/post/l62466$2n8p$1...@digitalmars.com
Walter said, in November:
I agree that async/await has to eventually be added to D. I'm
not
convinced it can or should be done with AST macros.
But this blog post shows why the rigid features of C# are not
always
On Friday, 13 June 2014 at 21:13:20 UTC, bearophile wrote:
This was surely discussed in past, but I don't remember the
answer (so perhaps this is more fit in D.learn).
Dereferencing the null pointer in C is undefined behaviour, so
in most cases the program segfaults, but sometimes the
On 2014-06-13 20:16, H. S. Teoh via Digitalmars-d wrote:
I think this is starting to show itself as an anti-pattern, or at least,
one of those obscure dark corners of D infested with complex
interactions between unexpected features and possible compiler quirks.
Probably the best thing to do is
On Saturday, 14 June 2014 at 00:40:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sat, 14 Jun 2014 00:34:51 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d
wrote:
On Fri, 13 Jun 2014 21:23:00 +
On 2014-06-13 20:03, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
for(;;) is a special case with no real benefit IMHO. It's a loop whose
condition is implicitly true rather than actually having a condition
in it.
On Friday, 13 June 2014 at 21:41:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Fri, 13 Jun 2014 11:03:14 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I disagree, it's not a special case. It's simply a logical
consequence
of each part of the for-loop being
On 2014-06-14 04:12, Jeremy DeHaan wrote:
I agree. Also, this page (http://dlang.org/dmd-osx.html) says that the
base requirement is a 32 bit OSX. Why is the DMD version that is
released 64 bit? That seems very counter intuitive.
Technically you can run 64bit applications on 32bit OS X if you
On Saturday, 14 June 2014 at 10:38:08 UTC, Jacob Carlborg wrote:
On 2014-06-14 04:12, Jeremy DeHaan wrote:
I agree. Also, this page (http://dlang.org/dmd-osx.html) says
that the
base requirement is a 32 bit OSX. Why is the DMD version that
is
released 64 bit? That seems very counter
On Saturday, 14 June 2014 at 11:16:57 UTC, Marc Schütz wrote:
On Saturday, 14 June 2014 at 10:38:08 UTC, Jacob Carlborg wrote:
Technically you can run 64bit applications on 32bit OS X if
you have a 64bit CPU.
Really? The other way round, yes, but this would really
surprise me...
Yes.
On 12/06/2014 18:30, Nick Treleaven wrote:
On 12/06/2014 17:59, bearophile wrote:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in
Phobos:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it does is disallow instantiating the type without
specifying an initializer (e.g. a struct literal, a value
returned from a factory function, or `static opCall()`).
On 06/13/2014 11:41 PM, Jonathan M Davis via Digitalmars-d wrote:
It's a special case in that the middle portion is supposed to be the condition
that the loop use to determine whether it can continue, and omitting it means
that it has to add the true itself,
No, omitting it means that it does
On 06/14/2014 02:39 AM, Jonathan M Davis via Digitalmars-d wrote:
On Sat, 14 Jun 2014 00:34:51 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote:
On Fri, 13 Jun 2014 21:23:00 +
deadalnix via Digitalmars-d
On Saturday, 14 June 2014 at 12:33:28 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it does is disallow instantiating the type without
specifying an initializer (e.g. a struct literal, a value
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default
On 6/14/14, 5:33 AM, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value. All it
does is disallow instantiating the type without specifying an
initializer (e.g. a struct literal, a value returned from a
Timon Gehr:
Have you ever used void[0][T]?
I have never used that so far. What is it useful for?
Bye,
bearophile
On Saturday, 14 June 2014 at 15:22:07 UTC, Andrei Alexandrescu
wrote:
On 6/14/14, 5:33 AM, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it
does is disallow instantiating the type without
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of using code like this (only one or the other should be
allowed) is rather natural, it breaks nothing, it avoids the
programmer to introduce a variable that is not needed, making the
code less noisy:
foreach (;0 .. 10) {...}
foreach (0 .. 10) {...}
I don't see the need for so many
On 06/14/2014 05:33 PM, bearophile wrote:
Timon Gehr:
Have you ever used void[0][T]?
I have never used that so far. What is it useful for?
Bye,
bearophile
It's a hash set with a somewhat awkward interface.
On 13.06.2014 12:08, Dmitry Olshansky wrote:
13-Jun-2014 12:22, Rainer Schuetze пишет:
If I add the actual copy into heap2 (i.e. every fourth page of 512
MB is
copied), I get 80-90 ms more.
Aye... this is a lot. Also for me it turns out that unmapping CoW view
at the last step takes the
On Saturday, 14 June 2014 at 15:22:07 UTC, Andrei Alexandrescu
wrote:
On 6/14/14, 5:33 AM, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it
does is disallow instantiating the type without
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an
object to exist that violates it without an Error being thrown.
Arguing that this is not part of the
Suppose you are sketching out your application, and you decide
that you need two classes, A and B. You know that instances of
both classes will be asked to foo things up, so you tell the type
checker that both A and B are foo-uppers:
interface Foo
{
void foo();
}
On Saturday, 14 June 2014 at 16:41:46 UTC, monarch_dodra wrote:
.init should simply mean the default bit state of the
object. Let's not make it into anything more complicated than
that.
I guess this is the root of disagreement. There is no place in
documentation that says that T.init is in
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an
object to exist that violates it
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an
object to exist that violates it
14-Jun-2014 20:34, Rainer Schuetze пишет:
On 13.06.2014 12:08, Dmitry Olshansky wrote:
13-Jun-2014 12:22, Rainer Schuetze пишет:
If I add the actual copy into heap2 (i.e. every fourth page of 512
MB is
copied), I get 80-90 ms more.
Aye... this is a lot. Also for me it turns out that
On Saturday, 14 June 2014 at 17:15:16 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 16:41:46 UTC, monarch_dodra wrote:
.init should simply mean the default bit state of the
object. Let's not make it into anything more complicated than
that.
I guess this is the root of disagreement. There
Recalling the previous discussion of throwing exception being costly, I
thought the idiom of pay as you go is worth incorporating into the
standard library.
In brief:
throw exception(CPU temperature is below, 2.5, K);
vs
throw new Exception(text(CPU temperature is below, 2.5, K));
or:
Good tutorial choices; they're very well-written. I haven't used
F# much, but here's my take (call me out on any mistakes in my
understanding):
`async` being just a particular instance of a class of
user/library-defined computation expression has a lot of good
things going for it. This setup
Le 12/06/2014 23:12, John a écrit :
On Thursday, 12 June 2014 at 19:38:06 UTC, André wrote:
Hi,
Is it possible to add a newsgroup for DGui on this forum? It
would be great to have a communication platform and also
advertising this really great Windows ui toolkit. With an easy to
use and
Le 14/06/2014 22:18, Xavier Bigand a écrit :
Le 12/06/2014 23:12, John a écrit :
On Thursday, 12 June 2014 at 19:38:06 UTC, André wrote:
Hi,
Is it possible to add a newsgroup for DGui on this forum? It
would be great to have a communication platform and also
advertising this really great
On 6/14/14, 10:05 AM, David Nadlinger wrote:
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an object
to exist that violates it without an Error being
On Sat, 14 Jun 2014 10:20:51 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 13 June 2014 at 21:41:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Fri, 13 Jun 2014 11:03:14 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I disagree, it's
On 06/14/2014 11:23 PM, Jonathan M Davis via Digitalmars-d wrote:
...
It's the lack of a condition that I object to. IMHO it's a fundamental
violation of how loops work.
Fundamentally, loops loop. That is the only fundamental thing about loops.
On Sat, Jun 14, 2014 at 02:23:36PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
On Sat, 14 Jun 2014 10:20:51 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
But this special treatment of the second operand is the same in all
forms of the for loop:
for(int i =
On 06/14/2014 09:04 PM, Dmitry Olshansky wrote:
Recalling the previous discussion of throwing exception being costly, I
thought the idiom of pay as you go is worth incorporating into the
standard library.
In brief:
throw exception(CPU temperature is below, 2.5, K);
vs
throw new
I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=12923 : UTF
exception in stride even though passes validate
and then a proposed fix. The fix still passes unittests and also solves the
bug, however I'm not sure whether it is correct: is the behavior of
strideImpl correct or is the
On Saturday, 14 June 2014 at 16:41:46 UTC, monarch_dodra wrote:
By that rational, so is void. If you want default initial
state, you just use A().
Using A.init is just the same as using void: It's fuck you
compiler I'm know what I'm doing.
Someone is trying to mess up with Andrei slice
On Saturday, 14 June 2014 at 07:53:17 UTC, bearophile wrote:
In this post:
http://forum.dlang.org/post/l62466$2n8p$1...@digitalmars.com
Walter said, in November:
I agree that async/await has to eventually be added to D. I'm
not
convinced it can or should be done with AST macros.
But this
On 6/14/2014 9:15 AM, Timon Gehr wrote:
On 06/13/2014 11:41 PM, Jonathan M Davis via Digitalmars-d wrote:
It's a special case in that the middle portion is supposed to be the
condition
that the loop use to determine whether it can continue, and omitting
it means
that it has to add the true
On 14/06/2014 7:53 p.m., bearophile wrote:
In this post:
http://forum.dlang.org/post/l62466$2n8p$1...@digitalmars.com
Walter said, in November:
I agree that async/await has to eventually be added to D. I'm not
convinced it can or should be done with AST macros.
But this blog post shows why
On 6/11/2014 8:56 AM, Remo wrote:
This is pretty strange behavior.
At least on Windows I can not confirm this.
Visual Studio 2013, Intel Compiler and Clang for windows have the same
consistent behavior here.
private do NOT affect struct size.
But there is a parameter in Visual Studio that
On 06/13/2014 10:29 PM, Meta wrote:
I thought this was possible, but DMD 2.065 doesn't allow it, saying no
constructor for int:
int* p = new int(3);
Is something like this planned for the future? I know we can already do:
int n = int(3);
Those both compile with 2.066
Ali
On Saturday, 14 June 2014 at 06:39:56 UTC, Ali Çehreli wrote:
On 06/13/2014 10:29 PM, Meta wrote:
I thought this was possible, but DMD 2.065 doesn't allow it,
saying no
constructor for int:
int* p = new int(3);
Is something like this planned for the future? I know we can
already do:
int n
Would
auto i = (int*)(3);
make sense?
Does it work?
On Sat, 14 Jun 2014 01:24:03 +
Mike Franklin via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
In other words, is 'shared __gshared' redundant?
Redundant? Not exactly.
__gshared makes it so that the variable is treated like a C variable - it's
not in TLS - but its _type_ is
On Saturday, 14 June 2014 at 08:09:12 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
Would
auto i = (int*)(3);
make sense?
Does it work?
No:
Error: C style cast illegal, use cast(int*)3
And I don't think it should, because the heap allocation that
you're probably expecting should be
On Friday, 13 June 2014 at 22:12:01 UTC, Ali Çehreli wrote:
On 06/13/2014 03:02 PM, monarch_dodra wrote:
No, it just receives a range, so it does range formating. eg:
[ ~ Element ~ , ~ Element ... ].
It still looks like it could send the formatting characters as
well as the elements
On 06/14/2014 03:58 AM, Reuben wrote:
Hi,
I'm new to D and am trying to compile a simple hello world program.
I get the following error when compiling it:
dmd test.d
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld:
That really is it. The other methods are just other gets to the
buffer, like this:
T[] get_dup(TS strat=TS.cyclic)(size_t n) const {
static if (strat==TS.once) size_t numreads = fixNToFill(n);
else size_t numreads = n;
auto ret = new T[](numreads);
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without constructor we get error: ...Cannot implicitly generate
a
On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote:
On 06/14/2014 03:58 AM, Reuben wrote:
Hi,
I'm new to D and am trying to compile a simple hello world
program.
I get the following error when compiling it:
dmd test.d
And I don't think it should, because the heap allocation that you're
probably expecting should be explicit IMO. For me it's also unintuitive,
because I would read it as constructing a pointer that points to the address
3.
I agree. I'm trying to get a feel on the limits of this new
Paul:
class MyError : Exception {
this(string msg) { super(msg); }
}
Don't call exceptions errors, because in D there are also errors,
so they should have distinct names.
Is any shorter D way?
Perhaps not.
Bye,
bearophile
On Saturday, 14 June 2014 at 11:59:53 UTC, Paul wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
this(string msg) { super(msg); }
}
(without
On Saturday, 14 June 2014 at 12:17:46 UTC, FreeSlave wrote:
On Saturday, 14 June 2014 at 11:59:53 UTC, Paul wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
On 06/14/2014 02:01 PM, Reuben wrote:
On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote:
On 06/14/2014 03:58 AM, Reuben wrote:
Depending on the desired behavior you'll need to remove the -shared
flag from the configuration or add -defaultlib=:libphobos2.so
dmd.conf contains the
Hi,
I'm new to D and stumbled upon this very interesting discussion.
My question now is:
can you provide an example of how to return a collection of
homogeneous elements whose size is not known at compile time (for
wich you would normally use a dynamic array) from a function?
Thanks,
Marco
I get a failure on a test in format.d when I build my own project with
unittest. I though importing phobos header would not regenerate their
unittest modules.
Any idea of what can cause this issue? I already have reinstalled dmd
with visualD completely.
On Saturday, 14 June 2014 at 13:05:52 UTC, Mike Wey wrote:
On 06/14/2014 02:01 PM, Reuben wrote:
On Saturday, 14 June 2014 at 10:45:25 UTC, Mike Wey wrote:
On 06/14/2014 03:58 AM, Reuben wrote:
Depending on the desired behavior you'll need to remove the
-shared
flag from the configuration
On Saturday, 14 June 2014 at 14:02:52 UTC, Marco Cosentino wrote:
Hi,
I'm new to D and stumbled upon this very interesting discussion.
My question now is:
can you provide an example of how to return a collection of
homogeneous elements whose size is not known at compile time
(for
wich you
On Monday, 9 June 2014 at 15:54:21 UTC, Ivan Kazmenko wrote:
I'd expect a multiple overrides of same function error, much
like if I just paste the mixin code by hand. Is that a bug or
working by design? In the latter case, please explain the
reasoning.
http://dlang.org/template-mixin.html
int[] data = [1,2,3,4];// create new array on the
heap
Thanks for the answer.
This is the bit of information I was missing: how to create an
array in the heap.
Is also this a valid way to do so?
int[] data = new int[0];
data ~= [4,2,3,1];
On Saturday, 14 June 2014 at 21:37:51 UTC, Marco Cosentino wrote:
int[] data = [1,2,3,4];// create new array on the
heap
Thanks for the answer.
This is the bit of information I was missing: how to create an
array in the heap.
Is also this a valid way to do so?
int[] data = new
On Sat, 14 Jun 2014 11:59:52 +
Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
One stupid question: in Python subclassing of Exception looks
like:
class MyError(Exception): pass
but in D, if I'm right, we should write more code:
class MyError : Exception {
1 - 100 of 158 matches
Mail list logo
