Feel free to take a look at https://github.com/hpohl/ext/. Maybe
you can find something useful.
On Wednesday, 18 September 2013 at 14:49:27 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
Several of us have been talking about Qt Creator and D in
various subthreads of the current IDE-related discussions going
on right now, so I thought it might be worth raising as a
matter of general
On Thursday, 4 July 2013 at 00:52:13 UTC, Timon Gehr wrote:
Also, I think [] should have a singleton type as well.
Currently it is a void[] with special implicit conversion rules.
+1
a) In the so-called whole dtor which calls the dtors of all
members including the dtor declared (if any). The attributes of
the whole dtor are deduced.
b) Everything takes place in the dtor declared (if any). If the
dtor is pure/nothrow/safe, it is guaranteed that the object can
be
According to the example on the frontpage the default input:
The D programming language. Modern convenience. Modeling power.
Native efficiency.
Has an average line length of 1.
Documentation:
Member functions which are private or package are never virtual,
and hence cannot be overridden.
I was about to write a bug report about this, because in my code
there are tons of overridden methods which actually should be
private/package. Can anyone tell me why this decision
I've been working on a pull request and came up with something
like this:
private void initialize(A...)(auto ref A args)
{
auto m = cast(void* function(size_t size) pure)malloc;
_store = cast(Impl*) enforce(m(Impl.sizeof));
auto r = cast(void function(in void* p, size_t sz) nothrow
By the way, my post is related to the impurity of RefCounted:
http://d.puremagic.com/issues/show_bug.cgi?id=9998
On Monday, 29 April 2013 at 11:32:33 UTC, monarch_dodra wrote:
I'm still worried about what it means for a pure function to
throw... (I'm thinking about the enforce(malloc) scheme)
If malloc returns null, we are out of memory. In D this is not an
exception, it is an error. So I guess we just
On Monday, 29 April 2013 at 12:08:58 UTC, monarch_dodra wrote:
I've hit this issue before: In D, if the *managed* memory runs
out, then it is an error (since then *everything* crumbles:
arrays, GC. etc). The reason it is an error is that since the
memory is managed by the language, there is
On Tuesday, 9 April 2013 at 20:46:12 UTC, Steven Schveighoffer
wrote:
No. You are not allowed to access any GC-managed resources
inside a destructor.
Okay, I finally found it:
http://dlang.org/class.html#destructors. But it's not listed
here: http://dlang.org/garbage.html.
And it won't be
In fact there is no order of destruction. And this is one of the
most annoying D problems I recently had to deal with. Look at
this example: http://dpaste.dzfl.pl/f3f860b0. This time, it
segfaulted. Next time it may (in theory) not, because the dtor of
a is called before the one of b. A holds
struct S {
int value() {
return 1;
}
}
class Base {
S s;
alias s this;
}
class Derived : Base {
void func() {
int i = value();
}
}
Fails with main.d(14): Error: undefined identifier value.
Explicitly casting this to Base works:
void func() {
On Monday, 8 October 2012 at 08:53:39 UTC, simendsjo wrote:
You can create a wrapper struct that includes an invariant:
import std.stdio;
struct Image
{
int width;
void doSomething()
{
}
void modifiesWidth()
{
--width;
}
}
void func(Image img)
{
Imagine you want an image to keep the width of 512:
void func(Image img) {
assert(img.width == 512);
img.doSomething();
assert(img.width == 512);
while (img.somethingElse()) {
assert(img.width == 512)
someFunc(img);
assert(img.width == 512);
}
}
In
On Sunday, 7 October 2012 at 20:18:15 UTC, Ali Çehreli wrote:
Sounds good.
Thanks.
You haven't mentioned the invariant keyword, so perhaps you are
not aware of that feature?
http://dlang.org/class.html#Invariant
http://dlang.org/dbc.html
Although the docs seem to favor classes,
On Friday, 5 October 2012 at 13:57:13 UTC, bearophile wrote:
void foo1(C1 c1, C2 c2)
in {
assert(c1 !is null);
assert(c2 !is null);
} body {
...
}
And in public library code, you can't even use assert. You have
to throw an error/exception. Runtime checks guaranteed even in
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała
wrote:
Agreed. Nullable types are a feature not a bug. There is no
need to change it. Bugs occur when you do not know the language
rules and make assumptions instead. This can happen whith any
language and any rules. As to an
On Wednesday, 3 October 2012 at 16:11:53 UTC, Franciszek Czekała
wrote:
As my comments indicated : the presence of a value does not
guarantee a valid value by itself. The C++ declaration int n;
introduces a value, good luck using it.
auto c = new Class();
Tell me, does c contain an invalid
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 16:58:52 UTC, Maxim Fomin wrote:
How much code would be broken by moving nullable references
from current state to question mark notation?
That's another question :]
I expect that non-nullable class objects (called references
here) addition (if there is no
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
No, it is meaningless. If you have a class which is supposed to
hold a prime number and you pass it to a function are you going
to check each time that the value is indeed prime? That would
kill the efficiency of your
The way D is dealing with classes reminds me of pointers because
you can null them. C++'s references cannot (of course you can do
some nasty casting). So you can be sure to have a valid
well-defined object. But then there is always the ownership
problem which renders them more dangerous as
On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
wrote:
On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote:
[…]
Anyway, it's too late to change it now.
I disagree. There are always opportunities to make changes to
things,
you just have manage things carefully.
I
On Saturday, 15 September 2012 at 13:36:00 UTC, Maxim Fomin wrote:
On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne
Petersen wrote:
But this being said, I agree that references being nullable by
default is hurtful. It allows any object reference to have an
invalid state even though
On Saturday, 15 September 2012 at 14:36:33 UTC, Maxim Fomin wrote:
On Saturday, 15 September 2012 at 14:17:53 UTC, Simen Kjaeraas
wrote:
And in real code it could crash after dereferencing and
before passing to bar, if accessed (meaning that problem is
in erroneous pointer usage, not accepting
On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis
wrote:
Of course people use it. Having nullable types is _highly_
useful. It would
suck if references were non-nullable. That would be _horrible_
IMHO. Having a
means to have non-nullable references for cases where that
makes
On Saturday, 15 September 2012 at 18:05:55 UTC, Jonathan M Davis
wrote:
I'd argue that using null for indicating something other than
the lack of a
value is bad design. But there are plenty of cases where being
able to
indicate that there is no value is useful.
I agree.
And if a function
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references cannot (of course you can do some nasty
casting).
Doing null references in C
I've ended up with a TypeTuple storing 1230 auto-generated types.
Now the compiler claims there is a recursive template expansion.
How to stir him from his resolve?
On Friday, 17 August 2012 at 22:01:42 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2012 23:45:49 Henning Pohl wrote:
I've ended up with a TypeTuple storing 1230 auto-generated
types.
Now the compiler claims there is a recursive template
expansion.
How to stir him from his resolve?
I
On Friday, 17 August 2012 at 22:28:12 UTC, bearophile wrote:
Henning Pohl:
I want to store lots (~615) dynamically loaded function
pointers in a class and call them using opDispatch. To provide
a type-safe function call, the types of the functions have to
be stored somewhere, in a TypeTuple
On Sunday, 12 August 2012 at 02:32:30 UTC, Timon Gehr wrote:
On 08/11/2012 11:42 PM, Henning Pohl wrote:
A struct takes a mixin template as argument:
struct S(alias Mixin) {
mixin Mixin;
}
How to specialize a mixin template like this one to pass to S?
mixin template MixinTemplate(T) {
}
S
So the struct is defined as:
struct S(T) {
}
template isS(T) {
// ...
}
static assert(isS(S!float));
static assert(!isS(float));
There may be some nasty ways using fullQualifiedName!T and so on
but I guess there is a better way, isn't it?
On Saturday, 11 August 2012 at 19:06:22 UTC, Chris Cain wrote:
Same idea, but doing it with just one template and using static
ifs...
struct S(T) {}
template isS(T) {
static if(is(T _ : S!U, U))
enum isS = true;
else
enum isS = false;
}
static assert(isS!(S!float));
A struct takes a mixin template as argument:
struct S(alias Mixin) {
mixin Mixin;
}
How to specialize a mixin template like this one to pass to S?
mixin template MixinTemplate(T) {
}
S(MixinTemplate!float); // Something like this
A struct is meant to take only integers as parameters:
struct SomeStruct(intergers...) {
int opIndex(size_t idx) /* ... */ {
return integers[idx]; // Error ...
}
}
alias SomeStruct!(1, 2, 3) ss;
But it results in:
Error: undefined identifier integers, did you mean tuple
On Friday, 10 August 2012 at 14:02:08 UTC, Andrei Alexandrescu
wrote:
On 8/10/12 9:55 AM, Henning Pohl wrote:
A struct is meant to take only integers as parameters:
struct SomeStruct(intergers...) {
int opIndex(size_t idx) /* ... */ {
return integers[idx]; // Error ...
}
}
alias SomeStruct!(1
On Friday, 10 August 2012 at 14:10:38 UTC, Vladimir Panteleev
wrote:
On Friday, 10 August 2012 at 14:10:02 UTC, Vladimir Panteleev
wrote:
On Friday, 10 August 2012 at 14:05:16 UTC, Henning Pohl wrote:
Oups, sorry, imagine there isn't one.
So the error is: variable idx cannot be read
On Friday, 10 August 2012 at 14:35:29 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
Henning Pohl , dans le message (digitalmars.D:174569), a
écrit :
On Friday, 10 August 2012 at 14:10:38 UTC, Vladimir Panteleev
wrote:
On Friday, 10 August 2012 at 14:10:02 UTC, Vladimir
Great, thank you :]
The solution provided by David seems to be shortest. You can even
pass the ints directly.
Most closed source C and C++ libraries provide headers and
binaries. It seems to me that there is no way to do this in D,
because the source files always have to be available to import
their modules.
I'm not going to write something proprietary or closed source,
but i wonder if others can do
On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan wrote:
On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl
henn...@still-hidden.dewrote:
Most closed source C and C++ libraries provide headers and
binaries. It
seems to me that there is no way to do this in D, because the
source files
On Sunday, 15 July 2012 at 13:26:19 UTC, Benjamin Thaut wrote:
Am 15.07.2012 15:06, schrieb Gor Gyolchanyan:
On Sun, Jul 15, 2012 at 4:33 PM, Henning Pohl
henn...@still-hidden.de
mailto:henn...@still-hidden.de wrote:
On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan
wrote
45 matches
Mail list logo
