Dovrei smettere di usare il termine C / C ++?

Capisco che C e C ++ sono lingue diverse ma quando stavo imparando il C ++ mi è sempre stato detto che C è un sottoinsieme di C ++ o C ++ è C con classi. E questo era abbastanza vero fino alla comparsa di C ++ x0, C ++ 11 (o del moderno C ++ 11/14/17 in generale). Infatti (specialmente quando si lavora su sistemi embedded) è molto probabile trovare codice scritto in C ++ ma con molte parti scritte interamente in linguaggio C puro. Qui ho diverse domande:

1. Dovrei smettere di usare il termine C / C ++?
2. Se la risposta al n. 1 è sì, come potrei chiamare un programma che utilizza un mix di C e C ++?
3. Dato che entrambi sono linguaggi "diversi", è probabile che a un certo punto i compilatori C ++ smettano di supportare il codice scritto nel linguaggio C (dal momento che il c ++ moderno si discosta dalla mentalità C per cose di base come puntatori, gestione dinamica della memoria, ecc.)
4. Esiste attualmente una collaborazione tra le persone che stabiliscono gli standard di C / C ++ per mantenere la compatibilità
5. Se il n. 4 è sì, tale collaborazione potrebbe finire nel prossimo futuro con l'apparizione del moderno c ++ (14/11/17)

So che ci sono già domande simili, ma sono sicuro che molte persone condividano queste domande, quindi sono molto interessato a ottenere buone risposte soprattutto per i punti che hanno a che fare con la tendenza del C ++ nel prossimo futuro.

C non è mai stato un sottoinsieme di C ++. L'esempio più ovvio di questo è int new;. Questo è vero dal C89 e dal C ++ 98 e le lingue sono cresciute l'una dall'altra solo quando sono emersi nuovi standard.

Dovrei smettere di usare il termine C / C ++

sì

Se la risposta al n. 1 è sì, come potrei chiamare un programma che utilizza un mix di C e C ++?

Un file sorgente è scritto in una lingua o nell'altra. Un programma può essere costituito da codice di più lingue che lavorano insieme o da un eseguibile prodotto collegando diversi oggetti compilati. Diresti che il programma è stato scritto in C e C ++, "C / C ++" non è un linguaggio.

Dato che entrambi sono linguaggi "diversi", è probabile che a un certo punto i compilatori C ++ smettano di supportare il codice scritto nel linguaggio C

3) Non l'hanno mai fatto. char *a = malloc(10);. C e C ++ non sono mai stati completamente compatibili almeno per il tempo in cui hanno avuto gli standard ISO (non conosco tutti i dettagli sui giorni pre-standardizzati). fai clic sui link o vedi sotto per un file che va bene con C89 e versioni successive, ma non è valido con nessuno standard C ++.

4) afaik no, i gruppi di lavoro sono consapevoli l'uno dell'altro ma gli standard prendono le decisioni migliori per se stessi.

