Re: Opaque structs
Am Sat, 29 Jun 2013 17:38:38 +0200 schrieb monarch_dodra monarchdo...@gmail.com: On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote: Shouldn't doing anything value-related on an empty struct be invalid anyway? Why ? The fact that the struct has no members is an implementation detail which should have no impact on the user of the struct. It's probably a matter of perception. As you said in your other post there are good reasons to give empty structs a size. But if you (naively) think of a struct as a simple aggregate of other types, then a aggregate of zero other types should have size zero. There's no information in such a struct which would have to take up space. And doing something value-related on some type which doesn't have a size and therefore doesn't have a value is not really well-defined. (How do you copy a value of size 0? What happens if you dereference a pointer to a value of size 0?).
Re: Passing a instance of a class to a thread via spawn?
You must pass a shared object: Thanks!
static opDispatch
struct Bla {
static @property
Bla opDispatch(string s)() const {
pragma(msg, s);
return Bla();
}
}
void main() {
Bla.abc;
}
---
abc
/d675/f256.d(10): Error: no property 'abc' for type 'Bla'
/d675/f256.d(10): Error: Bla is not an expression
---
I guess static opDispatch does not exist? Any reasons why it doesn't
exist or is it just a bug? It looks like a bug, since the pragma prints.
Returning nothing, doesn't change anything btw.
Re: Opaque structs
On Sunday, 30 June 2013 at 08:18:39 UTC, Johannes Pfau wrote: Am Sat, 29 Jun 2013 17:38:38 +0200 schrieb monarch_dodra monarchdo...@gmail.com: On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote: Shouldn't doing anything value-related on an empty struct be invalid anyway? Why ? The fact that the struct has no members is an implementation detail which should have no impact on the user of the struct. It's probably a matter of perception. As you said in your other post there are good reasons to give empty structs a size. But if you (naively) think of a struct as a simple aggregate of other types, then a aggregate of zero other types should have size zero. Well, *technically*, it should have a size of *at least* 0, since the compiler is allowed to add as much padding as it wishes (which it does). There's no information in such a struct which would have to take up space. And doing something value-related on some type which doesn't have a size and therefore doesn't have a value is not really well-defined. (How do you copy a value of size 0? What happens if you dereference a pointer to a value of size 0?). Well, as you say, it is a matter of perception: From the client side, all the client should know is that the structs hold no information, the actual *size*, is not his problem: EG, it is an empty bag. The fact that the bag is empty though shouldn't prevent the client from having an array of bags, or to have pointers to the bag. If the client can't say I created an S, which is a struct that holds no *data*, and this is it's address, then there is a problem, and it is the implementation's fault. The compiler works around that problem by giving the empty struct a size. It is a dirty way to do it, but it works :)
memcpy in D
What is the equivalent of memcpy
module memcopy;
immutable ADDRESS_BUS_SIZE = 20; // 2^20 address bus
byte memory[1 ADDRESS_BUS_SIZE];
void main()
{
ushort val = 12345;
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (memory[i], val, sizeof val); // D way???
val++;
}
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (val, memory[i], sizeof val); // D way???
writefln(%x, val);
}
}
achieved in D? I am trying not to use memcpy or any function from the C API.
Thanks,
--
Andrew Edwards
http://www.akeron.co
auto getAddress() {
string location = @, period = .;
return (info ~ location ~ afidem ~ period ~ org);
}
Re: memcpy in D
On Sunday, 30 June 2013 at 11:07:24 UTC, Tyro[17] wrote:
What is the equivalent of memcpy
module memcopy;
immutable ADDRESS_BUS_SIZE = 20; // 2^20 address bus
byte memory[1 ADDRESS_BUS_SIZE];
void main()
{
ushort val = 12345;
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (memory[i], val, sizeof val); // D way???
val++;
}
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (val, memory[i], sizeof val); // D way???
writefln(%x, val);
}
}
achieved in D? I am trying not to use memcpy or any function
from the C API.
Thanks,
You could do it with ubyte a vector copy:
void * dmemcpy ( void * destination, const void * source, size_t
num ) pure nothrow
{
(cast(ubyte*)destination)[0 ..
num][]=(cast(const(ubyte)*)source)[0 .. num];
return destination;
}
Doing it this way has the advantage of being CTFE-able, and
(potentially) faster, as everything I ever read about D's memcpy
is that it is slow.
Re: memcpy in D
Doing it this way has the advantage of being CTFE-able, and (potentially) faster, as everything I ever read about D's memcpy is that it is slow. On Windows? Doesn't memcpy use libc memcpy on Linux?
Re: memcpy in D
30-Jun-2013 15:47, David пишет: Doing it this way has the advantage of being CTFE-able, and (potentially) faster, as everything I ever read about D's memcpy is that it is slow. On Windows? Doesn't memcpy use libc memcpy on Linux? Yup on Linux is pretty darn fast just as is with C/C++. It's the _same_ GLIBC. -- Dmitry Olshansky
Re: memcpy in D
On Sunday, 30 June 2013 at 11:47:49 UTC, David wrote: Doing it this way has the advantage of being CTFE-able, and (potentially) faster, as everything I ever read about D's memcpy is that it is slow. On Windows? Doesn't memcpy use libc memcpy on Linux? I honestly have no idea, I'm just repeating what I heard, which could very well be rumors. It could be an overhead to making the actual call? I have no idea. But I *do* know it ain't CTFE. dmemcpy is.
Re: static opDispatch
On 06/30/13 12:36, David wrote:
struct Bla {
static @property
Bla opDispatch(string s)() const {
pragma(msg, s);
return Bla();
}
}
void main() {
Bla.abc;
}
---
abc
/d675/f256.d(10): Error: no property 'abc' for type 'Bla'
/d675/f256.d(10): Error: Bla is not an expression
---
I guess static opDispatch does not exist? Any reasons why it doesn't
exist or is it just a bug? It looks like a bug, since the pragma prints.
Returning nothing, doesn't change anything btw.
Try removing the 'const' - static methods have no 'this'.
Error reporting for optional templated methods that exist, but fail
to instantiate, can be very misleading; calling such methods explicitly
sometimes helps to identify the problem.
artur
Re: static opDispatch
Try removing the 'const' - static methods have no 'this'. Error reporting for optional templated methods that exist, but fail to instantiate, can be very misleading; calling such methods explicitly sometimes helps to identify the problem. artur Oh wow, so easy ... Thanks I tottally did not see that const.
Re: memcpy in D
On Sun, 30 Jun 2013 07:40:31 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Sunday, 30 June 2013 at 11:07:24 UTC, Tyro[17] wrote:
What is the equivalent of memcpy
module memcopy;
immutable ADDRESS_BUS_SIZE = 20; // 2^20 address bus
byte memory[1 ADDRESS_BUS_SIZE];
void main()
{
ushort val = 12345;
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (memory[i], val, sizeof val); // D way???
val++;
}
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (val, memory[i], sizeof val); // D way???
writefln(%x, val);
}
}
achieved in D? I am trying not to use memcpy or any function from the C
API.
Thanks,
You could do it with ubyte a vector copy:
void * dmemcpy ( void * destination, const void * source, size_t num )
pure nothrow
{
(cast(ubyte*)destination)[0 .. num][]=(cast(const(ubyte)*)source)[0
.. num];
return destination;
}
Doing it this way has the advantage of being CTFE-able, and
(potentially) faster, as everything I ever read about D's memcpy is that
it is slow.
D's memcpy is C's memcpy. So I don't know why it would be slower. Note
that with DMD on windows 32 bit, it uses DMC, which may vary in
performance from MSVC memcpy.
Using vector assignment may or may not use memcpy. It may be the slower
one, but I don't know. If it can be inlined, it certainly would be faster
for small values.
-Steve
Windows parameter
Can someone help me with this:
I have a library which I try to import from D
//funcs.lib
//windows includes...
HWND hwnd;
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
//main.d
pragma(lib, gdi32.lib);
import core.runtime;
import core.sys.windows.windows;
extern (C++) {
int setHWND(HWND hwnd);
}
int main(int argc, char **argv) {
//windows initializers
setHWND(hwnd);
return 0;
}
but when I try to import that function this comes:
Error 42: Symbol Undefined ?setHWND@@YAHPAX@Z (int cdecl
setHWND(void *))
--- errorlevel 1
it seems like I cannot use HWND directly.
Re: Windows parameter
On Sun, 30 Jun 2013 20:24:17 +0200, shuji cravs...@hotmail.com wrote:
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
And:
extern (C++) {
int setHWND(HWND hwnd);
}
See how these are different? One of them is an extern (C++) function, the
other is a D function.
In other words, this should work:
//funcs.lib
//windows includes...
HWND hwnd;
extern (C++) { // This line!
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
}
//main.d
pragma(lib, gdi32.lib);
import core.runtime;
import core.sys.windows.windows;
extern (C++) {
int setHWND(HWND hwnd);
}
int main(int argc, char **argv) {
//windows initializers
setHWND(hwnd);
return 0;
}
--
Simen
Re: Windows parameter
this code is in a .cpp file
//funcs.lib
//windows includes...
HWND hwnd;
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
So im trying to import from D like this. I dont think I can
implement this line in C++
extern (C++) {}
Re: Windows parameter
On Sunday, 30 June 2013 at 19:03:13 UTC, shuji wrote:
this code is in a .cpp file
//funcs.lib
//windows includes...
HWND hwnd;
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
So im trying to import from D like this. I dont think I can
implement this line in C++
extern (C++) {}
I'm probably the most unqualified person to offer help but are
you sure you are linking with funcs.lib (assuming setHWND is
defined there)
Re: Windows parameter
On Sunday, 30 June 2013 at 20:04:12 UTC, Anthony Goins wrote:
On Sunday, 30 June 2013 at 19:03:13 UTC, shuji wrote:
this code is in a .cpp file
//funcs.lib
//windows includes...
HWND hwnd;
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
So im trying to import from D like this. I dont think I can
implement this line in C++
extern (C++) {}
I'm probably the most unqualified person to offer help but are
you sure you are linking with funcs.lib (assuming setHWND is
defined there)
yes, i have called other functions in the same file correctly.
PD I can call a function with void* as receiving paremeter:
//main.d
extern (C++) {
int setHWND(void* ehwnd);
}
//mylib.cpp
int setmyHWND(void* exthwnd){
hwnd = (HWND)exthwnd;
return 0;
}
and then cast on C++ to HWND, but I think it would be better to
send the parameter correctly as HWND.
Re: Windows parameter
Am 30.06.2013 22:20, schrieb shuji:
On Sunday, 30 June 2013 at 20:04:12 UTC, Anthony Goins wrote:
On Sunday, 30 June 2013 at 19:03:13 UTC, shuji wrote:
this code is in a .cpp file
//funcs.lib
//windows includes...
HWND hwnd;
int setHWND(HWND extHwnd){
hwnd = extHwnd;
return 0;
}
So im trying to import from D like this. I dont think I can implement
this line in C++
extern (C++) {}
I'm probably the most unqualified person to offer help but are you
sure you are linking with funcs.lib (assuming setHWND is defined there)
yes, i have called other functions in the same file correctly.
PD I can call a function with void* as receiving paremeter:
//main.d
extern (C++) {
int setHWND(void* ehwnd);
}
//mylib.cpp
int setmyHWND(void* exthwnd){
hwnd = (HWND)exthwnd;
return 0;
}
and then cast on C++ to HWND, but I think it would be better to send the
parameter correctly as HWND.
make sure the HWND parameter is on both sides the same (it has to get
mangled correctly!). I don't know if HWND is an opaque struct, if it is,
this might get you into trouble.
--- Cut here, I looked into core.sys.windows.windows:
---
alias void *HANDLE;
alias HANDLE HWND;
---
That is the problem, on the C++-Side HWND is not of type void* hence it
gets mangled differently, you need to get DMD mangle it the same as the
C++ compiler does...
The problem is (I just looked it up) HWND is *basically* void*
All typedefs:
PVOID = void*
HANDLE = PVOID
HWND = HANDLE
So you have to emulate a typedef to get the correct mangling... Maybe
start messing arround with structs?
struct HWND;
etc.
Maybe you could also try to use the deprecated typedef in D. Neither
of these soloutions are really great. I would consider this another bug
on the extern(C++) list.
Re: memcpy in D
Am Sun, 30 Jun 2013 07:07:23 -0400
schrieb Tyro[17] rid...@yahoo.com:
What is the equivalent of memcpy
module memcopy;
immutable ADDRESS_BUS_SIZE = 20; // 2^20 address bus
byte memory[1 ADDRESS_BUS_SIZE];
void main()
{
ushort val = 12345;
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (memory[i], val, sizeof val); // D way???
val++;
}
for (int i = 0x12340; i 0x1234A; i+= 2) {
memcpy (val, memory[i], sizeof val); // D way???
writefln(%x, val);
}
}
achieved in D? I am trying not to use memcpy or any function from the C API.
Thanks,
While they are in the C stdlib, there is nothing really C
specific about them. Just use them. In your case GCC would
recognize a memcpy call with known length (2 bytes) and inline
the call. From there I guess the optimizer can figure
something out that runs fast.
That said how about this in D:
ushort val = 12345;
for (int i = 0x12340; i 0x1234A; i+= 2)
*cast(ushort*) memory[i] = val++;
for (int i = 0x12340; i 0x1234A; i+= 2) {
val = *cast(ushort*) memory[i]
writefln(%04x, val);
}
--
Marco
Re: memcpy in D
... or alternatively:
// Simple integers can be compile-time literals (i.e. C's #define)
enum ADDRESS_BUS_SIZE = 20; // 2^20 address bus
// In D it is more ideomatic to put the array length first.
// For example this wouldn't work: byte x, *y, memory[1 ADDRESS_BUS_SIZE];
byte[1 ADDRESS_BUS_SIZE] memory;
void main()
{
ushort val = 12345;
ushort* base = cast(ushort*) memory[0x12340];
foreach (i; 0 .. 5)
base[i] = val++;
foreach (i; 0 .. 5)
writefln(%04x, base[i]);
}
--
Marco
