Re: attribute length missing in std.array: Appender
On 11/27/2014 08:08 AM, Andre wrote: import std.array: appender; const HEADER_LENGTH = 8; auto app = appender!(ubyte[])(); app.put(cast(ubyte)40); app.put(cast(ubyte)5); app.put(cast(ubyte)234); // ... add 5 times 0 A fancy way: :) import std.range; // ... app.put(repeat(cast(ubyte)0).take(5)); Ali
Re: Passing reference data to class and incapsulation
Uranuz: Same situation happens when I assign reference data to properties. Someone has suggested to solve this problem with an attribute, like owned, that forbids to return mutable reference data owned by a class/struct instance. Bye, bearophuile
Re: attribute length missing in std.array: Appender
Ali Çehreli:
auto app = appender!(ubyte[])();
app.put(cast(ubyte)40);
app.put(cast(ubyte)5);
app.put(cast(ubyte)234);
// ... add 5 times 0
A fancy way: :)
import std.range;
// ...
app.put(repeat(cast(ubyte)0).take(5));
Now we have a better syntax for implicit casts:
void main() {
import std.array, std.range;
Appender!(ubyte[]) app;
app.put(ubyte(0).repeat.take(5));
}
Single line, but not lazy:
void main() {
import std.array, std.range;
Appender!(ubyte[]) app = ubyte(0).repeat.take(5).array;
}
But I have a question too. What's the best way to append several
lazy items to a dynamic array? This doesn't work:
void main() {
import std.array, std.range;
int[] arr;
arr.put(only(1, 2, 3));
}
Bye,
bearophile
Re: Passing reference data to class and incapsulation
Same situation happens when I assign reference data to properties. I can check or do something with data at the moment of assignment, but I can't control that someone will modify using initial reference from outside. So do you copy reference data in constructors or properties? Should it be? Or call site should be responsible for not escaping reference somewhere outside and not modifying these data badly? I'd probably do one of three things: * Clone a private copy; * Pass the parameter as an immutable ref; * Change the method signature to take a std.typecons.Unique!T to express the fact that I want transfer of ownership. Try to encode as much information as you can into the method signature to describe your intentions.
Re: Passing reference data to class and incapsulation
V Fri, 28 Nov 2014 06:19:37 +
Uranuz via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
napsáno:
In D we a several data types which are passed by reference:
dynamic arrays, associative arrays. And sometimes we need to pass
these reference data to class instance to store it inside. One of
the principles of object-oriented programming is incapsulation.
So all class data should be only modyfiable via class methods and
properties. But I we pass reference data to class (for example as
parameter in constructor) we still can change these data from
initial code and break some internal logic of class for modifying
these data. Example:
class Foo {
this(int[] b) { bar = b; }
private int[] bar;
//Some methods
}
void main() {
int[] bar = [1,2,3,4,5];
Foo foo = new Foo(bar);
//There I could do some logic with class
bar[2] = 6; //I modify class without some checks from class
//And there I might pass *bar* somewhere outside and break
incapsulation
}
Same situation happens when I assign reference data to
properties. I can check or do something with data at the moment
of assignment, but I can't control that someone will modify using
initial reference from outside. So do you copy reference data in
constructors or properties? Should it be? Or call site should be
responsible for not escaping reference somewhere outside and not
modifying these data badly?
There also possible some situations when these data should be
shared between different pieces of code (for example different
class instance could reference the same memory area). But I think
this is not very good and safe approach and should be avoided if
possible.
But I think storing reference to class inside another class could
be good approach because there could be different type of
relations between classes. For plain data types we often have
types of relations: *ownership* or *aggregation*. But classes can
usualy have more types of relations: *usage* or when one class
subscribes for events of another.
Is there some good links to read for these questions that you
could advice. After several hours of googling I haven't found
good topics about these problems. And I have not enough time for
reading big book.
You can wrap type and add suport for copy on write, something like this:
struct CoW(T:E[], E) {
T data;
bool change = false;
alias data this;
this(T v) {
data = v;
}
this(this) {
change = false;
}
void opIndexAssign(E v, size_t p)
{
if (change is false) {
data = data.dup;
change = true;
}
data[p] = v;
}
}
alias cowIntArr = CoW!(int[]);
class Foo {
this(cowIntArr b) { bar = b; }
private cowIntArr bar;
void printBar() {
writeln(bar);
}
}
void main(string[] args)
{
cowIntArr bar = [1,2,3,4,5];
auto foo = new Foo(bar);
bar[2] = 6;
writeln(bar);
foo.printBar();
}
Dynamic array head const in library code?
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
don't have to change length nor to be reassigned, but I have to
mutate or assign their items. So their length and ptr can be
const/immutable, unlike the array contents. The D type system
doesn't allow this.
So is it a good idea to try to add to Phobos a headConst function
similar to this (only for built-in dynamic arrays) that tries to
enforce those constraints?
import std.traits, std.range;
struct HeadConst(T) {
T[] data;
alias data this;
@property size_t length() const pure nothrow @safe @nogc {
return data.length;
}
@disable void opAssign();
}
HeadConst!(ElementType!R) headConst(R)(R arr)
if (isDynamicArray!R) {
return typeof(return)(arr);
}
void main() {
import std.stdio;
auto arr = new int[2].headConst;
arr[1] = 10;
arr[1].writeln;
arr.length.writeln;
//arr.length = arr.length + 1; // error
auto b = new int[2];
//arr = b; // error
arr[] = b[];
b = arr;
arr[] = 1;
HeadConst!int c = arr;
HeadConst!int d;
arr = d; // fail
}
Bye,
bearophile
Re: [dub] Size of executable
On Thursday, 27 November 2014 at 17:08:00 UTC, CraigDillabaugh wrote: On Thursday, 27 November 2014 at 14:14:50 UTC, Chris wrote: On Thursday, 27 November 2014 at 13:59:23 UTC, CraigDillabaugh wrote: On Thursday, 27 November 2014 at 13:56:19 UTC, Chris wrote: On Thursday, 27 November 2014 at 12:29:03 UTC, Gary Willoughby wrote: On Thursday, 27 November 2014 at 09:33:49 UTC, Chris wrote: I usually use dub to create and build projects. I built one of the projects with dub and then by hand with dmd[1] passing all the files etc. Turned out that the executable built with dub was 1.4 MB whereas the one built by hand was only 807 kB. Why is that? dub compiles and links every file in the source folder whether it's used or not. Whereas with dmd or rdmd you only compile and link the files you actually use. I compiled the exact same files. I excluded those I didn't need in the dub configuration like so: excludedSourceFiles: [...] But dub's executable is bigger. When you build with dub it should print out (if I remember correctly, its been a little while) the command it uses to build your code. Is there any difference between that command and your 'by hand' version? dub says: Compiling using dmd... Linking... I have the exact same setting, I think. I don't build for release with either method. dmd file1.d file2.d file3.d ... (dub compiles the same files, no release build) I am sure there is some way to get it to print out exactly what it is doing. I've done it before when trying to figure out some compilation issues ... unfortunately it was a while ago and the machine I am at now doesn't have dub (or D for that matter) installed. Maybe you need to give the the dub -v (--verbose) option. Type 'dub help' to check - again I can't do that right here. Nope, --verbose doesn't tell me anything useful in this regard. Only stuff like Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json ... I added a lot to the project yesterday, and still, the pure dmd-compiled version is 1.9 MB whereas the dub-compiled version is 3.5 MB. There is absolutely nothing in dub.json that links to anything else. Now, I've just created an empty test project with $ dub init size The executable is 940.5 kB Then $ dmd source/app.d -ofother The executable is 548.0 kB Try it yourself.
Re: [dub] Size of executable
On Thursday, 27 November 2014 at 09:33:49 UTC, Chris wrote: [Maybe this has been asked before.] I usually use dub to create and build projects. I built one of the projects with dub and then by hand with dmd[1] passing all the files etc. Turned out that the executable built with dub was 1.4 MB whereas the one built by hand was only 807 kB. Why is that? Another thing, I've spotted a typo in dub's[2] command line help: clean [package] Removes intermetiate build files and cached build results It should read intermediate (with d), else it sounds like the Goths in Asterix :-) [1] dmd 2.066.0 [2] DUB version 0.9.22, built on Sep 16 2014 Dub builds with debug symbols by default. Using dub build -v will tell you how it invokes DMD.
Re: Dynamic array head const in library code?
On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote: In D code it's a good idea to set as const/immutable (where possible) all variables that don't need to change, for both safety and compiler-enforced code documentation. In my D functions sometimes I create dynamic arrays that later don't have to change length nor to be reassigned, but I have to mutate or assign their items. Why you don't use static arrays for such a purpose? I thought this is exactly what they are made for, aren't they?
Re: Still not D standard yet ?
What is missing?
jsnode crypto createHmac createHash
Hi,
I translate some functionality written in jsnode,
which contains a crypto library.
Although there is some sha256 support in
phobos I think, they do not provide all functionality
I need to translate following two functions.
(Input and output is ubyte[])
Is there a library which supports the methods
similiar (createHmac, update)... ?
function hmac(key, msg) {
var hash = crypto.createHmac('sha256', key);
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
function sha256(msg) {
var hash = crypto.createHash('sha256');
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
Kind regards
André
Re: Dynamic array head const in library code?
Dominikus Dittes Scherkl: Why you don't use static arrays for such a purpose? I thought this is exactly what they are made for, aren't they? Currently you can't create a static array with a length known only at run-time. And passing around a fixed-size arrays has some costs. Bye, bearophile
Re: jsnode crypto createHmac createHash
V Fri, 28 Nov 2014 12:46:25 +
andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
napsáno:
Hi,
I translate some functionality written in jsnode,
which contains a crypto library.
Although there is some sha256 support in
phobos I think, they do not provide all functionality
I need to translate following two functions.
(Input and output is ubyte[])
Is there a library which supports the methods
similiar (createHmac, update)... ?
function hmac(key, msg) {
var hash = crypto.createHmac('sha256', key);
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
function sha256(msg) {
var hash = crypto.createHash('sha256');
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
Kind regards
André
I am using https://github.com/pszturmaj/phobos/tree/master/std/crypto
Re: Dynamic array head const in library code?
On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
don't have to change length nor to be reassigned, but I have to
mutate or assign their items. So their length and ptr can be
const/immutable, unlike the array contents. The D type system
doesn't allow this.
So is it a good idea to try to add to Phobos a headConst
function similar to this (only for built-in dynamic arrays)
that tries to enforce those constraints?
import std.traits, std.range;
struct HeadConst(T) {
T[] data;
alias data this;
@property size_t length() const pure nothrow @safe @nogc {
return data.length;
}
@disable void opAssign();
}
HeadConst!(ElementType!R) headConst(R)(R arr)
if (isDynamicArray!R) {
return typeof(return)(arr);
}
void main() {
import std.stdio;
auto arr = new int[2].headConst;
arr[1] = 10;
arr[1].writeln;
arr.length.writeln;
//arr.length = arr.length + 1; // error
auto b = new int[2];
//arr = b; // error
arr[] = b[];
b = arr;
arr[] = 1;
HeadConst!int c = arr;
HeadConst!int d;
arr = d; // fail
}
Bye,
bearophile
I wouldn't call it HeadConst, as that is a very general term.
A common situation for me is where I know the length at
compile-time, I want to make use of that knowledge (either in a
template somewhere or in hope of a compiler optimisation) but I
don't want the memory on the stack. That doesn't necessarily mean
I don't want to change the pointer though.
There's quite a lot of different possibilities that are useful, a
small set of utilities to help manage them would be great.
Re: jsnode crypto createHmac createHash
fantastic, thanks a lot.
Kind regards
André
On Friday, 28 November 2014 at 13:09:34 UTC, Daniel Kozák via
Digitalmars-d-learn wrote:
V Fri, 28 Nov 2014 12:46:25 +
andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
napsáno:
Hi,
I translate some functionality written in jsnode,
which contains a crypto library.
Although there is some sha256 support in
phobos I think, they do not provide all functionality
I need to translate following two functions.
(Input and output is ubyte[])
Is there a library which supports the methods
similiar (createHmac, update)... ?
function hmac(key, msg) {
var hash = crypto.createHmac('sha256', key);
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
function sha256(msg) {
var hash = crypto.createHash('sha256');
hash.update(msg);
return new Buffer(hash.digest(), 'binary');
}
Kind regards
André
I am using
https://github.com/pszturmaj/phobos/tree/master/std/crypto
Re: jsnode crypto createHmac createHash
Keep an eye on this one: Botan in D, https://github.com/etcimon/botan Should be finished in a couple weeks. e.g. from the TLS module: auto hmac = get_mac(HMAC(SHA-256)); hmac.set_key(secret_key); hmac.update_be(client_hello_bits.length); hmac.update(client_hello_bits); hmac.update_be(client_identity.length); hmac.update(client_identity); m_cookie = unlock(hmac.flush());
Re: Passing reference data to class and incapsulation
On Friday, 28 November 2014 at 08:31:26 UTC, bearophile wrote: Uranuz: Same situation happens when I assign reference data to properties. Someone has suggested to solve this problem with an attribute, like owned, that forbids to return mutable reference data owned by a class/struct instance. Bye, bearophuile Yes. Problem is even if you have property that controls correct assignment. If you have getter that returns mutable reference type and you try to access some fields of it or apply index operator (for arrays or AA) *host* cannot control corectness of these assignments or cannot react to these changes (in order to do some changes in model). The way I see is to create my own type of Array for this that can notify *host object* about changes so it could refresh the model or do some checks. Another way is to write interfaces in a way so we cant't escape uncontrolled references to mutable data. What do you think of it? Is there any patterns that could help to solve such problems? I think that writing your own type every time when you need to enforce consistency and safety is not very good))
Re: Passing reference data to class and incapsulation
Yes. Problem is even if you have property that controls correct assignment. If you have getter that returns mutable reference type and you try to access some fields of it or apply index operator (for arrays or AA) *host* cannot control corectness of these assignments or cannot react to these changes (in order to do some changes in model). The way I see is to create my own type of Array for this that can notify *host object* about changes so it could refresh the model or do some checks. Another way is to write interfaces in a way so we cant't escape uncontrolled references to mutable data. What do you think of it? Is there any patterns that could help to solve such problems? I think that writing your own type every time when you need to enforce consistency and safety is not very good)) In my opinion, this is an application design problem; not a language design problem. Getters break encapsulation: they expose an object's internal representation to client code. I tend to try and confine them to DTOs, which are generally immutable anyway. If you're worried about encapsulation, why not add a method to the object that modifies its own internal state?
Can't understand templates
Here is an example from the tutorial:
struct Point(T)
{
T x;
T y;
}
T getResponse(T)(string question) {
writef(%s (%s): , question, T.stringof);
T response;
readf( %s, response);
return response;
}
Point!T getResponse(T: Point!T)(string question) {
writefln(%s (Point!%s), question, T.stringof);
auto x = getResponse!T( x);
auto y = getResponse!T( y);
return Point!T(x, y);
}
void main()
{
auto pt = getResponse!(Point!int)(point);
}
I don't understand how to read this signature: Point!T
getResponse(T: Point!T)(string question). Clearly it's not
supposed to be saying that T is subclass of Point!T, so those Ts
must refer to different types. But when I rename it to
getResponse(U: Point!T) I get a compilation error (unknown
identifier T).
Another question: say I have a template class Pair:
class Pair(A, B) {
A a;
B b;
this(A a, B b) {this.a = a; this.b = b;}
}
How to write a specialization for getResponse matching Pair!(A,
B) with any type arguments A and B? I tried this:
T getResponse(T)(string question)
if (is(T: Pair!(A, B), A, B))
{
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
but get a compile error:
error: d.getResponse called with argument types (string) matches
both:
d.d(19): getResponse(T)(string question)
and:
d.d(40): getResponse(T)(string question) if (is(T : Pair!(A, B),
A, B))
Re: Can't understand templates
On Fri, Nov 28, 2014 at 07:32:38PM +, Sly via Digitalmars-d-learn wrote:
Here is an example from the tutorial:
[...]
Point!T getResponse(T: Point!T)(string question) {
writefln(%s (Point!%s), question, T.stringof);
auto x = getResponse!T( x);
auto y = getResponse!T( y);
return Point!T(x, y);
}
[...]
I don't understand how to read this signature: Point!T
getResponse(T: Point!T)(string question). Clearly it's not
supposed to be saying that T is subclass of Point!T, so those Ts
must refer to different types. But when I rename it to
getResponse(U: Point!T) I get a compilation error (unknown
identifier T).
This syntax is a little confusing, but basically the : there is saying
this type, when instantiated with the following pattern, produces a
valid type. Essentially it's equivalent to:
Point!T getResponse(T)(string question)
if (is(typeof(Point!T))) // i.e., Point!T is a valid type
{
...
}
Another question: say I have a template class Pair:
class Pair(A, B) {
A a;
B b;
this(A a, B b) {this.a = a; this.b = b;}
}
How to write a specialization for getResponse matching Pair!(A, B)
with any type arguments A and B? I tried this:
T getResponse(T)(string question)
if (is(T: Pair!(A, B), A, B))
{
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
but get a compile error:
error: d.getResponse called with argument types (string) matches
both:
d.d(19): getResponse(T)(string question)
and:
d.d(40): getResponse(T)(string question) if (is(T : Pair!(A, B),
A, B))
Yes, because D does not support overlapping template overloads. Both
the original overload of getResponse and the new overload matches the
given arguments, so it's an error. You need to explicitly restrict the
original overload so that it does *not* match in the case a Pair is
given. For example:
// Original overload
Point!T getResponse(T : Point!T)(string question)
if (!is(T : Pair!(A, B), A, B))
// ^^^ this says, match all T's for which Point!T is a
// valid type, but not when T is also an instantiation
// of Pair!(A,B).
{
...
}
// New overload
T getResponse(T)(string question)
if (is(T : Pair!(A, B), A, B))
{
...
}
T
--
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Why the DMD Backend?
Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? It seems to me that GCC and LLVM are far more developed and better supported by their respective communities. They have superior optimizers and are better equipped for migrating D to new platforms. On the other hand, from what I gather, there's lots of work to be done on DMD on improving support for x64 Windows and ARM. It's a genuine question, which is why I posted this to D.learn. I don't follow development on the backend and overall I'm unfamiliar with compilers, so I'm not sure what the benefits are of the D community continuing to maintain it's own backend.
Re: Why the DMD Backend?
On Fri, 28 Nov 2014 19:59:39 + Xinok via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? build time for the whole DMD compiler with standard library, using G++: 100 seconds. yea, no kidding. gdc: i don't even want to think about that, way t long. ldc: not that long as gcc, but still much longer than DMD. besides, for get ready to use compiler with DMD i need only installed c++ compiler binary. for gdc i need the whole gcc source tree. for ldc i need installed llvm with it's headers. DMD is good for fast write-compile-test cycles. and in most cases it's codegen is satisfying enough. last, but not least: rdmd is faster than rgdc. ;-) signature.asc Description: PGP signature
Re: Why the DMD Backend?
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? It seems to me that GCC and LLVM are far more developed and better supported by their respective communities. They have superior optimizers and are better equipped for migrating D to new platforms. On the other hand, from what I gather, there's lots of work to be done on DMD on improving support for x64 Windows and ARM. It's a genuine question, which is why I posted this to D.learn. I don't follow development on the backend and overall I'm unfamiliar with compilers, so I'm not sure what the benefits are of the D community continuing to maintain it's own backend. DDMD, bootstraping. LDC and GDC are not written in D.
Is someone still using or maintaining std.xml2 aka xmlp?
Old project link is http://www.dsource.org/projects/xmlp The launchpad and dsource repositories are dead for two years now. Anyone using it?
Re: Can't understand templates
On Friday, 28 November 2014 at 19:45:48 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
This syntax is a little confusing, but basically the : there
is saying
this type, when instantiated with the following pattern,
produces a
valid type. Essentially it's equivalent to:
Point!T getResponse(T)(string question)
if (is(typeof(Point!T))) // i.e., Point!T is a valid type
{
...
}
Is there a typo here? This version doesn't compile with the
original call: auto pt = getResponse!(Point!int)(point);
Yes, because D does not support overlapping template overloads.
But I thought the original example has ovelapping templates.
Let's take a simpler example from earlier in the tutorial, where
Point is a non-template struct:
// The general definition of the function template (same as
before)
T getResponse(T)(string question)
{
writef(%s (%s): , question, T.stringof);
T response;
readf( %s, response);
return response;
}
// The specialization of the function template for Point
T getResponse(T : Point)(string question)
{
writefln(%s (Point), question);
auto x = getResponse!int( x);
auto y = getResponse!int( y);
return Point(x, y);
}
auto center = getResponse!Point(Where is the center?);
Doesn't getResponse!Point match both declarations?
Re: thrift and dub
got it to work by using the thrift code from the fbthrift repo (minus the tests).
Re: Casting in Safe D
On Wednesday, November 26, 2014 16:27:53 David Held via Digitalmars-d-learn
wrote:
On 11/23/2014 3:12 PM, anonymous wrote:
[...]
And even pointer dereferencing is @safe. Invalid ones will fail
with a segfault at run time:
void foo(int* a) @safe {*a = 13;}
Hmm...throwing an exception is a well-defined behavior, but is
segfaulting a well-defined behavior of correct D programs? This seems
like a peculiar definition of safe to me...
@safe is about guaranteeing that memory will not be corrupted and that any
memory that's accessed has not been corrupted. Segfaults don't corrupt
memory and don't allow you to access corrupted memory. Rather, it's the OS
catching that your program has accessed memory that it shouldn't and then
essentially killing your program. The OS is _preventing_ any possible
memory corruption. So, as much as robust programs shouldn't segfault,
segfaults are perfectly safe with regards to memory - which is what @safe is
all about.
- Jonathan M Davis
Re: Can't understand templates
On 11/28/2014 12:36 PM, Sly wrote:
Let's take a simpler example from earlier in the tutorial, where
Point is a non-template struct:
// The general definition of the function template (same as
before)
T getResponse(T)(string question)
{
[...]
}
That definition would work with any type T. So, it is general: it
accepts any type.
// The specialization of the function template for Point
T getResponse(T : Point)(string question)
{
[...]
}
That definition is for T that matches Point (i.e. Point itself in this
example). So, it is special: it accepts only that type.
auto center = getResponse!Point(Where is the center?);
Doesn't getResponse!Point match both declarations?
True but the call is dispatched to the most special of all of the
matches. It is very briefly explained through a reference to C++:
The template picked to instantiate is the one that is most specialized
that fits the types of the TemplateArgumentList. Determine which is more
specialized is done the same way as the C++ partial ordering rules. If
the result is ambiguous, it is an error.
See the Specialization heading here:
http://dlang.org/template.html
Ali
Re: attribute length missing in std.array: Appender
On 11/28/2014 12:44 AM, bearophile wrote:
Now we have a better syntax for implicit casts:
[...]
app.put(ubyte(0).repeat.take(5));
Much better! :)
But I have a question too. What's the best way to append several lazy
items to a dynamic array? This doesn't work:
void main() {
import std.array, std.range;
int[] arr;
arr.put(only(1, 2, 3));
}
I don't think there is a better way in Phobos. (?) The following trivial
function would do as long as the array has room at the end, which
requires that it is safe to append:
void expandWith(A, R)(ref A arr, R range)
{
foreach (e; range) {
arr ~= e;
}
}
void main() {
import std.range;
int[] arr = [ 42 ];
// Ensure that there is room for new elements
arr.reserve(100);
assumeSafeAppend(arr);
const oldPlace = arr.ptr;
arr.expandWith(only(1, 2, 3));
const newPlace = arr.ptr;
assert(newPlace == oldPlace);
}
Ali
Re: attribute length missing in std.array: Appender
Ali Çehreli:
void expandWith(A, R)(ref A arr, R range)
{
foreach (e; range) {
arr ~= e;
}
}
I'd like a function like that in Phobos (with a little
improvement: when the length of the given range is available
inside expandWith, it should first extend the capacity to
increase performance a little). But I'd call it extend as in
Python.
Bye,
bearophile
Re: Still not D standard yet ?
On Friday, 28 November 2014 at 12:35:28 UTC, Kagamin wrote: What is missing? an ISO standard ?
Re: Still not D standard yet ?
On Saturday, November 29, 2014 01:30:55 Ledd via Digitalmars-d-learn wrote: On Friday, 28 November 2014 at 12:35:28 UTC, Kagamin wrote: What is missing? an ISO standard ? Someday, maybe, but most languages don't have an ISO standard, and I really on't see what it would buy us. What we're generally missing most is manpower. Putting a bunch of effort into formalizing it in a standard wouldn't really help us. If anything, it would just take away manpower from actually getting code written, getting bugs fixed, etc. And even if getting an ISO standard for D were a goal, C++ was something like 20 years old before it got an ISO standard, so even those languages that do have standards didn't generally get them very early in their development, meaning that we're not necessarily slow about getting a standard in comparison to those languages that do. - Jonathan M Davis
Re: Is someone still using or maintaining std.xml2 aka xmlp?
On 2014-11-28 15:15, Tobias Pankrath wrote: Old project link is http://www.dsource.org/projects/xmlp The launchpad and dsource repositories are dead for two years now. Anyone using it? Nope. I found kXML while searching for the same, it has everything I've needed up to spec. I'm maintaining a fork that works with DMD 2.066+ here: https://github.com/etcimon/kxml
Re: Can't understand templates
OK, so we *can* have overlapping templates in one fits better
than another, just like in C++. I still don't understand how to
read this signature:
Point!T getResponse(T: Point!T)(string question)
On Friday, 28 November 2014 at 23:59:07 UTC, Ali Çehreli wrote:
On 11/28/2014 12:36 PM, Sly wrote:
Let's take a simpler example from earlier in the tutorial,
where
Point is a non-template struct:
// The general definition of the function template (same as
before)
T getResponse(T)(string question)
{
[...]
}
That definition would work with any type T. So, it is general:
it accepts any type.
// The specialization of the function template for Point
T getResponse(T : Point)(string question)
{
[...]
}
That definition is for T that matches Point (i.e. Point itself
in this example). So, it is special: it accepts only that type.
auto center = getResponse!Point(Where is the center?);
Doesn't getResponse!Point match both declarations?
True but the call is dispatched to the most special of all of
the matches. It is very briefly explained through a reference
to C++:
The template picked to instantiate is the one that is most
specialized that fits the types of the TemplateArgumentList.
Determine which is more specialized is done the same way as the
C++ partial ordering rules. If the result is ambiguous, it is
an error.
See the Specialization heading here:
http://dlang.org/template.html
Ali
Why does hello world not compile in safe?
import std.stdio;
@safe:
void main()
{
writeln(Edit source/app.d to start your project.);
}
source/app.d(5): Error: safe function 'D main' cannot call system
function 'std.stdio.writeln!(string).writeln'
Re: Why does hello world not compile in safe?
'cause `writeln`() is not @safe, as you can read in the following compiler message: source/app.d(5): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln' signature.asc Description: PGP signature