/* 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) { }

Sento sempre la pena menzionare che C è un sottoinsieme di Objective-C.

Ci deve essere un motivo per cui questi termini si incontrano così spesso. Anche se non dovresti dire al tuo insegnante C che la sua lingua è un sottoinsieme del C ++, qui c'è del vero. Altri hanno già esposto il punto di vista del tuo insegnante. Questo è molto bello (e illustrato con esempi, ecc.). Ma non viviamo in una torre d'avorio o in un libro.

Al tuo grande capo non potrebbe importare di meno della lingua esatta che hai usato. Se sa un po 'di programmazione, digli che hai usato C / C ++ e sembrerà "Ho usato un linguaggio che deve essere compilato per codice macchina, con DLL e tutte le cose complicate". Questa è la parte "comunicazione esterna".

Se crei una libreria che può essere interfacciata sia da C che da C ++, devi sicuramente chiamarla libreria C / C ++. Certo, qualcuno alzerà una mano e chiederà perché non si chiama questa libreria C che sembra avere un wrapper C ++, e comunque C ++ può collegarsi alle librerie C quindi non è necessario menzionarlo affatto. Rispondi: "Sì, hai ragione, questa è una libreria C / C ++". Questa è la parte "comunicazione interna".

Se crei un analizzatore lessicale per C ++, rimarrai sorpreso da quanto bene funziona con C. Potrebbe anche non essere necessario modificarlo tutto. Questo è il "se sembra un'anatra, ecc." parte.

Eccetera.

La maggior parte dei programmi C che abbia mai visto compilare (e funzionare) senza modifiche come codice C ++. Non lasciare che alcune eccezioni o programmatori dogmatici (per quanto influenti) ingannino la tua intuizione. C e C ++ sono così vicini, e così spesso compatibili, e così spesso mescolati e messi insieme, che viene usato il termine C / C ++. Viene utilizzato perché è utile descrivere questo tipo di situazioni in cui non importa se si sta prendendo in considerazione C o C ++, purché non sia Java o PHP . Sappiamo che è "sbagliato", ma non ci interessa, è più utile che sbagliato.

Può essere abusato, può essere stupido, ma non sono sicuro di quali benefici otterrete essendo più pedante del necessario e rifiutando di comunicare in termini comprensibili agli altri. Se ti senti a disagio in una situazione specifica, semplicemente non usare il termine generico C / C ++, ma quello pertinente al caso (C o C ++).

Non aver paura del futuro. I nostri sistemi operativi sono scritti in C. Gran parte dell'attuale produzione di software C / C ++ avviene in C ++. Questa coppia è qui per un bel po '. Nessuno ha interesse a rendere l'uno reso più incompatibile con l'altro (al contrario, in realtà).

Per essere specifici sui tuoi punti:

1) dipende. Sì, quando potrebbe creare confusione, quando ti senti a disagio o quando è semplicemente sbagliato o fuori contesto. No quando pensi che sia adeguato.

2) N / A

3) Penso di no, ma non ho la sfera di cristallo.

4) nessuna idea

5) Non la penso così perché nulla spinge in questa direzione

Andando contro il flusso direi che dipende dal contesto .

Il termine "C / C ++" di solito non è appropriato quando si dice qualcosa come "questo è un programma C / C ++", ma questo è stato esplorato in modo approfondito in altre risposte.

Tuttavia, potrebbero esserci contesti in cui C / C ++ può essere appropriato.

• Esistono varie librerie che di solito hanno sia un'API C che un'API C ++. Immagino che non sia lontano dalla verità se si chiama una cosa del genere una libreria C / C ++. A noi umani piace comprimere le informazioni, quindi dire "opencv è una libreria C / C ++" è breve, chiaro e comprensibile, confrontarlo con dire "opencv è una libreria, che viene fornita con intestazioni sia per C che C ++".
• Puoi parlare di design e sintassi del linguaggio. Dal punto di vista della sintassi del linguaggio, potresti dire che una lingua ha una sintassi simile a C / C ++.
• Organizzi un concorso di codifica e accetti entrambe le soluzioni scritte in C e in C ++
• Stai assumendo un nuovo programmatore e la maggior parte delle attività saranno in C o C ++, quindi il programmatore dovrebbe conoscere entrambe le lingue. È comune nello sviluppo integrato, in cui C è più adatto per alcuni microcontrollori (di solito molto piccoli) e C ++ per altri. In questo caso potresti dire che stai cercando un programmatore C / C ++.

In generale, gli utenti SO chiedono alla persona che sta ponendo la domanda di scegliere una lingua: C o C ++. Perché?

Ci sono molte sottili differenze tra C e C ++. Ad esempio, in C ++, una constvariabile nell'ambito globale ha un collegamento interno a meno che non sia dichiarato extern, ma in C ha un collegamento esterno a meno che non sia dichiarato static. Dicendo "C / C ++", l'OP sta affermando la conoscenza che la risposta alla loro domanda è la stessa sia in C che in C ++, quando benissimo potrebbe non esserlo. Ciò rende inutilmente le cose più difficili per gli aspiranti rispondenti.

• A volte possiamo notare che il codice non è valido in una lingua o nell'altra (ad esempio, le conversioni implicite da void*puntatore a oggetto non sono valide in C ++). Questo è fastidioso. Perché dici "C / C ++" quando hai un pezzo di codice valido in C ma non in C ++? Intendevi C, o è solo un errore nel codice destinato a essere C ++?

• A volte la risposta sarà diversa a seconda della lingua (ad esempio, esistono array di lunghezza variabile in C99 ma non in C ++). Se non sappiamo di quale lingua stai parlando, o dobbiamo indovinare o scrivere una risposta per entrambi quando solo uno sarà effettivamente utile, perché sai quale lingua stai effettivamente usando; non ci stai dicendo!

• A volte la risposta è davvero la stessa per entrambe le lingue, ma è difficile esserne sicuri. Ad esempio, penso che C e C ++ abbiano le stesse regole di conversione dei numeri interi, ma per essere veramente, davvero sicuro, devo leggere attentamente entrambi gli standard. Ancora una volta, questo mi fa fare il doppio del lavoro necessario quando probabilmente ti interessa solo una delle lingue.

Ad ogni modo, per rispondere alle tue altre domande:

1. Sì.

2. Se si collegano insieme codice C e C ++, è accettabile utilizzare entrambi i tag, ma specificare la lingua in cui si trova ciascun file.

3. Ci sono cambiamenti di rottura a volte, ma sono rari e generalmente hanno un impatto limitato (altrimenti non vengono approvati). Ad esempio, autoin C ++ 11.

4. Non credo che collaborino direttamente, ma prestano attenzione agli sviluppi nell'altra lingua e cercano di evitare di introdurre cambiamenti che renderebbero più difficile la compatibilità.

E se vuoi davvero conoscere entrambe le lingue, va bene, e puoi dirlo nella tua domanda. Quando dici "C / C ++", non sono davvero sicuro di cosa tu voglia dire, e sembra proprio che tu stia prendendo un'ipotesi sulle due lingue.

Mi è sempre stato detto che C è un sottoinsieme di C ++ o C ++ è C con classi. E questo era assolutamente vero fino alla comparsa di C ++ x0, C ++ 11 (o del moderno C ++ 11/14/17 in generale).

C non è mai stato un sottoinsieme di C ++. Ad esempio C89 non è un sottoinsieme di C ++ 98.

Alcuni esempi:

• il modulo elenco identificatori C89 per la dichiarazione dei parametri di funzione non è supportato in C ++
• C89 e C ++ 98 hanno tipi diversi per le costanti dei caratteri
• C89 e C ++ 98 hanno tipi diversi per i letterali di stringa
• gli operatori logici producono tipi diversi in C89 e C ++ 98 ( intvs bool)

1. Dovrei smettere di usare il termine C / C ++?

Sì.

2. Se la risposta al n. 1 è sì, come potrei chiamare un programma che utilizza un mix di C e C ++?

Un programma è C o C ++ (se anche qualche programma molto semplice può essere compilato con un compilatore C o C ++). Quale compilatore stai usando per compilarlo? Dovrebbe rispondere alla tua domanda. Harbison e Steele hanno coniato il termine Clean C per designare un sottoinsieme comune di C e C ++, ma penso che sia stata una cattiva idea.

EDIT : Comunque ammetto che tecnicamente è possibile collegare file di oggetti C e C ++ in un singolo programma ma OTH ci sono molte lingue che possono essere mescolate in un singolo programma, ad esempio Java e C ++. Penso che l'uso del termine programma C / C ++ aggiunga solo confusione al fatto che sia scritto in un unico linguaggio chiamato C / C ++.

3. Dato che entrambi sono linguaggi "diversi", è probabile che a un certo punto i compilatori C ++ smettano di supportare il codice scritto nel linguaggio C (dal momento che il c ++ moderno si discosta dalla mentalità C per cose di base come puntatori, gestione dinamica della memoria, ecc.)

Esistono molte funzionalità (esempio: array a lunghezza variabile, membro dell'array flessibile _Generic, ...) di C99 o C11 che non sono supportate da alcuna versione C ++.

Alcuni programmi sono scritti in una miscela di C e C ++

Questo è solo un dato di fatto. È possibile compilare file oggetto da C e C ++ e collegarli insieme. Il risultato può ragionevolmente essere chiamato "un programma C / C ++".

Ma questo è solo il programma nel suo insieme. E le singole unità di compilazione?

C'è un sottoinsieme di C che è anche un sottoinsieme di C ++

Un programma (o unità di compilazione) scritto in quel sottoinsieme compilerà e si comporterà lo stesso con compilatori C e C ++ conformi. Tale programma o file può essere giustamente definito "un programma C / C ++" o "un file C / C ++".

Un programma parziale come un file di intestazione può essere utilizzato anche in programmi C e C ++. Tali file di intestazione possono essere giustamente definiti intestazioni C / C ++.

Citando il professor Bjarne Stroustrup:

C è un sottoinsieme di C ++?

In senso matematico rigoroso, C non è un sottoinsieme di C ++. Esistono programmi che sono C validi ma non C ++ validi e anche alcuni modi per scrivere codice che ha un significato diverso in C e C ++. Tuttavia, C ++ supporta tutte le tecniche di programmazione supportate da C. Ogni programma C può essere scritto essenzialmente allo stesso modo in C ++ con la stessa efficienza di runtime e spazio. Non è raro riuscire a convertire decine di migliaia di linee di ANSI C in C ++ di tipo C in poche ore. Pertanto, C ++ è tanto un superset di ANSI C quanto ANSI C è un superset di K&R C e tanto quanto ISO C ++ è un superset di C ++ come esisteva nel 1985.

Il C ben scritto tende anche a essere C ++ legale. Ad esempio, ogni esempio in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" è anche un programma C ++.

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

Quindi sì, esiste qualcosa come C / C ++. È tutto ciò che è sia C valido che C ++ valido.

Il pre-processore C fa parte del linguaggio C. Il pre-processore C ++ fa parte del linguaggio C ++

È possibile scrivere un'unità di compilazione che verrà compilata in C o C ++ ed essere diversa . Ad esempio, potrebbe avere funzionalità di base compilate in C ma trarre vantaggio da una libreria C ++ se compilata in C ++.

Se il programma è essenzialmente lo stesso, ma con funzionalità aggiuntive, non è esattamente sbagliato dire che è lo stesso programma. È lo stesso, ma anche diverso.

La maggior parte dei programmatori C può fare almeno un po 'di C ++ e viceversa

Non è irragionevole chiamare una persona del genere un programmatore C / C ++. Sì, probabilmente sono specializzati in uno, ma c'è qualcuno che è un programmatore competente in C o C ++ che letteralmente non può fare nessuna delle altre lingue? In un certo senso, non sono tutti programmatori C / C ++?

Non c'è niente di sbagliato nel dire "C / C ++". Ciò che conta è essere capito

La lingua inglese non è uno strumento per esprimere i sillogismi . È possibile usare l'inglese per la logica, ma solo, e con grande sforzo.

Questo perché le parole non hanno naturalmente significati esatti, ma piuttosto una vaga nuvola di denotazioni e connotazioni. Ciò che conta è se le persone capiscono quello che stai dicendo.

1. Dovrei smettere di usare il termine C / C ++?

Assolutamente. Non è chiaro che cosa intenda esprimere questo costrutto se non, forse, la confusione su ciò che C e C ++ sono per conto della persona che usa il termine.

Dal momento che questa confusione è una fonte di frustrazione così comune, molte persone sono diventate abbastanza emotive al riguardo e l'apparizione di quel solo termine sarà una ragione sufficiente per diventare negativi sul tuo contributo. Questo potrebbe sembrare sciocco ma sembra essere quello che abbiamo.

Raccomando che invece di parlare di "C / C ++" usi un termine che chiarisca effettivamente cosa intendi.

• Se si sta parlando di qualcosa in C che potrebbe o non potrebbe essere vero anche per C ++, semplicemente dire C .

  Esempio: come deve mainessere dichiarata la funzione in C?

  All'inizio, potrebbe sembrare che la risposta per C ++ sia la stessa: int main()o int main(int, char**). Ma mentre la discussione prosegue, potrebbe essere rilevante sottolineare che in C ++, la funzione deve essere dichiarata in ambito globale, il che non ha senso in C, perché non ha namespaces. D'altra parte, C consente di chiamare mainricorsivamente mentre C ++ no. In C ++, c'è un implicito return 0;se si "cade", mainma in C l' returnistruzione è richiesta su qualsiasi percorso. L'elenco continua e rende la discussione molto più semplice se si chiarisce in anticipo quale sia la lingua da discutere.

• Se stai parlando di qualcosa in C ++ che potrebbe o non potrebbe essere vero anche per C, dì semplicemente C ++ .

  Esempio: un malloc()array ed di ints inizialmente sarà tutto zero in C ++?

  La risposta breve per C sembra essere la stessa: no. Ma man mano che la risposta prosegue, potrebbe essere utile sottolineare che in C, callocsarebbe una buona alternativa mentre in C ++, l'utilizzo di a std::vector<int>potrebbe essere stata una scelta migliore in primo luogo.

• Se si desidera sottolineare una somiglianza tra C e C ++, dire C e C ++ .

  Esempio: in C e C ++, sizeofan intè definita dall'implementazione e può variare tra compilatori e architetture.

  Qui, vogliamo sottolineare che C e C ++ si comportano allo stesso modo. Stiamo parlando esplicitamente di entrambe le lingue.

In realtà ti consiglio di essere ancora più specifico e non solo di parlare di "C" o "C ++", ma della versione precisa. Entrambe le lingue si stanno evolvendo e una dichiarazione schietta come

C ++ supporta /* … */e // …commenta mentre C supporta solo lo /* … */stile.

