Rusty on CeePljusPljus

Rusty Russell have some message for C++ (l)users and here it is. Short and sweet :P

No more sound

edelib will not play sounds any more. I just removed sound code from it which was pretty buggy, especially asynchronous playing. Actually, the only asynchronous part was buggy, mostly due quick threading support addition.

Alternatives? Two possible options that I'm thinking currently: use Audiere (maybe fork it), a very good sound library or develop own. Or maybe use both ideas; Audiere have very cool API and it can be inspiration for EDE sound library design.

Why Audiere fork? Besides cool API, there are few things I would like to change and remove; also the last update on the web is dating on 2006 and repository code gets updates from time to time (like recent native ALSA support addition).

Looks like EDE 2.0 alphas/betas will not have sound support; probably even official 2.0 will not have it. But I' m hoping it will not last too long for it's addition.

-pedantic anyone?

Everyone talks how C++ plays nicely with C? Of course it plays, until you engage somehow stricter validator in that compiler. After that, you are on your own...

During my recent emountd cooking (new EDE mount/unmount HAL-lified notify daemon) I was surprised that you will not be able to compile program that uses libhal with -pedantic flag: syntax error! Not to be expected for a product from people knowing their business...

I got this:

...found 95 target(s)...
...updating 2 target(s)...
C++ emountd.o
/usr/include/hal/libhal-storage.h:283: error: comma at end of enumerator
list
cc -c -o emountd.o -Wno-long-long -Wall -pedantic -g3 -D_DEBUG -I..
-I/opt/ede/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I. emountd.cpp
...failed
C++ emountd.o ...
...skipped emountd for lack of
emountd.o...
...failed updating 1 target(s)...
...skipped 1
target(s)...

Hm, at first I was thinking compiler went nuts after 5 hour compile/recompile torture; you know, I get used to errors like this in my code, but in code residing in /usr/XXX... that is completely different thing.

So, quick peek in that libhal-storage.h, revealed this:

typedef enum {
// formatting mess so list is reduced
// ...
LIBHAL_VOLUME_DISC_TYPE_HDDVDRW = 0x0f,
LIBHAL_VOLUME_DISC_TYPE_MO =
0x10,
} LibHalVolumeDiscType;

See last LIBHAL_VOLUME_DISC_TYPE_MO and comma at the end? Well, both C and C++ standards said "no no" to that, and -pedantic is here to reminds you on that. Not only for these syntax changes, but for C/C++ difference too; at least those that C++ didn't adopted. The main example is long long type: not yet supported by C++ standard.

Not problem a much, except now you will not be able to compile D-BUS code with g++ and -pedantic! And long long is very much used in it.

Besides emountd, this problem I had in edelib too, at least in D-BUS binding code.

Possible solutions for this mess is to either forget on -pedantic or to add -Wno-long-long, where warnings/errors about non standard long long will be inhibited. Since I like -pedantic, you know what I went for.

Btw. just checked: that issue with libhal is fixed, so I'll have to think how to remove -pedantic in 0.5.9 version (not sure about previous/later). Ah, yes, we have autoconf for that :P