Re: on structs by reference
On 11/14/2015 07:53 AM, Alex wrote:
> 3. The only point I stumble on is, that the main feature in my program
> is, that the underlying array, to which my slices refer to never
> changes. So, I'm going to have more and more slices, which are going to
> be smaller and smaller and each points to the same underlying array
> without overlapping, but at each step, there are as much copies of a
> single slice as elements it points to. I hope this last point was not
> too weird.
Your struct objects must keep a reference to the slice that they use
(i.e. one ore level of indirection).
Here is a start:
import std.stdio;
/* This is the storage to the slices that objects will share.
*
* (Surprisingly, creating a slice dynamically is not possible due
* to syntax issues: new int[N] means "allocates N ints and make
* a slice from those." However, we need a dynamic slice object
* here. I've decided to put the slices in a 'slice slice' here.)
*/
int[][] slices;
struct S
{
size_t idx;
ref int[] arr()
{
return slices[idx];
}
}
void main()
{
S s; // = new S();
slices ~= [1,2,3];
s.idx = slices.length - 1;
writeln(s.arr); //first
S t; // = new S();
t = s;
writeln(t.arr); //second
s.arr ~= 4;
writeln(s.arr); //third
writeln(t.arr);
}
[1, 2, 3]
[1, 2, 3]
[1, 2, 3, 4]
[1, 2, 3, 4]
Ali
Re: Any D IDE on Mac OSX with debugging support?
On 16/11/15 7:45 PM, Vadim Lopatin wrote: Hello, Is there any IDE which allows debugging D apps on OSX? I'm trying Mono-D, but getting error "Debugger operation failed A syntax error in expression, near 'sizeof(void*)'" GDB is installed using homebrew. Probably, something is wrong with my gdb. When I'm trying to start debugging using console GDB interface - it fails with message about unsigned application. Is there any instruction how to get GDB working on OSX? Code completion and symbol lookups neither do not work on Mono-D / OSX. Does anyone managed to get it working? Best regards, Vadim On recent versions of OSX, Apple has by default made it so that all applications must be signed by default. You can disable this behavior through system settings and security. I suspect this is what is stopping it. https://answers.uchicago.edu/25481
Any D IDE on Mac OSX with debugging support?
Hello, Is there any IDE which allows debugging D apps on OSX? I'm trying Mono-D, but getting error "Debugger operation failed A syntax error in expression, near 'sizeof(void*)'" GDB is installed using homebrew. Probably, something is wrong with my gdb. When I'm trying to start debugging using console GDB interface - it fails with message about unsigned application. Is there any instruction how to get GDB working on OSX? Code completion and symbol lookups neither do not work on Mono-D / OSX. Does anyone managed to get it working? Best regards, Vadim
Re: What does the -betterC switch in dmd do?
On Sunday, 15 November 2015 at 15:34:19 UTC, Jacob Carlborg wrote: I'm pretty sure that the only things that are excluded are module info and type info. It's still possible to use "new" and all the array features that requires support in the runtime (slicing, concatenation, appending and so on). Don't those features require type info?
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 18:12:52 UTC, David Nadlinger wrote: On Sunday, 15 November 2015 at 18:02:01 UTC, David Nies wrote: How do I mark it as such? Can you please give an example? Thanks for the quick reply! :) Just add extern(C) to the beginning of the "alias" line. — David Great! Thanks to all of you! That was really quick and helpful!
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 18:02:01 UTC, David Nies wrote: How do I mark it as such? Can you please give an example? Thanks for the quick reply! :) Just add extern(C) to the beginning of the "alias" line. — David
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 18:02:01 UTC, David Nies wrote: On Sunday, 15 November 2015 at 18:00:09 UTC, David Nadlinger wrote: On Sunday, 15 November 2015 at 17:54:27 UTC, David Nies wrote: How can I make sure the order is correct? Whenever you use a C function, it must be marked as, even if it's through a function pointer as in this case. Just apply the attribute to the dll2_fn and dll3_fn declarations. Hope this helps, David How do I mark it as such? Can you please give an example? Thanks for the quick reply! :) I think he refers to this: http://dlang.org/interfaceToC.html
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 18:00:09 UTC, David Nadlinger wrote: On Sunday, 15 November 2015 at 17:54:27 UTC, David Nies wrote: How can I make sure the order is correct? Whenever you use a C function, it must be marked as, even if it's through a function pointer as in this case. Just apply the attribute to the dll2_fn and dll3_fn declarations. Hope this helps, David How do I mark it as such? Can you please give an example? Thanks for the quick reply! :)
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 17:54:27 UTC, David Nies wrote: How can I make sure the order is correct? Whenever you use a C function, it must be marked as, even if it's through a function pointer as in this case. Just apply the attribute to the dll2_fn and dll3_fn declarations. Hope this helps, David
My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
Apparantly, the order in which parameters are passed to a
dynamically loaded C function is reversed. See the following
minimal example:
%> cat dll.c
#include "stdio.h"
int dll2(const char* first, const char* second) {
printf("dll2() - first: '%s', second: '%s'\n", first, second);
return 0;
}
int dll3(const char* first, const char* second, const char*
third) {
printf("dll3() - first: '%s', second: '%s', third: '%s'\n",
first,
second,
third);
return 0;
}
I compiled it with the following commands:
%> gcc -c dll.c -fpic
%> gcc -shared -o libdll.dyld dll.o
%> file libdll.dyld
libdll.dyld: Mach-O 64-bit dynamically linked shared library
x86_64
Now, I'm using it with a very simple D program and see very
unexpected results:
%> cat main.d
import std.stdio, std.string, core.sys.posix.dlfcn;
// extern functions
alias nothrow int function(const char*, const char*) dll2_fn;
alias nothrow int function(const char*, const char*, const char*)
dll3_fn;
void main() {
string sdlLibPath = "libdll.dyld";
auto libraryHandle = dlopen(sdlLibPath.toStringz(),
RTLD_LAZY);
scope(exit) dlclose(libraryHandle);
dll2_fn dll2 = cast(dll2_fn)dlsym(libraryHandle, "dll2");
dll2("one", "two");
dll3_fn dll3 = cast(dll3_fn)dlsym(libraryHandle, "dll3");
dll3("one", "two", "three");
}
%> rdmd main.d
dll2() - first: 'two', second: 'one'
dll3() - first: 'three', second: 'two', third: 'one'
The order in which the C functions get the parameters is exactly
the reverse order in which I supply them in D.
What is happening there? I also tried to export a function that
has two different types from the C library. Calling it the same
way from the client D program causes a segfault - which I'd
expect when the parameters are really reversed.
How can I make sure the order is correct?
Re: What does the -betterC switch in dmd do?
On 2015-11-12 23:24, Justin Whear wrote: I believe the purpose of the switch is to help folks who are trying to write for bare or embedded systems by not emitting references to the D runtime library and runtime module information. Whether it actually does that in its current implementation is another question. I'm pretty sure that the only things that are excluded are module info and type info. It's still possible to use "new" and all the array features that requires support in the runtime (slicing, concatenation, appending and so on). -- /Jacob Carlborg
Re: emplace, immutable members and undefined behaviour
On Sunday, 15 November 2015 at 11:12:02 UTC, Tobias Pankrath wrote: On Sunday, 15 November 2015 at 10:59:43 UTC, Tobias Pankrath wrote: Point* p = (allocate memory from somewhere); emplace!Point(p, 1, 2); immutable(Point)* immutableP = cast(immutable(Point)*) p; You could also use the emplace version that takes untyped memory: http://dlang.org/phobos/std_conv.html#.emplace The last one. Missed that one... Thanks!
Re: emplace, immutable members and undefined behaviour
On Sunday, 15 November 2015 at 10:59:43 UTC, Tobias Pankrath wrote: Point* p = (allocate memory from somewhere); emplace!Point(p, 1, 2); immutable(Point)* immutableP = cast(immutable(Point)*) p; You could also use the emplace version that takes untyped memory: http://dlang.org/phobos/std_conv.html#.emplace The last one.
Re: emplace, immutable members and undefined behaviour
this compiles and runs fine. Because emplace expects a typed
pointer, it actually modifies (*p).x and (*p).y
As far as I understand, this causes undefined behavior.
Are there any (safe) alternatives to this code other than
making the immutable members mutable?
As long as there are no other references to the immutable members
and you can guarantee that they are indeed in mutable memory
(both guaranteed by malloc) you are safe. If you really don't
want to write to any immutable member, you could do this:
struct Point {
double a;
double b;
}
Point* p = (allocate memory from somewhere);
emplace!Point(p, 1, 2);
immutable(Point)* immutableP = cast(immutable(Point)*) p;
emplace, immutable members and undefined behaviour
According to http://dlang.org/const3.html any modification of
immutable data causes undefined behaviour. Now I want to
initialise a struct with immutable members in some malloc'd
memory and found the emplace function. I came up with the
following code:
import core.stdc.stdlib;
import std.conv;
struct Point {
immutable double x;
immutable double y;
}
void main() {
void* a = malloc(Point.sizeof);
Point* p = cast(Point*) a;
emplace!Point(p, 1.0, 2.0);
}
this compiles and runs fine. Because emplace expects a typed
pointer, it actually modifies (*p).x and (*p).y
As far as I understand, this causes undefined behavior.
Are there any (safe) alternatives to this code other than making
the immutable members mutable?