non è né giusto né sbagliato.

2. Se la risposta al n. 1 è sì, come potrei chiamare un programma che utilizza un mix di C e C ++?

Poiché le lingue si sovrappongono, ogni programma C conterrà parti che potrebbero apparire come C ++ e viceversa. Tuttavia, gli autori probabilmente avranno optato per l'uso di un compilatore C o C ++. Quindi dite "il programma è scritto in C " se è compilato con un compilatore C e "il programma è scritto in C ++ " se usano un compilatore C ++, anche se potrebbero rifiutare di utilizzare qualsiasi funzionalità C ++ moderna. Alcune persone si riferiscono a tale codice C ++ come stile C C ++ . L'assenza di sovraccarico, eccezioni, polimorfismo, modelli e flussi di I / O sono caratteristiche comuni di tale codice.

Se, invece, alcuni file sono scritti in C e compilati con un compilatore C e alcuni altri file sono scritti in C ++ e compilati con un compilatore C ++ e quindi i file oggetto collegati tra loro, direi che "il programma è scritto in un mix di C e C ++ ”come, in effetti, hai già fatto.

Tuttavia, se invece gli autori si prendessero molta cura di scrivere ogni singolo file in modo tale da poterlo compilare con un compilatore C o C ++ e il programma risultante farebbe la stessa cosa, si potrebbe dire che "il programma è scritto in un sottoinsieme comune di C e C ++ ”.

