Devrais-je arrêter d'utiliser le terme C / C ++?

Je comprends que C et C ++ sont des langages différents, mais lors de mon apprentissage du C ++, on me disait toujours que C était un sous-ensemble de C ++ ou que C ++ était C avec des classes. Et cela était tout à fait vrai jusqu'à l'apparition de C ++ x0, C ++ 11 (ou du C ++ moderne en général). En fait (surtout lorsque vous travaillez sur des systèmes embarqués), il est très probable que le code soit écrit en C ++, mais avec de nombreuses parties écrites entièrement en langage C pur. Ici j'ai plusieurs questions:

1. Devrais-je arrêter d'utiliser le terme C / C ++?
2. Si la réponse à la question 1 est oui, comment pourrais-je appeler un programme qui utilise une combinaison de C et C ++?
3. Étant donné que ces deux langues sont des langages "différents", il est probable qu'un compilateur C ++ cesse de prendre en charge le code écrit en langage C (car le c ++ moderne s'écarte de la mentalité C pour les éléments de base tels que les pointeurs, la gestion dynamique de la mémoire, etc.)
4. Existe-t-il actuellement une collaboration entre les personnes qui établissent les normes du C / C ++ pour conserver la compatibilité
5. Si # 4 est oui, une telle collaboration pourrait aboutir dans un proche avenir avec l'apparition du c ++ moderne (11/14/17)

Je sais qu'il y a déjà des questions similaires, mais je suis sûr que beaucoup de personnes partagent ces questions, donc je suis très intéressé d'obtenir de bonnes réponses, en particulier pour les points relatifs à la tendance C ++ dans un proche avenir.

C n'a jamais été un sous-ensemble de C ++. L'exemple le plus évident de cela est int new;. C’est vrai depuis C89 et C ++ 98, et les langages n’ont fait que se distancer au fur et à mesure que de nouvelles normes sont apparues.

Devrais-je arrêter d'utiliser le terme C / C ++

Oui

Si la réponse à la question 1 est oui, comment pourrais-je appeler un programme qui utilise une combinaison de C et C ++?

Un fichier source est écrit dans une langue ou une autre. Un programme peut consister en un code provenant de plusieurs langues travaillant ensemble ou en un exécutable créé en liant différents objets compilés. Vous diriez que le programme a été écrit en C et C ++, "C / C ++" n’est pas un langage.

Étant donné que les deux sont des langages "différents", il est probable qu'à un moment donné, les compilateurs C ++ cessent de prendre en charge le code écrit en langage C

3) Ils ne l'ont jamais fait. char *a = malloc(10);. C et C ++ n’ont jamais été totalement compatibles depuis au moins aussi longtemps qu’ils respectaient les normes ISO (je ne connais pas tous les détails des jours pré-normalisés). Cliquez sur les liens ou reportez-vous ci-dessous à la recherche d'un fichier compatible avec C89 et supérieur, mais non valide sous aucune norme C ++.

4) autant que je sache, les groupes de travail se connaissent, mais les normes prennent les décisions qui leur conviennent le mieux.

/* A bunch of code that compiles and runs under C89 but fails under any C++ */

/* type aliases and struct names occupy separate namespaces in C, not in C++ */
struct S { int i; };
typedef int S;


struct Outer { struct Inner { int i; } in; };
/* struct Inner will be Outer::Inner in C++ due to name scope */
struct Inner inner;


/* default return type of int in C, C++ functions need explicit return types */
g() {
    return 0;
}


/* C sees this as two declarations of the same integer,
 * C++ sees it as redefinition */
int n;
int n;


/* K&R style argument type declarations */
void h(i) int i; { }


/* struct type declaration in return type */
struct S2{int a;} j(void) { struct S2 s = {1}; return s; }


/* struct type declaration in argument, stupid and useless, but valid */
/*void dumb(struct S3{int a;} s) { } */


/* enum/int assignment */
enum E{A, B};
enum E e = 1;


void k() {
    goto label; /* C allows jumping past an initialization */
    {
        int x = 0;
label:
        x = 1;
    }
}


/* () in declaration means unspecified number of arguments in C, the definition
 * can take any number of arguments,
 * but means the same as (void) in C++  (definition below main) */
void f();

