No zero value in AvahiClientFlags enum

[tpot]

I'm using the client-publish-services example to create a DNS-SD client that registers services, but under gcc/g++ 4.1 the example's usage of avahi_client_new() does not compile.

ExperimentalProviders?/DNSSDClient/DNSSDClient.cpp: In member function 'virtual void hpwbem::DNSSDClientProvider::initialize(Pegasus::CIMOMHandle&)': ExperimentalProviders?/DNSSDClient/DNSSDClient.cpp:60: error: invalid conversion from 'int' to 'AvahiClientFlags?'

A simple patch adding a zero value to the enum fixes things (attached).

[tpot]

I've got the warning level wound up pretty high too: -W and -Wall flags are being used.

[lennart]

I don't think this is a good idea. The flags parameter is intended to be a bitmask, i.e. bitwise logical operators should be used on it. However, in C++ you cannot use those directly on an enum - you have to cast explicitly when checking or setting bits in a flags variable.

Since we do not provide a real C++ API I think our policy should be to require the user to always cast the flags parameter if he uses C++, regardless if the user wants to assign 0, wants to check a bit, or set a bit.

i.e. instead of defining AVAHI_CLIENT_NONE, use (AvahiClientFlags?) 0.

Thanks anyway for the patch.

[tedp]

Shouldn't enum types only ever hold a single one of the value list? It always seems to me like a flags parameter should simply used #defined values - enums are for a mutually exclusive set of possible values.

[lennart]

tedp: enums are just a cleaner way for doing integer #defines. In C they are behave exactly like literal integer constants in every way and may be used as such. Many programs use it for flags variables.

Why is it a good idea to use them for for defining literal integer constants? One reason is because gdb is able to decode enums properly, while it is not able to decode #defines. In fact, gdb even decodes ORed enums correctly!