Re: Performant method for reading huge text files
You can also try a BufferedRange. http://forum.dlang.org/thread/l9q66g$2he3$1...@digitalmars.com
Explicit Class Instance Allocation
In this article (http://dlang.org/memory.html) there is an
example showing how one could explicitly allocate and deallocate
an object. However, the article seems to be sorely neglected and
out of date ('delete' is deprecated, right?). Could someone
modify the example below using current best practices.
import std.c.stdlib;
import core.exception;
import core.memory : GC;
class Foo
{
new(size_t sz)
{
void* p;
p = std.c.stdlib.malloc(sz);
if (!p)
throw new OutOfMemoryError();
GC.addRange(p, sz);
return p;
}
delete(void* p)
{
if (p)
{
GC.removeRange(p);
std.c.stdlib.free(p);
}
}
}
Thanks,
Mike
scope attribute vs scope keyword vs scope storage class
This article (http://dlang.org/memory.html#raii) mentions a scope attribute. The following section (http://dlang.org/memory.html#stackclass) mentions a scope storage class. This deprecated list (http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack) states that the scope keyword has been deprecated. Are all these terms (scope attribute, scope keyword, and scope storage class) referring to the same thing? Mike
Re: scope attribute vs scope keyword vs scope storage class
On Wednesday, 5 February 2014 at 11:01:00 UTC, Mike wrote: Are all these terms (scope attribute, scope keyword, and scope storage class) referring to the same thing? scope keyword and scope storage class stay: http://dlang.org/function.html#parameters Although AFAIK it's not yet implemented.
Re: Explicit Class Instance Allocation
Mike:
class Foo
{
new(size_t sz)
Also that usage of new() is deprecated.
Bye,
bearophile
Re: Explicit Class Instance Allocation
On Wednesday, 5 February 2014 at 11:19:00 UTC, bearophile wrote:
Mike:
class Foo
{
new(size_t sz)
Also that usage of new() is deprecated.
Bye,
bearophile
Thank you, but can you please point me to your source. It's not
listed here (http://dlang.org/deprecate.html)
Re: Explicit Class Instance Allocation
On Wednesday, 5 February 2014 at 11:23:57 UTC, Mike wrote:
On Wednesday, 5 February 2014 at 11:19:00 UTC, bearophile wrote:
Mike:
class Foo
{
new(size_t sz)
Also that usage of new() is deprecated.
Bye,
bearophile
Thank you, but can you please point me to your source. It's
not listed here (http://dlang.org/deprecate.html)
It's mentioned here: http://dlang.org/class.html#allocators.
Perhaps a bugreport or even a pull request is in order?
Re: Explicit Class Instance Allocation
Stanislav Blinov: Perhaps a bugreport or even a pull request is in order? https://d.puremagic.com/issues/show_bug.cgi?id=12081 Bye, bearophile
Re: Explicit Class Instance Allocation
On Wednesday, 5 February 2014 at 12:12:12 UTC, bearophile wrote: https://d.puremagic.com/issues/show_bug.cgi?id=12081 Why do I sense another holy war in the bugzilla coming? :)
Re: scope attribute vs scope keyword vs scope storage class
On Wednesday, 5 February 2014 at 11:01:00 UTC, Mike wrote: This article (http://dlang.org/memory.html#raii) mentions a scope attribute. The following section (http://dlang.org/memory.html#stackclass) mentions a scope storage class. This deprecated list (http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack) states that the scope keyword has been deprecated. Are all these terms (scope attribute, scope keyword, and scope storage class) referring to the same thing? Mike D documentation has rather incosistent naming for attribute groups. - scope classes are deprecated, but usage of scope as storage class is still legal (it is expected to be a no-op for now) - scope storage class for function parameters is also accepted as no-op. For delegates it actually has a meaning. No deprecation. - scope statement as in scope(exit) was never suggested to be deprecated. - scope attribute most likely refers to declaration of scope classes and this is deprecated with them
Getting NotNull Right
Hi!
I've changed Adam D Ruppes module notnull.d a bit to allow
assignment of a NotNull inherited class instance to a NotNull
base class using
/** Assignment from $(D NotNull) Inherited Class $(D rhs) to
$(D NotNull) Base
Class $(D this). */
typeof(this) opAssign(U)(NotNull!U rhs) @safe pure nothrow if
(isAssignable!(T, U)) {
this._value = rhs._value;
return this;
}
This allows
unittest
{
class A {}
class B : A {}
NotNull!B b = assumeNotNull(new B);
NotNull!A a = assumeNotNull(new A);
a = b;
assert(a is b);
}
However I haven't figure out how to allow the follow code to
compile
unittest
{
class A {}
class B : A {}
void f(NotNull!A a) {}
NotNull!B b = assumeNotNull(new B);
f(b);
}
which I believe should work automatically.
How do I make that happen?
Complete source of module notnull.d follows:
#!/usr/bin/env rdmd
module notnull;
import std.traits: isAssignable;
/** Note that NotNull!T is not NotNullable :) */
alias NotNullable(T) = isAssignable!(T, typeof(null));
/**
NotNull ensures a null value can never be stored.
* You must initialize it when declared
* You must never assign the null literal to it (this is a
compile time error)
* If you assign a null value at runtime to it, it will
immediately throw an Error
at the point of assignment.
NotNull!T can be substituted for T at any time, but T cannot
become
NotNull without some attention: either declaring NotNull!T, or
using
the convenience function, notNull.
Condition: T must be a reference type.
Instead of: __traits(compiles, { T t; assert(t is null); }.
TODO: Merge with http://arsdnet.net/dcode/notnullsimplified.d
Examples:
---
int myInt;
NotNull!(int *) not_null = myInt;
// you can now use variable not_null anywhere you would
// have used a regular int*, but with the assurance that
// it never stored null.
---
*/
struct NotNull(T) if (NotNullable!T)
{
@disable this(); // Disallow default initialized (to null)
/** Assignment from $(D NotNull) Inherited Class $(D rhs) to
$(D NotNull) Base
Class $(D this). */
typeof(this) opAssign(U)(NotNull!U rhs) @safe pure nothrow if
(isAssignable!(T, U)) {
this._value = rhs._value;
return this;
}
NotNull!U opCast(U)() @safe pure nothrow if (isAssignable!(U,
T)) {
return NotNull!_value;
}
// this could arguably break the static type check because
// you can assign it from a variable that is null.. but I
// think it is important that NotNull!Object = new Object();
// works, without having to say assumeNotNull(new Object())
// for convenience of using with local variables.
/// Constructs with a runtime not null check (via assert()).
this(T value) @safe pure nothrow
{
assert(value !is null);
_value = value;
}
/** Disable null construction. */
@disable this(typeof(null));
/** Disable null assignment. */
@disable typeof(this) opAssign(typeof(null));
private T _value;
@property inout(T) _valueHelper() inout
{
assert(_value !is null); // sanity check of invariant
return _value;
}
// Apparently a compiler bug - the invariant being
uncommented breaks all kinds of stuff.
// invariant() { assert(_value !is null); }
alias _valueHelper this; /// this is substitutable for the
regular (nullable) type
/* void toMsgpack (Packer) (ref Packer packer) const {
packer.pack(_value); } */
/* void fromMsgpack(Unpacker)(auto ref Unpacker unpacker) {
unpacker.unpack(_value); } */
}
/** A convenience function to construct a NotNull value from
something $(D t)
you know isn't null.
*/
NotNull!T assumeNotNull(T)(T t) if (NotNullable!T)
{
return NotNull!T(t); // note the constructor asserts it is
not null
}
/** A convenience function to check for null $(D t). If you pass
null to $(D t),
it will throw an exception. Otherwise, return NotNull!T.
*/
NotNull!T enforceNotNull(T, string file = __FILE__, size_t line =
__LINE__)(T t) if (NotNullable!T)
{
import std.exception: enforce;
enforce(t !is null, t is null!, file, line);
return NotNull!T(t);
}
unittest
{
import core.exception;
import std.exception;
void NotNullCompiliationTest1()() // I'm making these
templates to defer compiling them
{
NotNull!(int*) defaultInitiliation; // should fail
because this would be null otherwise
}
assert(!__traits(compiles, NotNullCompiliationTest1!()()));
void NotNullCompiliationTest2()()
{
NotNull!(int*) defaultInitiliation = null; // should fail
here too at compile time
}
assert(!__traits(compiles, NotNullCompiliationTest2!()()));
int dummy;
NotNull!(int*) foo = dummy;
assert(!__traits(compiles, foo = null)); // again, literal
null is caught at compile time
int* test;
test = dummy;
Re: Getting NotNull Right
The alias this could be changed to allow conversion to the base
class one step at a time. I'm not happy with it since it'd
essentially do a big chain down to Object and it also ignores
interfaces, but it's a start:
static if(is(T == class) !is(T == Object))
@property NotNull!(BaseClassesTuple!T[0]) _valueHelper() inout
{
assert(_value !is null); // sanity check of invariant
return assumeNotNull(cast(BaseClassesTuple!T[0]) _value);
}
else
@property inout(T) _valueHelper() inout
{
assert(_value !is null); // sanity check of invariant
return _value;
}
(Previously, it just had the second _valueHelper)
Do you have any suggestions for project directory structure?
Suppose I have a project protocols that uses DMock and a library Foo. I would like to use a structure dub style..Which solution is better: A. protocols ├── bin │ └── protocols.a ├── dmocks │ └── *.d ├── foo │ └── *.d ├── src │ └── protocols │ └── *.d B. protocols ├── bin │ └── protocols.a ├── src │ ├── dmocks │ │└── *.d │ ├── foo │ │└── *.d │ └── protocols │└── *.d Or another solution? Thanks
Re: Do you have any suggestions for project directory structure?
I'd try to keep external libraries out of the main source directory or as part of separate git submodule hierarchy if using stuff like dub is not an option. They don't belong to project sources.
Re: std.parallelism: How to wait all tasks finished?
On Wednesday, 5 February 2014 at 15:38:14 UTC, Cooler wrote: Will not help. I don't know beforehand what tasks will be created. procData is recursive and it decides create new task or not. You seem to be saying that you want to be able to wait for all tasks to complete an indefinite number of times, adding more tasks after each one. Why would you want to do that? The queue for the pool is infinitely long, so just keep adding tasks till you have no more tasks to add. Or if you have a progression of types, like all tasks of type A have to be complete before you can start running the tasks of type B, then you should be able to have a separate thread pool for each type.
Re: Getting NotNull Right
On Wednesday, 5 February 2014 at 21:58:08 UTC, Nordlöw wrote: Members of a derived class T become inaccessible in NotNull!T with this approach. Do you have any clue to why? aaah, of course, now alias this returns the base class instead of the derived one. We could possibly work around it with opDispatch forwarding to the methods... or think of a new approach for the implicit conversion. blargh, i don't have a good answer right now
Re: Getting NotNull Right
On Wednesday, 5 February 2014 at 22:13:00 UTC, Adam D. Ruppe wrote: On Wednesday, 5 February 2014 at 21:58:08 UTC, Nordlöw wrote: Members of a derived class T become inaccessible in NotNull!T with this approach. Do you have any clue to why? aaah, of course, now alias this returns the base class instead of the derived one. We could possibly work around it with opDispatch forwarding to the methods... or think of a new approach for the implicit conversion. blargh, i don't have a good answer right now Thanks anyway. If we get it right maybe we could propose it for Phobos :) /Per
Re: Do you have any suggestions for project directory structure?
On Wednesday, 5 February 2014 at 22:01:08 UTC, Orfeo wrote: On Wednesday, 5 February 2014 at 21:54:15 UTC, Dicebot wrote: I'd try to keep external libraries out of the main source [cut] Something like this? ├── protocols │ └── src ├── dmocks │ └── *.d ├── foo │ └── *.d Yes. And make sure build script for your project allows to define path to external import folder(s). dub automates that for you
Re: Do you have any suggestions for project directory structure?
I'm not sure I would recommend this, but I've been using something like this: protocols ├── dmocks (I don't use this) │ └── *.d ├── libs │ └──foo │ └── *.d │ └── bar │ └── source │ └── *.d │ ├── source │ └── protocols │ └── *.d The libraries can actually have dependencies on other libraries, in this case bar requires foo and will expect to find ../foo