Quest'ultimo è spesso il caso dei file di intestazione che dovrebbero essere condivisi tra il codice C e C ++. Scrivere un tale codice non è facile, comunque. Se si desidera sottolineare ulteriormente che sono stati utilizzati solo tali costrutti validi in C e C ++ e ampiamente supportati da diversi produttori di compilatori, il termine un sottoinsieme comune portatile di C e C ++ può essere utilizzato per enfatizzare questo aspetto.

3. Dato che entrambi sono linguaggi "diversi", è probabile che a un certo punto i compilatori C ++ smettano di supportare il codice scritto nel linguaggio C (dal momento che il C ++ moderno si discosta dalla mentalità C per cose di base come puntatori, gestione dinamica della memoria, ecc.)?

Non sono sicuro di aver capito questa domanda. Poiché C e C ++ sono lingue diverse, non ci si può aspettare che un compilatore accetti un programma scritto per l'altro. Tuttavia, i compilatori sono spesso progettati in modo modulare e se un compilatore ha un front-end C ++ , è probabile che abbia anche un front-end C. (Dovresti quindi selezionare quale di questi desideri tramite un interruttore della riga di comando o mezzi simili.) Finché entrambe le lingue saranno ampiamente utilizzate, sembra molto improbabile che questo cambi. Il tuo punto sul "C ++ moderno" credo sia fondamentalmente una questione di buoni standard di codifica e di libreria standard. Dal punto di vista del compilatore , l'evoluzione di entrambe le lingue è piuttosto convergente che divergente.

