I'm currently playing around with sound in D, using the native Linux functionality (eg. using ioctls, write and read and so forth) to do so.

I'm wondering if I'm doing it properly, design wise. I've been doing it sort of like I would if i were to write a C program that uses lots of assembly, confining it to wrapper functions (well, wrapper classes in this case) so that the rest of the code is as clean from native functions as possible (this way I imagine porting to other systems is easier).

Is this the best way of doing this, or should I consider other ideas?

Thanks.

Viktor L wrote:
> I'm currently playing around with sound in D, using the native Linux
> functionality (eg. using ioctls, write and read and so forth) to do so.
> 
> I'm wondering if I'm doing it properly, design wise. I've been doing it sort
> of like I would if i were to write a C program that uses lots of assembly,
> confining it to wrapper functions (well, wrapper classes in this case) so that
> the rest of the code is as clean from native functions as possible (this way I
> imagine porting to other systems is easier).
> 
> Is this the best way of doing this, or should I consider other ideas?
> 
> Thanks.

I think that's a good strategy, unless you're "re-inventing the wheel" for something already available through the D std. library (which _should_ be portable already for the most part)?

There doesn't seem to be any support for ioctl:s in the d std lib. That's the main
 part I'm having to implement, that and lower-levelish terminal stuff from termios.h

This far I've been importing macro values (that I suspect can change from system to system) by creating a c source file with constructs like

"int some_macro = SOME_MACRO;"
and then in d doing something like
"extern(C) { extern int some_macro; }"

Is this also a good idea, or is there another way of importing these sorts of macros?