Namal:
Hello I am trying to convert BigInt to string like that while
trying to sort it:
void main() {
import std.stdio, std.algorithm, std.conv, std.bigint,
std.string;
auto n = 17.BigInt ^^ 179;
n.text.dup.representation.sort().release.assumeUTF.writeln;
}
Bye,
bearophile
void main() {
import std.stdio, std.algorithm, std.conv, std.bigint,
std.string;
auto n = 17.BigInt ^^ 179;
n.text.dup.representation.sort().release.assumeUTF.writeln;
}
Better:
n.to!(char[]).representation.sort().release.assumeUTF.writeln;
Bye,
bearophile
Yazan D:
On Saturday, 16 January 2016 at 14:42:27 UTC, Yazan D wrote:
ubyte[] b = (cast(ubyte*) &a)[0 .. int.sizeof];
Better to use the actual size:
ubyte[] b = (cast(ubyte*) &a)[0 .. a.sizeof];
Bye,
bearophile
Dibyendu Majumdar:
On Thursday, 21 January 2016 at 21:52:06 UTC, Dibyendu Majumdar
wrote:
How should this be translated to D? Will D's array access allow
data elements to be accessed beyond the size declared?
Take a look at the code I've written here:
http://rosettacode.org/wiki/Sokoban#Faste
FreeSlave:
On Thursday, 28 January 2016 at 08:15:38 UTC, FreeSlave wrote:
Not directly. You can declare cdecl function on Free Pascal
side and call it as extern(C).
What about extern(Pascal)?
https://dlang.org/spec/attribute.html#linkage
Bye,
bearophile
monarch_dodra:
Out of curiosity, if the requirement was to *also* preserve
ordering (eg: remove all non-first elements), how would you go
at it?
[2, 1, 1, 3, 2, 3] => [2, 1, 3];
Maybe std.algorithm's `makeIndex` would help here?
Bonus points for doing it inplace.
This preserves ordering a
matovitch:
struct Test
{
immutable (ubyte)[] data;
T get(T)()
{
return *(cast(T*)(&(data[0])));
}
It's better to return const/immutable data. Otherwise the program
gives undefined results. In alternative use mutable ubytes for
data.
Also &da
David Held:
class Baz
{
override string toString() pure const
{ return cast(Object)(foo).toString(); }
Foo foo;
}
This really makes the compiler go bonkers:
src\Bug.d(11): Error: pure nested function 'toString' cannot
access mutable data 'foo'
src\Bug.d(11): Error: pure nested fu
In this case I am not sure about bug reports, so I ask here.
In this program the first loop doesn't compile, giving a nice
error:
test.d(3,5): Error: index type 'ubyte' cannot cover index range
0..300
If you comment out the first loop, the second compiles and runs,
but it seems to go in an
For the second loop one possible alternative behavour is to
refuse a ubyte index and accept only a size_t index if it loops
on a dynamic array.
Another alternative is: the i variable can go from 0 to 255,
then go up to the modulus of the remaining indexes, and then
stop.
In this program the a
https://issues.dlang.org/show_bug.cgi?id=12611
Bye,
bearophile
Matthew Dudley:
Also, as an aside, why can't tuples be indexed dynamically?
Most of my problems with this have been because you apparently
can't.
Think about how D tuples are implemented, they are essentially
structs. Every tuple element can have a different type and to be
represented in me
Andre:
Nice to hear that it is not by design but will be fixed.
See:
https://issues.dlang.org/show_bug.cgi?id=3543
Bye,
bearophile
Casey:
My question is, is there a way I can prevent this conflict from
occurring without affecting what the struct will look like?
The usual strategy is to append an underscore. (I think C# uses a
@ prefix).
Bye,
bearophile
Casey:
I've done that, but then it changes the name which, from what
I've read in the documentation, means the JSON -> object
conversion won't work since it won't see a variable named
delete.
Perhaps we need a built-in syntax solution as in C#, like a
"$delete".
Bye,
bearophile
Charles McAnany:
this(int x){}
this(T)(T x) if(!is(T == int)){}
}
void main(){}
But this does not compile because the two constructors conflict:
Try adding the negative constraint:
this(T)(in T x) pure nothrow if(is(T == int)) {}
this(T)(in T x) pure nothrow if(!is(T == int)) {}
Bye
Walter Gray:
the files contain the entire definitions, so why would it be
necessary to link to them AND specify them as imports?
What am I missing here?
I don't understand why that's not regarded as a job for the
compiler. But in the standard D distribution there are programs
like rdmd that
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
Dicebot:
Why would you even expect those to be same types? These 2 types
are also different:
struct A
{
const int x;
}
alias A_ = const(A);
In general a tuple is a higher level data structure compared to a
struct. So it's not unreasonable to expect a Tuple to be more
flexible than a s
Dicebot:
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388
Nope, that's just an implementation detail. They are two quite
different data structures. Example: slicing a tuple always has a
meaning, while slicing a s
Dicebot:
std.typecons.Tuple is just a subset of all structs implementing
specific behavior. It still acts as struct everywhere when
applicable.
A subset is not the same as the whole set.
You are missing something important about what a data structure
is. Take a look at your computer science
I was just expressing a little frustration :-)
An example; despite it looks simple I am missing something:
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Dicebot:
It would be weird exception of general type system rules with
no practical justification I can readily imagine.
I partially disagree. It could be useful to have structural
typing (http://en.wikipedia.org/wiki/Structural_type_system )
only on tuples (and not on structs), because the
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Foo[] empty;
auto seed = tuple(empty);
reduce!foo(seed, data);
}
I have found a solution:
import
Meta:
I think it's a bad idea to make these equal for this reason: if
T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
assert(is(T1 == T2));
alias UnT1 = Unqual!T1; // Tuple!(int, int)
alias UnT2 = Unq
Justin Whear:
brad clawsie:
b = cast(ubyte[]) s;
Better to use std.string.representation.
It doesn't look like you're allocating space for `e` or `d`,
e.g. `auto e
= new ubyte[](256);`, so those arrays have a length of 0, in
which case
the encrypt/decrypt functions are just trashing
Dicebot:
For your objections to make sense tuple would need to be
inroduced as completely new first class type system entity. As
this will never happen,
I think first class tuples will happen in D, because the current
tuple situation is quite bad.
But this thread is not about built-in tupl
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
If you think this can be done and it's useful, then ask for this
enhancement requ
Lazy arguments in general allocate, but who is to blame for the
allocation?
Isn't the allocation at the calling point?
This code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives:
test.d(2,15): Error: @nogc function 'test.foo' cannot call
non-@nog
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
D doesn't like warnings, but it could be an error. This is
minimized code:
st
Dicebot:
It happens because attribute inference does not work properly
on generated delegated for lazy argument. I think it is a bug
"lazy int x" is effectively same as "int delegate() x" and
@nogc states that you can only call other @nogc functions and
delegates from something annotated as
spec:
I usually try to refrain myself from opinionating on stuff
where i lack proper knowledge and i'am still a newbie with D
(contrary to you bearophile).
It's not just a matter of experience, when there are many
interacting parts it's also a matter of intelligence (and people
like Timon a
Meta:
I'm trying to create a basic List type using Algebraic, but the
compiler keeps complaining about recursive aliasing.
As stated in its docs, Algebraic is not yet finished and good for
recursive data structures. But here I have put an usage example
of that kind:
http://rosettacode.org/
Meta:
alias List = Algebraic!(typeof(null), Cons!(int, This));
Also your Cons seems a value type, like Algebraic itself. You
have to avoid creating an infinite-size algebraic value.
Bye,
bearophile
Meta:
I should specify. This did not work:
alias T = Algebraic!(int, This*);
void main() {
auto l = T(1, new T(2, new T(3, null)));
}
An Algebraic is a sum type, so you can't store two value in it,
only one, an int or a T*. But this is not going to solve your
problems...
Bye,
bea
Meta:
The more I try to use Algebraic, the more I come to think that
this is something that can't be done cleanly in a library, even
in D.
Algebraic is currently unfinished and needs improvements. If it
turns out it's not possible to implement it well in library code,
we can find the minima
If no one comment I'll put this in Bugzilla.
https://issues.dlang.org/show_bug.cgi?id=12667
Bye,
bearophile
Andrey:
Could anyone please explain to me, why do I have error message
on this piece of code?
In this thread you are doing some mistakes. This code seems OK:
alias TData = short;
alias TArray = TData[100];
struct MyStruct {
TArray* arrPtr;
}
void main() {
MyStruct* t3 = new MyStruct
Chris:
I need an array that contains pointers to types created via
template. To stick to my usual example:
Person!(string)
How can I make an array with pointers to concrete "instances"
of Person!(string)?
Every template creates a new type, so you can't put them as they
are in an array. Th
Chris:
So there is no way of filling an array with something like
Person!(string) *pptr;
foreach(person; people) {
buf ~= &person;
}
So you want an array filled with instances of the same
instantiation, sorry, I misunderstood your problem for a more
complex one :-)
Bye,
bearophile
Andrey:
alias short Type1;
The "alias X Y;" syntax is going to be deprecated, so use "alias
Y = X;" if your compiler already supports it.
alias Type1[100]* Type2; // if I take out '*' I will have to
type it everywhere, because arrays in D2 always 'by value'
Adding the * everywhere could
ketmar:
so it's broken beyond any repair. so sad.
The current implementation of the module system has some
problems, that are being worked on. If you think some part of the
module system design is not good enough, then try to ask for an
enhancement :-) No need to be sad.
Bye,
bearophile
Artur Skawina:
The D module system has a lot of problems and certainly needs
to be completely redesigned from scratch,
I don't think it will be redesigned from scratch (and if that
happens I see no proof that the redesign will be better than the
original design). So better to fix its major p
ketmar:
ah, i can't clearly express myself even in this case, i don't
think i can make clear request. it's easier to write code, not
words. ;-)
i'm sad not about D or module issues, i'm sad about myself.
One of the most important skills of a programmer (and of course a
technical/literary w
ketmar:
the thing is that English neither my native language
Nor mine, as you can see :-) And I am bad with natural languages
in general. But you can learn to write "acceptable" English if
you do exercises for some years :-)
Bye,
bearophile
brad clawsie:
auto digest = HMAC(EVP_sha1(),
cast(void *) key,
Better to attach the * to void.
cast(int) key.length,
cast(ubyte*) s,
Here you are casting a struct of pointer to immutable plus length
to a mut
Jonathan M Davis:
If you want it to be guaranteed, you'd do something like
template foo(string s)
{
enum foo = s ~ " betty";
}
A more general solution is to wrap the concatenation with a call
to:
alias ctEval(alias expr) = expr;
Use:
string bar() { return ctEval!(s ~ " betty"); }
By
Nordlöw:
How can I make `join` variadic (by filling in njoin) in the
following code?
When you have a D tuple (not Phobos tuple), and it contains
values all of the same type, you can turn it into an array with
just:
[mytuple]
Once you have an array of strings, you can use the normal phobos
Mark Isaacson:
Accordingly, I no longer need an answer to my second question
unless someone knows of a more idiomatic way to get the same
results.
Is the "alias this" useful in this case?
Bye,
bearophile
monarch_dodra:
As rule of thumb, you can't allocate during a GC cleaning
cycles, and class destructors are usually called during a GC
cleaning cycle.
This means it is usually unsafe to call *anything* that could
potentially allocate in a destructor.
So it could be a good idea to have @nogc
Jonathan M Davis:
Andrei suggested auto ref to fix this problem, and Walter
implemented it, but he misunderstood what Andrei had meant,
I missed this detail of the story :-)
Walter has suggested that we just redefine ref itself to do
what I just
described rather than using auto ref or defin
Alex:
Why the compiler does not complain or,
I've just asked something related to this in the main D
newsgroup, take a look there for answers. Today D has means to
complain statically.
But I don't know the fate of D class destructors.
Bye,
bearophile
Mark Isaacson:
2) Create a wrapper struct that contains key and value and
whose comparison operator is defined only on the key. This
would essentially be doing what the C++ implementation does.
Until we have a tree-based associative map, use a tuple for the
key-value and define a "less" temp
Mark Isaacson:
Got it, no native support. Most unfortunate.
What native support are you talking about?
I've always been vehemently against losing self-documentation
via the std::pair/tuple based solution to the problem.
What self documentation are you losing in D?
I ended up rolling my
Dicebot:
What benefits this gives over definining distinct struct?
Sounds like unnecessary complication for me.
See the code in my precedent post, what do you think about it?
Bye,
bearophile
Andrey:
A similar D code is, as far as I know,
type.field.offsetof
Yes, it's a built-in feature of D.
Is there an any way to make a corresponding D template?
I don't understand. Please explain better.
Bye,
bearophile
Chris Piker:
Is there any way to get a list of the properties and functions
provided by a module or class or generic variable in D at
runtime?
In D there are various traits to do that a compile-time. Like:
http://dlang.org/traits.html#allMembers
There are also the Phobos traits:
http://dlang
Andrej Mitrovic:
I can do this:
struct Foo(T) { }
template bar(T : Foo!int) { }
I can check if T is a specific instantiation of Foo. But I want
to
check whether T is *any* instantiation of Foo. Is this possible
to do?
There is now std.traits.isInstanceOf that could do what you need.
Its i
Mark Isaacson:
I'm trying my hand at reading from standard input and having
little luck. In particular, I would like to be able to do the
rough equivalent of C++'s:
cin >> myString;
There isn't always a 1:1 mapping between C++ and D. In D if you
want a single word you usually read the whol
Mark Isaacson:
Fair enough. I've done stuff like that in the past. I'm trying
to implement a university project that was originally designed
for C++ style I/O... and so where I'd have otherwise jumped at
something like that from the beginning, my hands are slightly
tied.
If you need/want to
Mark Isaacson:
Indeed. However, doing so looks more painful than redefining my
goals. Upon further examination it seems that I had more
flexibility than I originally estimated. Besides, the real
reason I'm implementing this project is just to practice for
when I get to write production D code
Is it a good idea to add a function like this to Phobos?
This is just a first draft of the idea.
void main() {
import std.stdio, std.algorithm, std.range, range_matcher;
auto primes = iota(2, uint.max)
.filter!(x => iota(2, x)
.all!(t =
Artur Skawina:
Keep in mind that D's offsetof is flawed - if the object does
not contain the requested member, but implicitly converts to
another one that does have such field then the expression
compiles, but yields a bogus value. Eg
struct S { int a, b, c; S2 s2; alias s2 this; }
stru
Artur Skawina:
And, I have no idea if the, hmm, /unconventional/ D offsetof
semantics
are in the bugzilla. It's not really a "bug", but a design
mistake...
Design mistakes are valid bugzilla entries. At worst the bad
behavior could be documented. But often it's possible to fix the
design to
H. S. Teoh:
Exercise for the reader: spot the bug.
https://issues.dlang.org/show_bug.cgi?id=5212
https://issues.dlang.org/show_bug.cgi?id=11657
Bye,
bearophile
So far in Rosettacode D entries I've kept a line length limit of
72 or 73 chars.
But now a little larger monitors are common, D UFCS chains are
common, and we also have longer function signatures with "pure
nothrow @safe @nogc" (that usually I put on a new line), so
keeping that line length l
Nick Sabalausky:
72-73 chars would indeed be a pain. In my own code I like to
use a soft limit of 80, FWIW.
This is not regular code, it's an online wiki. The situation is a
little different. But I think 80 is now acceptable.
Bye,
bearophile
Yuriy:
Hello, is there a way of reducing size of an empty class to
just vtbl? I tried to declare it as extern(C++) which works,
but has a nasty side effect of limited mangling.
extern(C++) classes is only for interfacing with C++ code. It's
not to write regular D code.
Bye,
bearophile
Jonathan M Davis:
ultimately, this sort of
thing pretty much always ends up being highly subjective.
But please put the const/immutable of methods on the right:
struct Foo {
void bar1() const {} // Good
const void bar2() {} // Bad
}
Bye,
bearophile
Artur Skawina:
But I have no idea why anybody would want to wrap this trivial
expression like that.
And, I have no idea if the, hmm, /unconventional/ D offsetof
semantics
are in the bugzilla. It's not really a "bug", but a design
mistake...
https://issues.dlang.org/show_bug.cgi?id=12714
By
Jonathan M Davis:
Unfortunately, making this consistent by doing something like
enforcing that
all function attributes go on the right would then be
inconsistent with other
languages with regards to the attributes that they have which
go on the left,
This is a job for a Lint. like DScanner :
amehat:
What is the proper behavior for this D?
D doesn't have that Java syntax, because it was widely regarded
as a Java design mistake. So in D omit the throws part. If your
function tree doesn't throw exceptions (but it can throw errors)
add a "nothrow".
Bye,
bearophile
Jonathan M Davis:
I still think that allowing const on the left is simply a
bad design decision.
I opened a request on this, and it was closed down :-)
Bye,
bearophile
H. S. Teoh:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
Yuriy:
But. Why are you protecting __monitors so eagerly? :)
Also take a look at the Rust language, that avoids some of your
problems :-)
Bye,
bearophile
Yuriy:
but I like D, and i strongly believe it's the next big language.
Oh, good. Do you want to briefly explain why? :)
Bye,
bearophile
monarch_dodra:
As a matter of fact, the built in "sort" property does it.
It's going to be deprecated "soon".
Bye,
bearophile
Chris:
Is there any huge difference as regards performance and memory
footprint between the two? Or is 2. basically 1. under the hood?
An associative array is a rather more complex data structure, so
if you don't need it, use something simpler. There is difference
in both the amount of memor
Chris:
Do you mean the difference is negligible in many cases?
Yes, but you have to profile the code (or reason about it well,
with knowledge of the data structures and their usage patterns)
if you want to know what your case is.
Bye,
bearophile
Chris:
foreach (size_t i; 0..myArray.length) {
// do something with myArray[i];
}
There are various better ways to use a foreach on an array:
foreach (immutable x; myArray) {
foreach (ref const x; myArray) {
foreach (ref x; myArray) {
Bye,
bearophile
Damian Day:
Benchmark found here:
http://dpaste.dzfl.pl/0058fc8341830
Perhaps it's a problem of missed dmd inlining. So I suggest to
run the benchmark with ldc2.
Bye,
bearophile
This task asks for an basic implementation of the the
Lempel-Ziv-Welch (LZW) compression/decompression algorithm. I am
keeping two D versions, the first one is minimal, and the second
is a little more optimized:
http://rosettacode.org/wiki/LZW_compression#More_Refined_Version
There are of cour
Ali Çehreli:
I don't think that should even be allowed. C functions should
not know or be compatible with 'ref' D parameters. Define the
arguments as simple 'double *' or 'const double *'.
Time ago I suggested something like that, that is not meaningful
to accept extern(C) function signature
John Colvin:
Any plans to get any preprocessor stuff working?
Do you mean in D?
Bye,
bearophile
There are of course ways to implement a really efficient ZLW
compressor in D, and such implementation could be added as
third D entry if it manages to be not too much long,
Third version added:
http://rosettacode.org/wiki/LZW_compression#More_Efficient_Version
I have tried to make it idiomatic
Artur Skawina:
So how does it perform wrt the D version that I wrote for
you last time? [1]
[1]
http://forum.dlang.org/post/mailman.2132.1353592965.5162.digitalmar...@puremagic.com)
From your answer:
First, the code above is practically a textbook example on how
/not/ to
write readable and
Artur Skawina:
Ugh. So how does it perform wrt the D version that I wrote for
you last time? [1]
I have done a benchmark with the various version (the first 3 are
the ones on the Rosettacode site, and the #4 is yours):
lzw1: 0.39
lzw2: 0.17
lzw3: 0.21
lzw4: 0.17
I think your comment was ab
monarch_dodra:
Arguably, your code allocates a lot.
What version (1-2-3) do you mean?
I'll give it a shot (next week).
I think the LZW entries are OK :) So if you want to work on
Rosettacode it's better to write an entry that is missing in D.
Bye,
bearophile
Meta:
You need to use the function array from std.array.
import std.array;
int[] source = [ ... ];
int[] sample = randomSample(source, 3).array();
In some cases it's also useful to use std.algorithm.copy:
void main() {
import std.stdio, std.algorithm, std.random, std.array,
Steffen Wenz:
Just noticed that using UFCS does not work for nested functions,
Right.
and was wondering whether that's intended, and what the
rationale behind it is:
Currently it's intended. Because doing otherwise causes other
problems with struct/class member functions. Perhaps there a
Tim:
is there any chance to modify a char in a string like:
void main()
{
string sMyText = "Replace the last char_";
sMyText[$ - 1] = '.';
}
But when I execute the code above I'm always getting "cannot
modify immutable expression at sMyText[__dollar -1LU]". I
though D supported such mo
Darren:
Let's say I have a hex representation of a large number:
String hexnum = "16D81B16E091F31BEF";
I'd like to convert it into a ubyte[]
A simple way is to use hex strings and then cast it to
immutable(ubyte)[]:
void main() {
immutable hexNum =
cast(immutable(ubyte)[])x"16D81B16E
Andrew Brown:
I would like to write a double to a text file as hexadecimal
and then read it back in without losing information.
Is this good enough for you?
void main() {
import std.stdio, std.math;
auto fout = File("ouput.txt", "w");
fout.writef("%a", PI);
fout.close;
a
Alexandr Druzhinin:
In D code I do
void* data = GC.malloc(...);
if(data is null)
...
In C code I do
void* data = malloc(...);
if(data == null)
...
What to do when in D code I have
void* data = std.c.stdlib.malloc(...);
if(data ?) // is null vs == 0
"x is null" or "x == null"
Adam D. Ruppe:
but I prefer "is null" because that is most consistent with
other D code (where there might be a difference between the
two).
Curiously I do the opposite, I use == to remind me it's a pointer
:-)
Bye,
bearophile
Stefan Frijters:
Is this by design? It was very surprising to me, especially
since all other combinations do seem to work.
I don't know if this situation is by design. At first sights it
seems a limitation that could be removed.
Bye,
bearophile
Nicholas Londey:
So I tried rewriting the example on the dlang.org home page and
came up with the following.
import std.algorithm, std.exception, std.stdio;
double average(T)(T range)
{
enforce(!range.empty, "No inputs");
auto totals = range.map!(a => tuple(1.0,
cast(double)(a))).reduce
Chris:
The following:
import std.stdio;
void main() {
int[5] arg;
arg[10] = 3; // Compiler says (of course):
Error: array index 10 is out of bounds arg[0 .. 5]
}
import std.stdio;
void main() {
int[5] arg;
foreach (i; 0..10) {
arg[i] = i;
}
}
Compiler says nothi
I don't know if this is a bug, an enhancement request, or just a
mistake of mine. I don't understand why currently @nogc refuses
this code:
import std.algorithm: filter;
struct Foo {
bool bar(in int) @nogc {
return true;
}
auto spam() @nogc {
immutable static data =
maarten van damme:
writeln(providor_symbol_map.keys.sort!((x,y)=>providor_symbol_map[x].length>=providor_symbol_map[y].length));
[/code]
Try:
((x, y) => providor_symbol_map[x].length >
providor_symbol_map[y].length)
Bye,
bearophile
1 - 100 of 544 matches
Mail list logo