4. Esiste attualmente una collaborazione tra le persone che stabiliscono gli standard di C / C ++ per mantenere la compatibilità?

Sì. Il modello di memoria e la libreria delle operazioni atomiche introdotti in C ++ 11 e C11 ne sono un buon esempio. Sembra che i progettisti di entrambe le lingue si rendano conto che la compatibilità è importante e stanno lavorando per migliorarla. Personalmente, vorrei che la collaborazione fosse più intensa e che forse i due gruppi di lavoro ISO si unissero, ma i miei desideri non sono importanti.

Bjarne Stroustrup parla delle differenze e dei punti in comune tra le varie versioni di C e C ++ nel § 44.3 della 4a edizione di The C ++ Programming Language che, ironicamente, si intitola "Compatibilità C / C ++". L'uso del termine potrebbe effettivamente essere appropriato in questo caso in quanto è chiaro cosa si intende.

5. Se il numero 4 è sì, tale collaborazione potrebbe finire nel prossimo futuro con l'apparizione del moderno C ++ (14/11/17)

Come discusso in precedenza, è successo in C ++ 11 ed è previsto / sperato / necessario che accada di nuovo.

C / C ++ è l'intersezione di C e C ++.

int new;non è C / C ++ e nemmeno lo è vector<int> foo;.

