Re: DMD Callstacks
On Monday, 23 October 2017 at 12:41:09 UTC, Márcio Martins wrote: What is everyone doing to get proper file name and line number info for callstacks with DMD? addr2line just gives me ??:0 You could try compiling with the -debug-switch. Of course if this turns out to be the fix, it doesn't help with std code.
Re: Why is this legal?
On Wednesday, 29 March 2017 at 11:06:55 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 29 March 2017 at 10:12:08 UTC, abad wrote: On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote: Related question, it seems that final methods are allowed in interfaces. Obviously you can't implement them anywhere, so is this also on purpose and on what rationale? :) So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall. The idea between `final` functions in interfaces is to provide a default non-overridable implementation. For example: Yes, does make sense. I was looking this from Java 7 perspective where interfaces can't implement any methods.
Re: Why is this legal?
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote: Related question, it seems that final methods are allowed in interfaces. Obviously you can't implement them anywhere, so is this also on purpose and on what rationale? :) So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall.
Re: Why is this legal?
Related question, it seems that final methods are allowed in interfaces. Obviously you can't implement them anywhere, so is this also on purpose and on what rationale? :)
Re: Why is this legal?
Never mind, it's working OK if the class is defined in another module.
Why is this legal?
This works:
class Foo {
protected void bar() {
writeln("hello from foo");
}
}
void main() {
auto foo = new Foo;
foo.bar();
}
Is this on purpose and what's the rationale?
Re: understanding std.algorithm.mutation.fill behaivor.
On Wednesday, 28 December 2016 at 08:10:41 UTC, Nemanja Boric
wrote:
On Wednesday, 28 December 2016 at 05:09:34 UTC, LeqxLeqx wrote:
Perhaps this is a stupid question, and I apologize if it is,
but why doesn't this compile:
import std.algorithm;
import std.stdio;
void main()
{
char[] array = [1, 2, 3, 4];
char value = 2;
fill(array, value);
}
if this does:
import std.algorithm;
import std.stdio;
void main()
{
int[] array = [1, 2, 3, 4];
int value = 2;
fill(array, value);
}
when the only difference is the type, and the 'fill' method is
meant to be generic?
Thanks for your time.
So I don't repeat excellent answer:
http://stackoverflow.com/a/6401889/133707
So in short, unlike in C/C++ world, you should only use char to
store actual text, not data as would be common in C/C++. byte &
ubyte are for that.
Re: std.array : appender woes
On Thursday, 16 June 2016 at 07:59:50 UTC, cym13 wrote:
On Thursday, 16 June 2016 at 07:47:03 UTC, abad wrote:
import std.array : appender;
import std.stdio : writeln;
void main() {
auto app = appender!(char[]);
app.put('x');
auto foo = app.data;
app.clear; // done, start a new array
app.put('y');
writeln(foo);
}
This prints out 'y'. It's not surprising because what I
suppose app.data is doing is just returning a slice of the
dynamic array. Clear() resets the counter of current position.
But this behavior is confusing in practical use, IMHO.
Should calling clear in your opinion guarantee that a new
array gets allocated?
I don't find it confusing at all, what did you expect?
Consider the word clear in this context. What is it that gets
cleared? The data in the array (which might imply reallocation)?
Nope, what gets "cleared" is the index to current position in the
array. I think 'reset' may have been a better name for the
function.
std.array : appender woes
import std.array : appender;
import std.stdio : writeln;
void main() {
auto app = appender!(char[]);
app.put('x');
auto foo = app.data;
app.clear; // done, start a new array
app.put('y');
writeln(foo);
}
This prints out 'y'. It's not surprising because what I suppose
app.data is doing is just returning a slice of the dynamic array.
Clear() resets the counter of current position. But this behavior
is confusing in practical use, IMHO.
Should calling clear in your opinion guarantee that a new array
gets allocated?
Re: Calling C++ code with pointer** argument
On Wednesday, 1 June 2016 at 07:17:04 UTC, Mike Parker wrote: On Wednesday, 1 June 2016 at 07:09:16 UTC, abad wrote: Try this: extern(C++) void DoesNotLink(const(char)**); That does work, though I have to explicitly cast it in my caller as well. Like this: doesNotLink(cast(const(char)**)baz2); It's a bit troublesome as my code will include quite a lot of calls like this. Casting is not necessary with the method call with the single pointer argument, as it seems to get const'ed automatically. And I don't know if this was just a typo in your post, but also note that you 'D'oesNotLink in the CPP source you pasted and 'd'oesNotLink in the D code. That was just a typo.
Calling C++ code with pointer** argument
D source:
extern(C++) void thisWorks(const char* test);
extern(C++) void doesNotLink(const char** test);
void main() {
char* baz1;
char** baz2;
thisWorks(baz1);
doesNotLink(baz2);
}
CPP source:
#include
void thisWorks(const char* test) {
printf("hi\n");
}
void DoesNotLink(const char** test) {
// not reached
}
The error given by the linker:
test.d:(.text._Dmain+0x21): undefined reference to
`doesNotLink(char const* const*)'
What's happening? I know there are differences in const behavior
between D and C++, but can't figure a way around it. Any sort of
casting trick I tried doesn't seem to help.
DUB and static libs
I have a project which is a mixture of D, C++ and C. I have used
Make for build automation so far but would like to migrate to DUB.
I have hard time figuring out what to do with C / C++ sections of
the program. DUB seems to ignore (probably sensibly) everything
but D source files. I compiled a static library of the non-D
sections of my program, and now I'd need to tell DUB to include
the library in the linking stage.
I tried to use "linkerFiles" argument in dub.json but that
doesn't seem to do anything.
Here's the full dub.json:
{
"name": "audio_test",
"description": "audio test.",
"copyright": "",
"authors": [""],
"dependencies": {
"derelict-imgui": {"version":"~master", "path":
"./DerelictImgui/"},
"derelict-glfw3": "~>1.1.0",
"derelict-gl3": "~>1.0.12",
"derelict-sdl2": "~>1.9.7",
},
"libs": [ "stdc++" ],
"stringImportPaths": [
"res"
],
"linkerFiles": [
"sid.a"
]
}
sid.a is the library in question.
Any ideas?
Re: Collapsing n-dimensional array to linear (1 dimensional)
On Monday, 25 January 2016 at 02:27:57 UTC, Solomon E wrote:
On Saturday, 23 January 2016 at 07:57:55 UTC, Ali Çehreli wrote:
auto collapse(R)(R r)
if (isArray!R) {
return r.joiner.collapse.joiner;
}
auto collapse(R)(R r)
if (!isArray!R) {
return r;
}
Ali, that code only passed the one test it had for collapsing a
three level array. It wouldn't collapse arrays of other numbers
of levels. It wasn't recursing as appeared to be intended.
Is the following code better D? (I don't know because I'm still
learning D, so I'd like to be corrected if the comments in my
code are inaccurate or misleading.)
(See https://issues.dlang.org/show_bug.cgi?id=12062 for where I
got the idea that `flatten` should be defined to mutate by
reference. A comment there suggests to use
std.experimental.ndslice and byElement for that, but ndlslice
doesn't seem to be in the library anymore.)
I will give this a try later.
Ruby's Array class includes this sort method for flattening and
for me it was surprisingly useful, for instance when it was
necessary to write the array to file.
I will also take a look at ndslice and see how intuitive its
approach for achieving this would be.
Collapsing n-dimensional array to linear (1 dimensional)
Let's say I have an array like this: int[][][] array; And I want to generate a linear int[] based on its data. Is there a standard library method for achieving this, or must I iterate over the array manually? What I'm thinking of is something like this: int[] onedim = std.array.collapse(array);
Re: Operator overloading - operations on slices
On Thursday, 21 January 2016 at 11:15:22 UTC, abad wrote:
I am trying to create a generic interface to arrays. Most
operations except those on elements of slices.
Code:
class Table(T) {
T[] data;
this(T[] data) {
this.data = data;
}
auto ref opSlice(size_t x, size_t y) {
return new Table!(T)(data[x .. y]);
}
void opIndexAssign(T value) {
data[] = value;
}
void opIndexAssign(T value, size_t idx) {
data[idx] = value;
}
void opAssign(T value) {
opIndexAssign(value);
}
auto ref opIndexOpAssign(string op)(T value, size_t
idx) {
return mixin("data[idx] " ~ op ~ "= value");
}
}
int main(string[] args) {
int[] data = new int[256];
auto t = new Table!int(data);
t[] = -1; // OK
t[1 .. 3] = 5; // OK
t[0] = 6; // OK
t[4] += 7; // OK
t[4..6] += 7; // FAIL, does not compile
}
Am I missing some specific overload or is this just not
possible?
I got it to work by adding this:
auto ref opSliceOpAssign(string op, this X, V, B, E)(auto ref V
v, auto ref B b, auto ref E e) { return mixin("data[b..e] "~op~"=
v"); }
What could perhaps be improved are compiler error messages. DMD
output:
Error: t.opSlice(4LU, 6LU) is not an lvalue
This does not really tell clearly what is going on.
Operator overloading - operations on slices
I am trying to create a generic interface to arrays. Most
operations except those on elements of slices.
Code:
class Table(T) {
T[] data;
this(T[] data) {
this.data = data;
}
auto ref opSlice(size_t x, size_t y) {
return new Table!(T)(data[x .. y]);
}
void opIndexAssign(T value) {
data[] = value;
}
void opIndexAssign(T value, size_t idx) {
data[idx] = value;
}
void opAssign(T value) {
opIndexAssign(value);
}
auto ref opIndexOpAssign(string op)(T value, size_t idx) {
return mixin("data[idx] " ~ op ~ "= value");
}
}
int main(string[] args) {
int[] data = new int[256];
auto t = new Table!int(data);
t[] = -1; // OK
t[1 .. 3] = 5; // OK
t[0] = 6; // OK
t[4] += 7; // OK
t[4..6] += 7; // FAIL, does not compile
}
Am I missing some specific overload or is this just not possible?