int main(void) {
    f(1); /* doesn't match declaration in C++ */
    {
        /* new is a keyword in C++ */
        int new = 0;
    }

    /* no stdio.h include results in implicit definiton in C.  However,
     * as long as a matching function is found at link-time, it's fine.
     * C++ requires a declaration for all called functions */
    puts("C is not C++");
    {
        int *ip;
        void *vp = 0;
        ip = vp; /* cast required in C++, not in C */
    }
    return 0;
}

/* matches declaration in C, not in C++ */
void f(int i) { }

Je pense toujours qu'il vaut la peine de mentionner que C est un sous-ensemble d'Objective-C.

Il doit y avoir une raison pour laquelle ces termes sont si souvent réunis. Bien que vous ne devriez pas dire à votre professeur de C que sa langue est un sous-ensemble du C ++, il y a une part de vérité ici. D'autres ont déjà exposé le point de vue de votre professeur. C'est très agréable (et illustré d'exemples, etc.). Mais nous ne vivons pas dans une tour d'ivoire ou un livre.

Votre grand patron se moque de la langue exacte que vous avez utilisée. S'il en sait un peu sur la programmation, dites-lui simplement que vous avez utilisé le C / C ++ et que le son sera: "J'ai utilisé un langage qui doit être compilé en code machine, avec des DLL et tout le reste compliqué". C'est la partie "communication externe".

Si vous créez une bibliothèque pouvant être interfacée à la fois par C et C ++, vous voudrez certainement l'appeler une bibliothèque C / C ++. Bien sûr, quelqu'un lèvera la main et vous demandera pourquoi vous n'appelez pas cela une bibliothèque C disposant d'un wrapper C ++, et de toute façon, le C ++ peut être lié à des bibliothèques C, de sorte que vous n'avez pas besoin de le mentionner du tout. Répondez simplement: "Oui, vous avez raison, il s’agit d’une bibliothèque C / C ++". C'est la partie "communication interne".

Si vous créez un analyseur lexical pour C ++, vous seriez surpris de voir à quel point il fonctionne avec C. Vous n'aurez peut-être même pas besoin de tout modifier. Ceci est le "si cela ressemble à un canard, etc." partie.

Etc.

La majorité des programmes C que j'ai vus se compilent (et fonctionnent) sans modification en code C ++. Ne laissez pas quelques exceptions ou programmeurs dogmatiques (même influents) tromper votre intuition. C et C ++ sont si proches et si souvent compatibles, et si souvent mélangés et appariés, que le terme C / C ++ est utilisé. Il est utilisé car il est utile de décrire ce type de situation où il importe peu de savoir si vous envisagez d'utiliser le C ou le C ++, tant que ce n'est pas Java ou PHP . Nous savons que c'est "faux", mais cela nous est égal, c'est plus utile que mal.

Cela peut être abusé, stupide, mais je ne suis pas sûr de l’avantage que vous obtiendrez en étant plus pédant que nécessaire et en refusant de communiquer dans des termes que les autres comprennent. Si vous vous sentez mal à l'aise dans une situation donnée, n'utilisez simplement pas le terme générique C / C ++, mais celui qui est pertinent en l'espèce (C ou C ++).

N'ayez pas peur de l'avenir. Nos systèmes d'exploitation sont écrits en C. Une grande partie de la production logicielle actuelle en C / C ++ se fait en C ++. Ce couple est là pour rester pendant un bon moment. Personne n'a intérêt à ce que l'un soit rendu plus incompatible avec l'autre (au contraire, en fait).

Pour être précis sur vos points:

1) ça dépend. Oui, lorsque cela peut semer la confusion, lorsque vous vous sentez mal à l'aise, ou simplement que c'est faux ou hors de contexte. Non quand vous pensez que c'est adéquat.

2) N / A

3) Je pense que non, mais je n'ai pas de boule de cristal.

4) aucune idée

5) Je ne pense pas, car rien ne va dans cette direction

Aller à contre-courant, je dirais que cela dépend du contexte .

Le terme "C / C ++" n'est généralement pas approprié lorsque vous dites quelque chose comme "ceci est un programme C / C ++", mais cela a été approfondi dans d'autres réponses.

Cependant, il peut y avoir des contextes où C / C ++ peut être approprié.

• Il existe différentes bibliothèques qui ont généralement une API C et C ++. Je suppose que ce n’est pas loin de la vérité si vous appelez une telle chose une bibliothèque C / C ++. Nous, les humains, aimons compresser les informations. Par conséquent, dire "opencv est une bibliothèque C / C ++" est court, clair et compréhensible, comparez cela à "opencv est une bibliothèque qui est livrée avec des en-têtes pour C et C ++".
• Vous pouvez parler de la conception et de la syntaxe du langage. Du point de vue de la syntaxe de langage, vous pourriez dire qu’un langage a une syntaxe semblable à C / C ++.
• Vous organisez un concours de codage et vous acceptez les deux solutions écrites en C et en C ++.
• Vous embauchez un nouveau programmeur et la plupart des tâches seront en C ou C ++. Le programmeur doit donc connaître les deux langages. C'est courant dans les développements intégrés, où le C convient mieux à certains microcontrôleurs (généralement très petits) et le C ++ à d'autres. Dans ce cas, vous pourriez dire que vous recherchez un programmeur C / C ++.

En général, les utilisateurs de SO demandent à la personne qui pose la question de choisir un langage: C ou C ++. Pourquoi?

Il existe de nombreuses différences subtiles entre C et C ++. Par exemple, en C ++, une constvariable de portée globale a une liaison interne sauf si elle est déclarée extern, mais en C elle a une liaison externe sauf si elle est déclarée static. En disant "C / C ++", l'OP affirme que la réponse à sa question est la même en C et C ++, alors que ce n'est peut-être pas le cas. Cela complique inutilement la tâche des personnes susceptibles de répondre.

• Parfois, nous pouvons remarquer que le code n'est pas valide dans l'une ou l'autre langue (par exemple, les conversions implicites de point void*à point ne sont pas valides en C ++). C'est énervant. Pourquoi dites-vous "C / C ++" quand vous avez un morceau de code valide en C mais pas en C ++? Aviez-vous l'intention de C, ou s'agit-il simplement d'une erreur de code destiné à être C ++?

• Parfois, la réponse sera différente selon le langage (par exemple, des tableaux de longueur variable existent en C99 mais pas en C ++). Si nous ne savons pas de quelle langue vous parlez, nous devons soit deviner, soit écrire une réponse pour les deux quand une seule sera réellement utile, car vous savez quelle langue vous utilisez réellement; vous ne nous dites pas juste!

• Parfois, la réponse est vraiment la même pour les deux langues, mais il est difficile d’en être sûr. Par exemple, je pense que C et C ++ ont les mêmes règles de conversion d'entiers, mais pour être vraiment, vraiment sûr, je dois lire les deux normes attentivement. Encore une fois, cela me fait faire deux fois plus de travail que nécessaire lorsque vous ne vous souciez probablement que d'une des langues.

Quoi qu'il en soit, pour répondre à vos autres questions:

1. Oui.

2. Si vous associez des codes C et C ++, il est acceptable d’utiliser les deux balises, mais veuillez spécifier la langue de chaque fichier.

3. Il y a parfois des changements radicaux, mais ils sont rares et ont généralement un impact limité (sinon, ils ne sont pas approuvés). Par exemple, autoen C ++ 11.

4. Je ne pense pas qu'ils collaborent directement, mais ils sont attentifs aux évolutions dans l'autre langue et évitent d'introduire des modifications rendant la compatibilité plus difficile.

Et si vous voulez vraiment connaître les deux langues, c'est très bien, et vous pouvez le dire dans votre question. Quand vous dites "C / C ++", je ne suis vraiment pas sûr de ce que vous voulez dire, et on dirait vraiment que vous faites une supposition sur les deux langages.

On m'a toujours dit que C est un sous-ensemble de C ++ ou que C ++ est C avec des classes. Et c’était assez vrai jusqu’à l’apparition de C ++ x0, C ++ 11 (ou du C ++ moderne en général).

C n'a jamais été un sous-ensemble de C ++. Par exemple, C89 n'est pas un sous-ensemble de C ++ 98.

Quelques exemples:

• la forme liste d'identifiants C89 pour la déclaration de paramètres de fonction n'est pas prise en charge en C ++
• C89 et C ++ 98 ont des types différents pour les constantes de caractères
• C89 et C ++ 98 ont des types différents pour les littéraux de chaîne
• les opérateurs logiques produisent différents types en C89 et C ++ 98 ( intvs bool)

1. Devrais-je arrêter d'utiliser le terme C / C ++?

Oui.

2. Si la réponse à la question 1 est oui, comment pourrais-je appeler un programme qui utilise une combinaison de C et C ++?

Un programme est soit C, soit C ++ (si même un programme très basique peut être compilé avec un compilateur C ou C ++). Quel compilateur utilisez-vous pour le compiler? Cela devrait répondre à votre question. Harbison & Steele ont inventé le terme Clean C pour désigner un sous-ensemble commun de C et C ++, mais je pense que c'était une mauvaise idée.

EDIT : Cependant, j’admets que techniquement, vous pouvez lier des fichiers d’objets C et C ++ dans un seul programme, mais OTH permet de mélanger de nombreux langages dans un seul programme, par exemple Java et C ++. Je pense que l'utilisation du terme programme C / C ++ ne fait qu'ajouter à la confusion qu'il est écrit dans un seul langage appelé C / C ++.

3. Étant donné que ces deux langues sont des langages "différents", il est probable qu'un compilateur C ++ cesse de prendre en charge le code écrit en langage C (car le c ++ moderne s'écarte de la mentalité C pour les éléments de base tels que les pointeurs, la gestion dynamique de la mémoire, etc.)

Il existe de nombreuses fonctionnalités (exemple: tableau de longueur variable, membre de tableau flexible,, _Generic...) de C99 ou C11 qui ne sont prises en charge par aucune version C ++.

Certains programmes sont écrits dans un mélange de C et C ++

Ceci est juste une réalité de la vie. Vous pouvez compiler des fichiers objet à partir de C et C ++ et les lier entre eux. On peut raisonnablement appeler le résultat "un programme C / C ++".

Mais ce n'est que le programme dans son ensemble. Qu'en est-il des unités de compilation individuelles?

Il existe un sous-ensemble de C qui est également un sous-ensemble de C ++

Un programme (ou une unité de compilation) écrit dans ce sous-ensemble compilera et se comportera de la même manière sous les compilateurs C et C ++ conformes. Un tel programme ou fichier peut à juste titre être appelé "programme C / C ++" ou "fichier C / C ++".

Un programme partiel tel qu'un fichier d'en-tête peut également être utilisé dans les programmes C et C ++. De tels fichiers d'en-tête peuvent à juste titre être appelés en-têtes C / C ++.

Citant le professeur Bjarne Stroustrup:

C est un sous-ensemble de C ++?

Au sens mathématique strict, C n'est pas un sous-ensemble de C ++. Il existe des programmes qui valent le C mais pas le C ++ et même quelques façons d’écrire du code qui a une signification différente en C et C ++. Cependant, C ++ prend en charge toutes les techniques de programmation prises en charge par C. Chaque programme C peut être écrit essentiellement de la même manière en C ++ avec la même efficacité d'exécution et d'espace. Il n'est pas rare de pouvoir convertir en quelques heures des dizaines de milliers de lignes de C ANSI en C ++ de style C. Ainsi, C ++ est autant un sur-ensemble d'ANSI C que ANSI C est un sur-ensemble de K & R C et autant qu'ISO C ++ est un sur-ensemble de C ++ tel qu'il existait en 1985.

Bien écrit, le C a également tendance à être légal. Par exemple, chaque exemple dans Kernighan & Ritchie: "Le langage de programmation C (2e édition)" est également un programme C ++.

• http://www.stroustrup.com/bs_faq.html#C-is-subset

Alors oui, il existe une chose telle que C / C ++. C'est tout ce qui est à la fois valide C et valide C ++.

Le pré-processeur C fait partie du langage C. Le pré-processeur C ++ fait partie du langage C ++

Vous pouvez écrire une unité de compilation qui compilera sous C ou C ++ et sera différente . Par exemple, il peut avoir des fonctionnalités de base compilées en C mais tirer parti d’une bibliothèque C ++ s’il est compilé en C ++.

Si le programme est essentiellement identique, mais avec des fonctionnalités supplémentaires, il n’est pas tout à fait faux de dire que c’est le même programme. C'est pareil, mais aussi différent.

La plupart des programmeurs C peuvent faire au moins un peu de C ++ et vice-versa

Il n'est pas déraisonnable d'appeler une telle personne un programmeur C / C ++. Oui, ils se spécialisent probablement dans un domaine, mais y a-t-il quelqu'un qui est un programmeur compétent en C ou C ++ qui ne peut littéralement faire aucune autre langue? D'une certaine manière, ne sont-ils pas tous des programmeurs C / C ++?

Il n'y a rien de mal à dire "C / C ++". Ce qui compte, c'est d'être compris

La langue anglaise n'est pas un outil pour exprimer des syllogismes . Vous pouvez utiliser l'anglais pour la logique, mais seulement avec beaucoup d'effort.

En effet, les mots n’ont pas naturellement une signification exacte, mais plutôt un nuage vague de dénotations et de connotations. Ce qui compte, c’est que les gens comprennent ce que vous dites.

1. Devrais-je arrêter d'utiliser le terme C / C ++?

Absolument. On ne voit pas clairement ce que cette construction est censée exprimer, sauf peut-être une confusion sur ce que sont C et C ++ au nom de la personne qui utilise le terme.

Puisque cette confusion est une source courante de frustration, beaucoup de gens sont devenus très émus à son sujet et la simple apparence de ce terme sera une raison suffisante pour qu’ils deviennent négatifs à propos de votre contribution. Cela peut sembler idiot, mais cela semble être ce que nous avons.

Je recommande que, au lieu de parler de “C / C ++”, vous utilisiez un terme qui précise ce que vous voulez dire.

• Si vous parlez de quelque chose en C qui pourrait ou non être aussi vrai pour C ++, disons simplement C .

  Exemple: comment maindéclarer la fonction en C?

  Au début, il pourrait sembler que la réponse pour C ++ soit la même: int main()ou int main(int, char**). Mais au fil de la discussion, il pourrait être pertinent de souligner qu'en C ++, la fonction doit être déclarée au niveau global, ce qui n'a pas de sens en C, car elle n'a pas de namespaces. D'autre part, C permet d'appeler de mainmanière récursive , contrairement à C ++. En C ++, il y a une implicite return 0;si vous "tombez" mainmais en C, l' returninstruction est requise sur n'importe quel chemin. La liste est longue et rend la discussion beaucoup plus simple si vous précisez clairement le langage à discuter.

• Si vous parlez de quelque chose en C ++ qui pourrait ou non être vrai pour C, dites simplement C ++ .

  Exemple: un malloc()tableau ed de ints sera-t-il initialement entièrement composé de zéros en C ++?

  La réponse courte pour C se trouve être la même: non. Mais au fur et à mesure que la réponse se poursuit, il pourrait être intéressant de souligner qu'en C, callocserait une bonne alternative, alors qu'en C ++, utiliser un std::vector<int>aurait pu être un meilleur choix en premier lieu.

• Si vous souhaitez souligner une similarité entre C et C ++, dites C et C ++ .

  Exemple: En C et C ++, l' implémentation de sizeofan intest définie et peut varier entre les compilateurs et les architectures.

  Ici, nous voulons souligner que C et C ++ se comportent de la même manière. Nous parlons explicitement des deux langues.

En fait, je recommande que vous soyez encore plus précis et que vous ne parliez pas seulement de “C” ou de “C ++”, mais de la version précise. Les deux langues évoluent et une déclaration directe telle que

C ++ prend en charge /* … */et // …commente alors que C ne prend en charge que le /* … */style.

n'est ni juste ni faux.

2. Si la réponse à la question 1 est oui, comment pourrais-je appeler un programme qui utilise une combinaison de C et C ++?

Comme les langages se chevauchent, chaque programme C contiendra des parties qui pourraient ressembler à C ++ et vice versa. Néanmoins, les auteurs auront probablement opté pour un compilateur C ou C ++. Ainsi, dites «le programme est écrit en C » s’il est compilé avec un compilateur C et «le programme est écrit en C ++ » s’ils utilisent un compilateur C ++, même s’ils risquent de refuser l’utilisation de fonctionnalités C ++ modernes. Certaines personnes se réfèrent à ce code C ++ en tant que C ++ . L'absence de surcharge, les exceptions, le polymorphisme, les modèles et les flux d'E / S constituent les caractéristiques communes de ce code.

Si, au contraire, certains fichiers sont écrits en C et compilé avec un compilateur C et quelques autres fichiers sont écrits en C ++ et compilé avec un compilateur C ++, puis les fichiers objets liés ensemble, je dirais que « le programme est écrit dans un mélange de C et C ++ ”comme vous l’avez déjà fait.

Cependant, si, au lieu de cela, les auteurs prenaient grand soin d'écrire chaque fichier de manière à ce qu'il puisse être compilé avec un compilateur C ou C ++ et que le programme résultant fasse la même chose, vous pouvez dire que «le programme est écrit dans un sous-ensemble commun de C et C ++ ».

Ce dernier cas est souvent le cas pour les fichiers d’en-tête qui devraient être partagés entre le code C et C ++. L'écriture d'un tel code n'est pas facile, d'ailleurs. Si vous voulez plus souligner que seules les constructions ont été utilisés qui sont valides en C et C ++ et sont largement pris en charge par différents fournisseurs de compilateur, le terme d' un portable sous - ensemble commun de C et C ++ peut être utilisé pour souligner.

3. Étant donné que les deux sont des langages «différents», est-il probable qu'un compilateur C ++ cesse de prendre en charge le code écrit en langage C (puisque le C ++ moderne s'écarte de la mentalité C pour les éléments de base tels que les pointeurs, la gestion de mémoire dynamique, etc.)?

Je ne suis pas sûr de comprendre cette question. Comme C et C ++ sont des langages différents, vous ne pouvez pas vous attendre à ce qu'un compilateur accepte un programme écrit pour l'autre. Cependant, les statisticiens sont souvent conçus de façon modulaire et si un compilateur C ++ a un front-end , les chances sont bonnes , il disposera également d'un frontal C. (Vous choisirez ensuite laquelle de vos choix via un commutateur de ligne de commande ou un moyen similaire.) Tant que les deux langues seront largement utilisées, il semble très peu probable que cela change. Je pense que votre remarque sur le «C ++ moderne» est essentiellement une question de bonnes normes de codage et de la bibliothèque standard. Du point de vue du compilateur , l'évolution des deux langues est plutôt convergente que divergente.

4. Existe-t-il actuellement une collaboration entre les personnes qui établissent les normes du C / C ++ pour conserver la compatibilité?

Oui. Le modèle de mémoire et la bibliothèque d'opérations atomiques introduits dans C ++ 11 et C11 en sont un bon exemple. Il semble que les concepteurs des deux langues se rendent compte que la compatibilité est importante et travaillent à l’améliorer. Personnellement, j'aimerais que la collaboration soit plus intense et que les deux groupes de travail de l'ISO aient peut-être même adhéré, mais mes souhaits ne sont pas importants.

Bjarne Stroustrup parle des différences et des points communs entre les différentes versions de C et C ++ dans le § 44.3 de la 4ème édition du Langage de programmation C ++ qui, ironiquement, s'intitule «Compatibilité C / C ++». L'utilisation de ce terme pourrait en fait être appropriée dans ce cas car son sens est clair.

5. Si # 4 est oui, une telle collaboration pourrait aboutir dans un proche avenir avec l'apparition du C ++ moderne (11/14/17)

Comme discuté ci-dessus, cela s'est produit dans C ++ 11 et on s'attend à ce qu'il se reproduise.

C / C ++ est l'intersection de C et C ++.

int new;n'est pas C / C ++, et n'est pas non plus vector<int> foo;.

De même, C89 / C99 est l'intersection de ces deux langues, où ni l'une enum bool { false, true };ni l'autre for(int i = 0;;)n'est autorisée.

Et C ++ 11 / C ++ 14, etc.

Il est possible d'écrire du code qui compile (et s'exécute correctement) sous C ++ 11 et C ++ 14, même si compiler sous l'un n'implique pas qu'il compile sous l'autre. En fait, beaucoup de gens le font.

Et beaucoup de gens écrivent du code qui fonctionne en C et C ++.

Évidemment, plus le chevauchement est important, plus cela a de sens; Je ne m'attends pas à voir des questions sur le code C / C ++ / Java.

Bien qu'il soit "logique" de parler d'un sous-ensemble commun de ces langages, de nombreuses questions n'auront pas de réponse dans ce sous-ensemble, par exemple Qu'est-ce que main () devrait renvoyer en C et C ++?

Mais vous pouvez parler d'un code qui fonctionne pour plusieurs spécifications de langage, que ces spécifications soient différenciées par "version", "nom de langage" ou autrement.

Ceci est une sorte de réponse à la position selon laquelle "ceci est un code pour les programmeurs qui travaillent près du métal et qui est OK dans un contexte de gestion", comme indiqué dans certaines des autres réponses et commentaires.

Je dirais que même cette interprétation doit être prise avec précaution.

À partir du milieu des années 90 au moins, si vous vouliez un programmeur C ++ et que quelqu'un se décrivant comme un programmeur C appliqué, vous auriez dû demander à quel point ils connaissaient la conception orientée objet, quelle expérience ils avaient du débogage dans un objet. contexte orienté, et sur leur capacité à utiliser les bibliothèques de modèles. Vous voudriez sonder exactement ces problèmes lors de l'entretien et du processus d'embauche.

D'un autre côté, cela fait maintenant plus de 10 ans que les gourous du C ++ ont commencé à utiliser le "C ++ moderne", ce qui signifie qu'il est plus important de passer des indicateurs nus aux objets pointeurs plus sûrs et aux idiomes basés sur des itérateurs. Avec l’émergence de C ++ 11, il existe désormais un support explicite pour la programmation multi-paradigmes et la poussée vers le code qui n’affiche aucun pointeur nu est très forte. Ce que cela signifie, c'est que si j'interviewais aujourd'hui un programmeur C ++ pour un poste en C, je m'inquiéterais beaucoup de vérifier à quel point cette personne était familière avec les véritables pointeurs activés pour le tir à pied.

Je ne suis plus dans le métier ces temps-ci (même dans la mesure où je l'étais quand Stack Overflow en était à ses balbutiements), je ne vais donc pas tenter de deviner à quelle fréquence l'une ou l'autre des personnes interrogées imaginaires n'aurait pas les compétences croisées, mais Je pense que, comme le plus souvent, les langues sont très différentes.

En bref, "C / C ++" devrait être supprimé non seulement dans des contextes techniques, mais également dans la plupart des contextes professionnels.

La réponse la plus simple à cette question est que vous n'auriez jamais dû utiliser ce terme. C'est un terme qui ne devrait pas exister. Cela n'a pas de sens. Chaque programme est soit C, soit C ++.

Et c’était assez vrai jusqu’à l’apparition de C ++ x0, C ++ 11 (ou du C ++ moderne en général).

C ++ 98 et 03 ne sont même pas à distance avec les classes. Celui qui t'a appris ça ne connait pas la merde et tu peux les oublier. Cela n'a jamais été correct.

Conceptuellement, la conception de fichiers source C ne devrait présenter aucune difficulté particulière, de sorte qu'ils puissent également être compilés tels quels avec C ++. Cela peut en effet présenter des avantages importants. Par exemple, lors de l'écriture de code pour un système intégré, il est parfois utile de pouvoir tester le code sur un environnement PC hébergé. Si le code se compile proprement en C ++, il est possible d'avoir une instruction du type "MOTOR_ENABLE = 1;" écrire sur un bit d'E / S volatile sur le système intégré (compilé en C), mais déclencher une logique d'émulation sur le PC (compilation en C ++). Il serait aussi probablement possible de concevoir un type C ++ sur le PC qui se comporterait comme un uint16_t sur des systèmes embarqués plus petits (de sorte que, par exemple u16 x=65533;, un compilateur devrait considérer la valeur dex*xcomme neuf, plutôt que de pouvoir faire tout ce qu'il veut), bien qu'aucun de mes émulateurs ne l'ait encore inclus [en partie parce que les compilateurs C ++ que j'ai utilisés n'ont rien fait de farfelu dans de tels cas].

Malheureusement, les programmeurs C et les programmeurs C ++ ont une antipathie suffisante pour que les langages aient évolué au fil des ans de manière compatible. Tandis que C89 tentait d’adapter certaines des fonctionnalités les plus utiles du C ++ (telles que les prototypes de fonctions), il semble que les programmeurs souhaitant utiliser l’une des fonctionnalités du C ++ utilisent le C ++, ignorant le fait qu’il existe de nombreuses situations être utile pour pouvoir utiliser certaines des fonctionnalités de C ++ (par exemple, la capacité de surcharger des fonctions avec une liaison statique ou inline statique sans devoir accepter les coûts associés à d'autres fonctionnalités dont on n'a pas besoin (par exemple la gestion des noms associée à l'exportation fonctions surchargées).

Bien que l'intersection de C89 et de C ++ 98 soit un langage exploitable, le sur-ensemble utilisable des versions ultérieures de C avec les versions ultérieures de C ++ s'est probablement rétréci plutôt que développé (grâce à des éléments tels que la règle d'aliasing stricte) et les tendances favorisent une tendance constante. fissure croissante.