Allo stesso modo, C89 / C99 è l'intersezione di queste due lingue, dove nessuno dei due enum bool { false, true };o for(int i = 0;;)è consentito.

E C ++ 11 / C ++ 14, ecc.

È possibile scrivere codice che viene compilato (ed eseguito correttamente) in C ++ 11 e C ++ 14, anche se la compilazione sotto uno non implica che si compili sotto l'altro. In effetti, molte persone lo fanno.

E molte persone scrivono codice che funziona in C e C ++.

Ovviamente, maggiore è la sovrapposizione, più senso ha; Non mi aspetto di vedere domande sul codice C / C ++ / Java.

Sebbene abbia "senso" parlare di un sottoinsieme comune di queste lingue, molte domande non avranno risposte in questo sottoinsieme, ad es. Cosa dovrebbe restituire main () in C e C ++?

Ma puoi parlare di codice che funziona per specifiche di più lingue, indipendentemente dal fatto che tali specifiche siano differenziate per "versione" o "nome della lingua" o in altro modo.

Questa è una sorta di risposta alla posizione secondo cui "questo è un codice per i programmatori che lavorano vicino al metal ed è OK in un contesto di gestione" visto in alcune delle altre risposte e commenti.

Direi che anche questa interpretazione dovrebbe essere presa con cura.

A partire almeno dalla metà degli anni '90 se volevi un programmatore C ++ e qualcuno che si autodefiniva un programmatore C, avresti dovuto chiedere quanto ne sapevano del design orientato agli oggetti, quanta esperienza hanno con il debug in un oggetto contesto orientato e sulla loro capacità di utilizzare librerie di modelli. Vorresti sondare esattamente questi problemi durante il processo di intervista e assunzione.

