Essa resposta é inspirada por um caso em que o raciocínio de Arne estava correto. Um fornecedor escreveu uma biblioteca que antes suportava C e C ++; no entanto, a versão mais recente suportava apenas C. As seguintes diretivas vestigiais deixadas no código eram enganosas:
#ifdef __cplusplus
extern "C" {
#endif
Isso me custou várias horas tentando compilar em C ++. Simplesmente chamar C de C ++ foi muito mais fácil.
A convenção ifdef __cplusplus viola o princípio de responsabilidade única. Um código que usa essa convenção tenta fazer duas coisas ao mesmo tempo:
- (1) executar uma função em C - e -
- (2) executar a mesma função em C ++
É como tentar escrever em inglês americano e britânico ao mesmo tempo. Isso está jogando desnecessariamente uma #ifdef __thequeensenglish spanner #elif __yankeeenglish wrench #else uma ferramenta inútil que torna o código mais difícil de ler #endif no código.
Para código simples e pequenas bibliotecas, a convenção ifdef __cplusplus pode funcionar; entretanto, para bibliotecas complexas, é melhor escolher um idioma ou outro e ficar com ele. O suporte a um dos idiomas exigirá menos manutenção do que tentar oferecer o suporte a ambos.
Este é um registro das modificações que fiz no código de Arne para compilá-lo no Ubuntu Linux.
foo.h :
#ifndef FOO_H
#define FOO_H
void foo(void);
#endif
foo.c
#include "foo.h"
#include <stdio.h>
void foo(void)
{
// modified to verify the code was called
printf("This Hello World was called in C++ and written in C\n");
}
bar.cpp
extern "C" {
#include "foo.h" //a C header, so wrap it in extern "C"
}
int main() {
foo();
return(0);
}
Makefile
# -*- MakeFile -*-
# dont forget to use tabs, not spaces for indents
# to use simple copy this file in the same directory and type 'make'
myfoobar: bar.o foo.o
g++ -o myfoobar foo.o bar.o
bar.o: bar.cpp
g++ -c -o bar.o bar.cpp
foo.o: foo.c
gcc -c -o foo.o foo.c
g++
mensagens de erro