Nagios headers fails to compile in C++

[Matthieu Kermagoret]

On Thu, Dec 16, 2010 at 1:54 PM, Andreas Ericsson <ae at op5.se> wrote:
> On 12/16/2010 01:19 PM, Matthieu Kermagoret wrote:
>> On Thu, Dec 16, 2010 at 11:25 AM, Andreas Ericsson<ae at op5.se>  wrote:
>>> Oh. Can't C++ handle types as variable names? That's pretty weak tbh.
>>
>> Nop it cannot.
>>
>
> Why oh why. It's not as if the compiler can't discern the difference
> between variable names and variable types. grrmbl
>

It's not that the compiler cannot but the name lookup mechanism is
"improved". In C you only have 4 namespaces (labels, types, structure
members and "else") which are automatically used by the compiler. In
C++ you can define your own namespaces where you can put various kinds
of identifiers. I guess this "limitation" is just a question of
consistency.

> Bah. How does it handle "struct stat" vs "stat()" then? It seems pretty
> inconsistent if it handles one thing but not the other.
>

Using stat alone would lead to an ambiguous resolution. To use the
type you can use the 'struct' keyword such as "struct stat"
unambiguously resolve to the type name. The stat() call is resolved by
searching an identifier which can be used with the parenthesis
operator.

I hope it's a bit more clear this way ;-)

>> Wouldn't the _t suffix be appropriate (ie. host_t, service_t) ? It is
>> a widely used suffix for type names.
>>
>
> It is widely used because it is reserved by POSIX for POSIX types.
> size_t, socklen_t, pthread_mutex_t et al are all POSIX constructs, so
> that path is barred to us.
>

All right, I've never noticed this was actually written within the
POSIX standard.

> Perhaps "nagios_host", "nag_host" or "n_host", although "n" is quite
> commonly used as abbreviation for "number of".
>

According to http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02
the "n_" prefix is reserved if netdb.h is included. I'd never though
that that much identifiers were reserved ! Thanks for pointing it out.

> Either way, rearranging the object names for this project alone
> simply isn't worth it. Is there a particular reason you're dead set
> on writing the broker module in c++ rather than in plain c? If so,
> I'd recommend you importing the header files into your project and
> editing the names as you see fit.
>

I'll guess that's what I'll do until the patch is applied.

> Oh, and could you submit a small patch that, with "make cppneb",
> attempts to compile a microscopic C++ program using the core header
> files? That would make it a lot easier for me to handle testing of
> C++ functionality in the future. I'd write it myself, but I'm not
> familiar with C++ rules (if that wasn't obvious), so I'd probably
> botch the job completely.
>

The patch attached add a cppneb.cc source file in the module directory
and adds it to the 'modules' target. From what I understand this is
where sample modules belong. Also I'm no autotools expert and I didn't
dare to modify the configure{,.in} files. I hope the patch to
Makefile.in is not too ugly.

Best regards,

-- 
Matthieu KERMAGORET | Développeur

mkermagoret at merethis.com

MERETHIS est éditeur du logiciel Centreon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nagios_cppneb.patch
Type: text/x-patch
Size: 3037 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20101220/20191226/attachment.bin>
-------------- next part --------------
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel