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

Question

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

1. Dois-je arrêter d'utiliser le terme C/C++?
2. Si la réponse à # 1 est oui, comment pourrais-je appeler un programme qui utilise un mélange de C et C++?
3. É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 (car le c ++ moderne s'écarte de la mentalité C pour les choses de base comme les pointeurs, la gestion dynamique de la mémoire, etc.)
4. Existe-t-il actuellement une collaboration entre les personnes qui font les standards du C/C++ pour garder la compatibilité
5. Si # 4 est oui, une telle collaboration pourrait se terminer dans un proche avenir avec l'apparition du c ++ moderne (14/11/17)

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

Answer 1

C n'a jamais été un sous-ensemble de C++. L'exemple le plus évident est int new;. Cela est vrai depuis C89 et C++ 98, et les langages ne se sont éloignés les uns des autres que lorsque de nouvelles normes sont apparues.

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

Oui

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

Un fichier source est écrit dans une langue ou dans l'autre. Un programme peut être composé de code provenant de plusieurs langages travaillant ensemble, ou d'un exécutable produit 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é entièrement compatibles depuis au moins aussi longtemps qu'ils ont des normes ISO (je ne sais pas tous les détails sur les jours pré-standardisés). cliquez sur les liens ou voyez ci-dessous pour un fichier qui est bien avec C89 et plus, mais qui n'est valide sous aucune norme C++.

4) afaik non, 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) { }

J'ai toujours l'impression qu'il vaut la peine de mentionner que C est un sous-ensemble d'Objective-C.

Answer 2

Il doit être une raison pour laquelle ces termes se rencontrent si souvent. Bien que vous ne deviez pas dire à votre professeur C que son langage est un sous-ensemble de C++, il y a du vrai ici. D'autres ont déjà exposé le point de vue de votre professeur. C'est très sympa (et illustré d'exemples, etc.). Mais nous ne vivons pas dans une tour d'ivoire ou un livre.

Votre grand patron ne se soucie pas du langage exact que vous utilisez. S'il connaît un peu la programmation, dites-lui simplement que vous avez utilisé le C/C++ et cela ressemblera à "J'ai utilisé un langage qui doit être compilé pour coder la machine, avec des DLL et tout le reste". Il s'agit de la partie "communication externe".

Si vous créez une bibliothèque qui peut être interfacée à la fois par C et C++, vous voulez 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 qui se trouve avoir un wrapper C++, et de toute façon C++ peut se lier aux bibliothèques C donc vous n'avez pas besoin de le mentionner du tout. Répondez simplement: "Oui, vous avez raison, c'est une bibliothèque C/C++". Il s'agit de 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 pourriez même ne pas avoir besoin de tout modifier. C'est le "si ça ressemble à un canard, etc." partie.

Etc.

La majorité des programmes C que j'ai jamais vus se compilent (et fonctionnent) sans modification en tant que 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 genre de situations où peu importe que vous envisagiez C ou C++, tant que ce n'est pas Java ou PHP =. Nous savons que c'est "faux", mais peu nous importe, c'est plus utile que faux.

Il peut être abusé, il peut être stupide, mais je ne sais toujours pas quel avantage vous obtiendrez en étant plus pédant que nécessaire et refusez de communiquer en termes que les autres comprennent. Si vous vous sentez mal à l'aise dans une situation spécifique, alors n'utilisez simplement pas le terme générique C/C++, mais celui pertinent pour le cas (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 actuelle de logiciels C/C++ se produit en C++. Ce couple est là pour rester un bon moment. Personne n'a intérêt à ce que l'un soit rendu plus incompatible avec l'autre (à l'inverse, en fait).

Pour être précis sur vos points:

1) Cela dépend. Oui quand cela peut conduire à une confusion, quand vous vous sentez mal à l'aise, ou quand c'est simplement faux ou hors contexte. Non quand vous pensez que c'est suffisant.

2) N/A

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

4) aucune idée

5) Je ne le pense pas car rien ne pousse dans cette direction

Answer 3

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

Le terme "C/C++" n'est généralement pas approprié pour dire quelque chose comme "ceci est un programme C/C++", mais cela a été exploré en profondeur 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 à la fois un C et une API 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, donc dire "opencv est une bibliothèque C/C++" est court, clair et compréhensible, comparez-le à dire "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 du langage, vous pourriez dire qu'un langage a une syntaxe de type 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 soit C ou C++, donc le programmeur devrait connaître les deux langages. Il est courant dans le développement embarqué, où C est plus approprié pour certains microcontrôleurs (généralement très petits) et C++ pour d'autres. Dans ce cas, vous pourriez dire que vous recherchez un programmeur C/C++.

Answer 4

En général, les utilisateurs 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 variable const de portée globale a un lien interne sauf si elle est déclarée extern, mais en C elle a un lien externe sauf si elle est déclarée static. En disant "C/C++", l'OP affirme qu'il sait que la réponse à sa question est la même en C et en C++, alors qu'elle pourrait très bien ne pas l'être. Cela rend inutilement les choses plus difficiles pour les répondeurs potentiels.

• Parfois, nous pouvons constater que le code n'est pas valide dans une langue ou dans l'autre (par exemple, les conversions implicites de void* pour pointer vers l'objet ne sont pas valides en C++). C'est énervant. Pourquoi dites-vous "C/C++" quand vous avez un morceau de code qui est valide en C mais pas C++? Avez-vous l'intention de C, ou est-ce juste une erreur de code destiné à être C++?

• Parfois, la réponse sera différente selon la langue (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 deviner ou écrire une réponse pour les deux quand une seule sera réellement utile, car vous savez de quelle langue vous ' re réellement utiliser; vous ne nous le dites pas!

• 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 attentivement les deux normes. Encore une fois, cela me fait faire deux fois plus de travail que nécessaire lorsque vous ne vous souciez probablement que de l'une des langues.

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

1. Oui.

2. Si vous liez ensemble du code C et C++, il est acceptable d'utiliser les deux balises, mais veuillez spécifier dans quelle langue se trouve chaque fichier.

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

4. Je ne pense pas qu'ils collaborent directement, mais ils prêtent attention aux développements dans l'autre langue et essaient d'éviter d'introduire des changements qui rendraient la compatibilité plus difficile.

Et si vous voulez vraiment connaître les deux langues, c'est bien, et vous pouvez le dire dans votre question. Lorsque vous dites "C/C++", je ne sais vraiment pas de quoi vous parlez, et il semble vraiment que vous faites une hypothèse sur les deux langages.

Answer 5

On m'a toujours dit que C est un sous-ensemble de C++ ou C++ est C avec des classes. Et cela était vrai jusqu'à l'apparition de C++ x0, C++ 11 (ou du C++ 11/14/17 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:

• le C89 forme de liste d'identifiants pour la déclaration des paramètres de fonction n'est pas pris 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 (int vs bool)

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

Oui.

2. Si la réponse à # 1 est oui, comment pourrais-je appeler un programme qui utilise un mélange 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 a 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'avoue que techniquement vous pouvez lier des fichiers d'objets C et C++ dans un seul programme mais OTH là de nombreux langages sont autorisés à être mélangés 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 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 (car le c ++ moderne s'écarte de la mentalité C pour les choses de base comme 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 pris en charge par aucune version C++.

Answer 6

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

C'est juste une réalité de la vie. Vous pouvez compiler des fichiers objets à partir de C et C++ et les lier ensemble. Le résultat peut raisonnablement être appelé "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 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é "un programme C/C++" ou "un fichier C/C++".

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

Citant le professeur Bjarne Stroustrup:

C est-il un sous-ensemble de C++?

Au sens mathématique strict, C n'est pas un sous-ensemble de C++. Il existe des programmes qui sont valides C mais pas valides 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 le même temps d'exécution et la même efficacité d'espace. Il n'est pas rare de pouvoir convertir des dizaines de milliers de lignes de C ANSI en C++ de style C en quelques heures. Ainsi, C++ est autant un surensemble de ANSI C que ANSI C est un surensemble de K&R C et autant que ISO C++ est un surensemble de C++ comme il existait en 1985.

Un C bien écrit a également tendance à être du C++ légal. Par exemple, chaque exemple dans Kernighan & Ritchie: "The C Programming Language (2nd Edition)" est également un programme C++.

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

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

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érent. Par exemple, il peut avoir des fonctionnalités de base compilées en C mais tirer parti d'une bibliothèque C++ si elle est compilée en C++.

Si le programme est essentiellement le même, mais avec des fonctionnalités supplémentaires, ce n'est pas exactement mauvais pour dire que c'est le même programme. C'est la même chose, 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, mais y a-t-il quelqu'un qui est un programmeur C ou C++ compétent qui ne peut littéralement pas faire n'importe quoi de l'autre langage? D'une certaine manière, ne sont-ils pas tous 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 les syllogismes. Vous pouvez utiliser l'anglais pour la logique, mais juste et avec beaucoup d'efforts.

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

Answer 7

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

Absolument. Il n'est pas clair ce que cette construction est censée exprimer, sauf, peut-être, la confusion sur ce que sont C et C++ au nom de la personne qui utilise le terme.

Étant donné que cette confusion est une source de frustration si courante, de nombreuses personnes en sont devenues très émotives et l'apparence de ce terme seul sera une raison suffisante pour qu'elles deviennent négatives à propos de votre contribution. Cela peut sembler idiot, mais cela semble être ce que nous avons.

Je recommande qu'au lieu de parler de "C/C++", vous utilisiez un terme qui indique clairement ce que vous voulez dire.

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

  Exemple: Comment la fonction main doit-elle être déclarée en C?

  Au début, il peut sembler que la réponse pour C++ est la même: int main() ou int main(int, char**). Mais au fur et à mesure de la discussion, il pourrait être pertinent de souligner qu'en C++, la fonction doit être déclarée à portée globale, ce qui n'a pas de sens en C, car elle n'a pas de namespaces. D'un autre côté, C permet d'appeler main récursivement alors que C++ ne le fait pas. En C++, il y a un return 0; Implicite si vous "tombez" main mais en C, l'instruction return est requise sur n'importe quel chemin. La liste continue et rend la discussion beaucoup plus simple si vous précisez à l'avance quelle est la langue à discuter.

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

  Exemple: Un tableau malloc() ed de ints sera-t-il initialement tout à zéro 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 utile de souligner qu'en C, calloc serait une bonne alternative tandis qu'en C++, l'utilisation d'un std::vector<int> Aurait pu être un meilleur choix dans le premier endroit.

• Si vous souhaitez signaler une similitude entre C et C++, dites C et C++.

  Exemple: En C et C++, le sizeof an int est défini par l'implémentation 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 vous recommande d'être encore plus précis et de parler non seulement de "C" ou de "C++" mais de la version précise. Les deux langues évoluent et une déclaration brutale telle que

C++ prend en charge les commentaires /* … */ Et // … Tandis que C ne prend en charge que le style /* … */.

n'est ni bon ni mauvais.

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

Étant donné que les langages se chevauchent, chaque programme C contiendra des parties qui pourraient ressembler à C++ et vice versa. Néanmoins, les auteurs auront probablement choisi d'utiliser un compilateur C ou C++. Donc, 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 refusent d'utiliser des fonctionnalités C++ modernes. Certaines personnes se réfèrent à ce code C++ comme C++ de style C. L'absence de surcharge, d'exceptions, de polymorphisme, de modèles et de flux d'E/S est une caractéristique commune de ce code.

Si, à la place, certains fichiers sont écrits en C et compilés avec un compilateur C et certains autres fichiers sont écrits en C++ et compilés avec un compilateur C++, et puis les fichiers objets liés entre eux, je dirais que "le programme est écrit en n mélange de C et C++" comme, en fait, vous l'avez déjà fait.

Cependant, si, au lieu de cela, les auteurs ont pris grand soin d'écrire chaque fichier de telle manière qu'il puisse être compilé avec un C ou un C++ le compilateur et le programme résultant feraient la même chose, on pourrait dire que "le programme est écrit en n sous-ensemble commun de C et C++".

Ce dernier est souvent le cas pour les fichiers d'en-tête qui doivent être partagés entre le code C et C++. D'ailleurs, écrire un tel code n'est pas facile. Si vous souhaitez souligner davantage que seules ces constructions ont été utilisées qui sont valides en C et C++ et sont largement prises en charge par différents fournisseurs de compilateurs, le terme - n portable sous-ensemble commun de C et C++ peut être utilisé pour le souligner.

3. Étant donné que les deux sont des langages "différents", est-il probable qu'à un moment donné, les compilateurs C++ cessent de prendre en charge le code écrit en langage C (car le C++ moderne s'écarte de la mentalité C pour les choses de base comme les pointeurs, la gestion dynamique de la mémoire, 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 l'un des programmes écrits pour l'autre. Cependant, les compilateurs sont souvent conçus de manière modulaire et si un compilateur a un frontal C++ , les chances sont bonnes qu'il aura également un front C fin. (Vous choisiriez ensuite lequel d'entre eux vous souhaitez 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. Votre point sur le "C++ moderne", je pense, 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 langages est plutôt convergente que divergente.

4. Existe-t-il actuellement une collaboration entre les personnes qui font les standards du C/C++ pour garder la compatibilité?

Oui. Le modèle de mémoire et la bibliothèque d'opérations atomiques introduits en C++ 11 et C11 en sont un bon exemple. Il semble que les concepteurs des deux langues réalisent que la compatibilité est importante et travaillent à son amélioration. Personnellement, je souhaiterais que la collaboration soit plus intense et que les deux groupes de travail de l'ISO se soient même joints, 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 de Le langage de programmation C++ qui, ironiquement, est intitulé "Compatibilité C/C++". L'utilisation du terme pourrait en fait être appropriée dans ce cas, car il est clair ce que l'on entend.

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

Comme discuté ci-dessus, cela s'est produit en C++ 11 et devrait/devrait/devrait se reproduire.

Answer 8

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

int new; N'est pas C/C++, ni vector<int> foo;.

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

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

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

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

De toute évidence, plus le chevauchement est grand, plus il 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 langues, de nombreuses questions n'auront pas de réponses dans ce sous-ensemble, par ex. Que doit retourner main () en C et C++?

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

Answer 9

C'est en quelque sorte une réponse à la position selon laquelle "c'est un code pour les programmeurs qui travaillent près du métal et qui est OK dans un contexte de gestion" vu dans certaines des autres réponses et commentaires.

---

Je dirais que même cette interprétation devrait être prise avec soin.

À partir du milieu des années 90 au moins, si vous vouliez un programmeur C++ et quelqu'un qui se décrivait comme un programmeur C appliqué, vous auriez dû demander ce qu'il sait de la conception orientée objet, quelle expérience il a du débogage dans un objet contexte orienté, et sur leur capacité à utiliser des bibliothèques de modèles. Vous voudriez sonder exactement ces problèmes pendant l'entrevue et le processus d'embauche.

D'un autre côté, cela fait maintenant plus d'une décennie que les gourous du C++ ont commencé à pousser le "C++ moderne", ce qui signifie qu'il faut s'éloigner des pointeurs nus vers des objets pointeurs plus sûrs et des idiomes basés sur des itérateurs. Avec l'émergence de C++ 11, il y a maintenant un support explicite pour la programmation multi-paradigmes et le Push vers du code qui ne présente aucun pointeur nu est très fort. Ce que cela signifie, c'est que si j'interviewais un programmeur C++ pour un poste C aujourd'hui, je serais très inquiet de vérifier à quel point cette personne était familière avec les pointeurs réels, permettant de tirer à pied.

Je ne suis pas dans les affaires ces jours-ci (même dans la mesure où je l'étais lorsque Stack Overflow en était à ses balbutiements), donc je ne vais 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 les langues les plus souvent appliquées sont désormais très différentes.

En bref, "C/C++" devrait être abandonné non seulement dans les contextes techniques mais aussi dans la plupart des contextes commerciaux.

Answer 10

Sur le plan conceptuel, il ne devrait pas y avoir de difficulté particulière à concevoir des fichiers source C afin 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 embarqué, 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 comme "MOTOR_ENABLE = 1;" écrire sur un bit d'E/S volatile sur le système embarqué (compilé en C), mais déclencher la logique d'émulation sur le PC (compiler en C++). Il serait également probablement possible de concevoir un type C++ sur le PC qui se comporterait comme un uint16_t se comporte sur des systèmes embarqués plus petits (de sorte que, par exemple, étant donné u16 x=65533;, un compilateur devrait considérer la valeur de x*x comme neuf, plutôt que d'avoir le libre jeu de faire tout ce qu'il veut), bien qu'aucun de mes émulateurs n'ait encore inclus cela [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 suffisamment d'antipathie l'un envers l'autre que les langages ont, au fil des ans, évolué de manière compatible. Bien que C89 ait tenté d'adapter certaines des fonctionnalités les plus utiles de C++ (telles que les prototypes de fonctions), une attitude semble être apparue selon laquelle les programmeurs qui veulent l'une des fonctionnalités de C++ devraient utiliser C++, ignorant le fait qu'il existe de nombreuses situations où il le ferait. être utile pour pouvoir utiliser certaines des fonctionnalités de C++ (par exemple la possibilité de surcharger les fonctions avec une liaison statique ou en ligne statique sans avoir à accepter les coûts associés à d'autres fonctionnalités dont on n'a pas besoin ( par exemple, le nom mangling associé à l'exportation de fonctions surchargées).

Alors que l'intersection de C89 et C++ 98 est un langage exploitable, le sur-ensemble utilisable des versions ultérieures de C avec les versions ultérieures de C++ a probablement diminué plutôt que augmenté (grâce à des choses comme la règle stricte d'alias) et les tendances favorisent un fissure croissante.

Answer 11

La réponse la plus simple à cette question est que vous devriez jamais avoir utilisé ce terme. C'est un terme qui ne devrait pas exister. Cela n'a aucun sens. Chaque programme est soit C, soit C++.

Et cela était vrai jusqu'à l'apparition de C++ x0, C++ 11 (ou du C++ 11/14/17 moderne en général).

C++ 98 et 03 ne sont même pas à distance C avec des classes non plus. Celui qui vous a appris cela ne connaît pas la merde et vous pouvez les oublier. Ce n'était jamais correct.