D'altro canto, è passato più di un decennio da quando i guru del C ++ hanno iniziato a spingere il "moderno C ++", il che significa enfatizzare il passaggio da puntatori nudi a oggetti puntatore più sicuri e modi di dire basati su iteratore. Con l'emergere di C ++ 11 ora esiste un supporto esplicito per la programmazione multi-paradigma e la spinta verso il codice che non mostra puntatori nudi è molto forte. Ciò significa che se avessi intervistato un programmatore C ++ per una posizione C oggi sarei molto preoccupato di verificare quanto questa persona avesse familiarità con i puntatori effettivi abilitati al tiro a piede.

In questi giorni non sono in attività (anche nella misura in cui ero quando Stack Overflow era agli inizi), quindi non mi avventurerò su quanto spesso entrambi gli intervistati immaginari non avrebbero le abilità incrociate, ma Penso che, come spesso applicato, le lingue ora siano davvero molto diverse.

In breve, "C / C ++" dovrebbe essere eliminato non solo in contesti tecnici ma anche in molti contesti aziendali.

La risposta più semplice a questa domanda è che non avresti mai dovuto usare quel termine. È un termine che non dovrebbe esistere. Non ha significato. Ogni programma è C o C ++.

E questo era assolutamente vero fino alla comparsa di C ++ x0, C ++ 11 (o del moderno C ++ 11/14/17 in generale).

C ++ 98 e 03 non sono nemmeno remotamente C con le classi. Chiunque ti abbia insegnato questo non conosce la merda e puoi dimenticarteli. Questo non è mai stato corretto.

Concettualmente, non dovrebbero esserci particolari difficoltà con la progettazione di file sorgente C in modo che possano essere compilati così com'è con C ++. Ci possono essere davvero alcuni vantaggi significativi nel fare questo. Ad esempio, quando si scrive il codice per un sistema incorporato, a volte è utile poter testare il codice su un ambiente PC ospitato. Se il codice viene compilato correttamente come C ++, è possibile avere un'istruzione come "MOTOR_ENABLE = 1;" scrivere su un bit I / O volatile sul sistema incorporato (compilato come C), ma attivare la logica di emulazione sul PC (compilando come C ++). Probabilmente sarebbe anche possibile progettare un tipo C ++ sul PC che si comporterebbe nel modo in cui un uint16_t si comporta su sistemi embedded più piccoli (in modo che, ad esempio u16 x=65533;, un compilatore dovrebbe considerare il valore dix*xcome nove, piuttosto che avere il regno libero di fare tutto ciò che vuole), anche se nessuno dei miei emulatori lo ha incluso [in parte perché i compilatori C ++ che ho usato non hanno fatto nulla di strano in questi casi].

Sfortunatamente, i programmatori C e i programmatori C ++ hanno abbastanza antipatia reciproca che le lingue, nel corso degli anni, si sono evolute in modo compatibile. Mentre C89 ha tentato di adattare alcune delle funzionalità più utili di C ++ (come i prototipi di funzioni), è emerso un atteggiamento secondo cui i programmatori che desiderano una delle funzionalità di C ++ dovrebbero usare C ++, ignorando il fatto che ci sono molte situazioni in cui sarebbe essere utile per essere in grado di utilizzare alcune delle funzionalità di C ++ (ad esempio la possibilità di sovraccaricare le funzioni con il collegamento inline statico o statico senza dover accettare i costi associati ad altre funzionalità che non sono necessarie (ad esempio il nome mangling associato all'esportazione funzioni sovraccaricate).

Mentre l'intersezione di C89 e C ++ 98 è un linguaggio praticabile, il superset utilizzabile delle versioni successive di C con le versioni successive di C ++ si è probabilmente ridotto piuttosto che cresciuto (grazie a cose come la regola di aliasing rigorosa) e le tendenze favoriscono un sempre- fessura crescente.