¿Debo dejar de usar el término C / C ++?

Entiendo que C y C ++ son lenguajes diferentes, pero cuando estaba aprendiendo C ++ siempre me dijeron que C es un subconjunto de C ++ o C ++ es C con clases. Y eso fue bastante cierto hasta la aparición de C ++ x0, C ++ 11 (o el moderno C ++ 11/14/17 en general). De hecho (especialmente cuando se trabaja en sistemas integrados) es muy probable que encuentre código escrito en C ++ pero con muchas partes escritas completamente en lenguaje C puro. Aquí tengo varias preguntas:

1. ¿Debo dejar de usar el término C / C ++?
2. Si la respuesta a # 1 es sí, ¿cómo llamaría a un programa que usa una combinación de C y C ++?
3. Dado que ambos son lenguajes 'diferentes', es probable que en algún momento los compiladores de C ++ dejen de admitir código escrito en el lenguaje C (dado que el C ++ moderno está divergiendo de la mentalidad C para cosas básicas como punteros, manejo dinámico de memoria, etc.)
4. ¿Existe ahora alguna colaboración entre las personas que hacen los estándares de C / C ++ para mantener la compatibilidad?
5. Si el número 4 es sí, dicha colaboración podría terminar en un futuro cercano con la aparición del moderno c ++ (14/11/17)

Sé que ya hay preguntas similares, pero estoy seguro de que muchas personas comparten estas preguntas, así que estoy muy interesado en obtener buenas respuestas, especialmente para los puntos que tienen que ver con la tendencia C ++ en el futuro cercano.

C nunca fue un subconjunto de C ++. El ejemplo más obvio de esto es int new;. Esto ha sido así desde C89 y C ++ 98, y los lenguajes solo han crecido más entre sí a medida que surgen nuevos estándares.

¿Debo dejar de usar el término C / C ++

si

Si la respuesta a # 1 es sí, ¿cómo llamaría a un programa que usa una combinación de C y C ++?

Un archivo fuente está escrito en un idioma u otro. Un programa puede consistir en código de múltiples idiomas trabajando juntos, o un ejecutable producido al vincular diferentes objetos compilados. Diría que el programa fue escrito en C y C ++, "C / C ++" no es un lenguaje.

Dado que ambos son lenguajes 'diferentes', es probable que en algún momento los compiladores de C ++ dejen de admitir código escrito en el lenguaje C

3) Nunca lo hicieron. char *a = malloc(10);. C y C ++ nunca han sido totalmente compatibles durante al menos el tiempo que han tenido estándares ISO (no conozco todos los detalles sobre los días preestandarizados). haga clic en los enlaces o vea a continuación un archivo que esté bien con C89 y versiones posteriores, pero que no sea válido bajo ningún estándar de C ++.

4) afaik no, los grupos de trabajo se conocen entre sí, pero los estándares toman las decisiones que son mejores para ellos.

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

Siempre siento que vale la pena mencionar que C es un subconjunto de Objective-C.

No tiene que haber una razón por qué estos términos se unen tan a menudo. Si bien no debe decirle a su maestro de C que su lenguaje es un subconjunto de C ++, aquí hay algo de verdad. Otros ya han expuesto el punto de vista de su maestro. Esto es muy bueno (e ilustrado con ejemplos, etc.). Pero no vivimos en una torre de marfil o en un libro.

A tu gran jefe no podría importarle menos el lenguaje exacto que usaste. Si sabe un poco acerca de la programación, solo dígale que usó C / C ++ y sonará como "Usé un lenguaje que necesita ser compilado en código máquina, con archivos DLL y todas las cosas complicadas". Esta es la parte de "comunicación externa".

Si crea una biblioteca que puede ser interconectada por C y C ++, definitivamente desea llamarla una biblioteca C / C ++. Por supuesto, alguien levantará una mano y preguntará por qué no llama a esto una biblioteca de C que tiene un contenedor de C ++, y de todos modos C ++ puede vincularse a las bibliotecas de C, por lo que no necesita mencionarlo en absoluto. Solo responde: "Sí, tienes razón, esta es una biblioteca C / C ++". Esta es la parte de "comunicación interna".

Si crea un analizador léxico para C ++, se sorprenderá de lo bien que funciona con C. Es posible que incluso no necesite modificarlo todo. Este es el "si parece un pato, etc." parte.

Etc.

La mayoría de los programas en C que he visto compilar (y trabajar) sin modificación como código C ++. No permita que algunas excepciones o programadores dogmáticos (aunque influyentes) engañen su intuición. C y C ++ son tan cercanos, y tan a menudo compatibles, y tan a menudo mezclados y combinados, que se utiliza el término C / C ++. Se utiliza porque es útil para describir este tipo de situaciones en las que realmente no importa si está considerando C o C ++, siempre que no sea Java o PHP . Sabemos que está "mal", pero no nos importa, es más útil que mal.

Puede ser abusado, puede ser estúpido, pero aún así, no estoy seguro de qué beneficio obtendrá al ser más pedante de lo necesario y se niega a comunicarse en términos que otros entiendan. Si se siente incómodo en alguna situación específica, simplemente no use el término genérico C / C ++, sino el relevante para el caso (C o C ++).

No tengas miedo del futuro. Nuestros sistemas operativos están escritos en C. Gran parte de la producción actual de software C / C ++ ocurre en C ++. Esta pareja está aquí para quedarse por bastante tiempo. Nadie tiene interés en que uno sea más incompatible con el otro (al contrario, en realidad).

Para ser específico sobre sus puntos:

1) depende. Sí, cuando podría generar confusión, cuando te sientas incómodo o cuando simplemente esté mal o fuera de contexto. No cuando crees que es adecuado.

2) N / A

3) Creo que no, pero no tengo bola de cristal.

4) ni idea

5) No lo creo, ya que nada empuja en esta dirección

Yendo en contra de la corriente, diría que depende del contexto .

El término "C / C ++" generalmente no es apropiado cuando se dice algo como "este es un programa C / C ++", pero esto se ha explorado en profundidad en otras respuestas.

Sin embargo, puede haber contextos donde C / C ++ puede ser apropiado.

• Hay varias bibliotecas que generalmente tienen una API C y una C ++. Supongo que no está lejos de la verdad si llamas a una biblioteca C / C ++. A los humanos nos gusta comprimir información, por lo que decir "opencv es una biblioteca C / C ++" es breve, claro y comprensible, compárelo con decir "opencv es una biblioteca, que se envía con encabezados tanto para C como para C ++".
• Puede hablar sobre diseño de lenguaje y sintaxis. Desde el punto de vista de la sintaxis del lenguaje, se podría decir que un lenguaje tiene una sintaxis similar a C / C ++.
• Organiza un concurso de codificación y acepta ambas soluciones escritas en C y en C ++
• Está contratando un nuevo programador, y la mayoría de las tareas serán C o C ++, por lo que se espera que el programador conozca ambos lenguajes. Es común en el desarrollo integrado, donde C es más adecuado para algunos microcontroladores (generalmente muy pequeños) y C ++ para otros. En este caso, podría decir que está buscando un programador C / C ++.

En general, los usuarios de SO le preguntan a la persona que hace la pregunta que elija un lenguaje: C o C ++. ¿Por qué?

Hay muchas diferencias sutiles entre C y C ++. Por ejemplo, en C ++, una constvariable de alcance global tiene un enlace interno a menos que se declare extern, pero en C tiene un enlace externo a menos que se declare static. Al decir "C / C ++", el OP está afirmando que la respuesta a su pregunta es la misma tanto en C como en C ++, cuando muy bien podría no serlo. Esto innecesariamente hace las cosas más difíciles para los aspirantes a responder.

• A veces podemos detectar que el código no es válido en un idioma u otro (por ejemplo, las conversiones implícitas de void*un puntero a un objeto no son válidas en C ++). Esto es molesto. ¿Por qué dice "C / C ++" cuando tiene un código válido en C pero no en C ++? ¿Pretendía C, o es solo un error en el código destinado a ser C ++?

• A veces, la respuesta será diferente según el lenguaje (por ejemplo, existen matrices de longitud variable en C99 pero no en C ++). Si no sabemos de qué idioma estás hablando, tenemos que adivinar o escribir una respuesta para ambos cuando solo uno será realmente útil, porque sabes qué idioma estás usando en realidad; ¡simplemente no nos estás diciendo!

• A veces la respuesta realmente es la misma para ambos idiomas, pero es difícil estar seguro. Por ejemplo, creo que C y C ++ tienen las mismas reglas de conversión de enteros, pero para estar realmente seguro, tengo que leer ambos estándares cuidadosamente. Nuevamente, esto me hace hacer el doble de trabajo que sea necesario cuando probablemente solo te interese uno de los idiomas.

De todos modos, para responder a sus otras preguntas:

1. Si.

2. Si está enlazando código C y C ++, es aceptable usar ambas etiquetas, pero especifique en qué idioma está cada archivo.

3. A veces hay cambios importantes, pero son raros y generalmente tienen un impacto limitado (de lo contrario, no se aprueban). Por ejemplo, autoen C ++ 11.

4. No creo que colaboren directamente, pero prestan atención a los desarrollos en el otro idioma y tratan de evitar introducir cambios que dificulten la compatibilidad.

Y si realmente quieres saber sobre ambos idiomas, está bien, y puedes decir eso en tu pregunta. Cuando dices "C / C ++", realmente no estoy seguro de lo que quieres decir, y realmente parece que estás asumiendo los dos idiomas.

Siempre me dijeron que C es un subconjunto de C ++ o C ++ es C con clases. Y eso fue cierto hasta la aparición de C ++ x0, C ++ 11 (o el C ++ moderno 14/11/17 en general).

C nunca ha sido un subconjunto de C ++. Por ejemplo, C89 no es un subconjunto de C ++ 98.

Algunos ejemplos:

• el formulario de lista de identificadores C89 para la declaración de parámetros de función no se admite en C ++
• C89 y C ++ 98 tienen diferentes tipos para las constantes de caracteres
• C89 y C ++ 98 tienen diferentes tipos para literales de cadena
• Los operadores lógicos producen diferentes tipos en C89 y C ++ 98 ( intvs bool)

1. ¿Debo dejar de usar el término C / C ++?

Si.

2. Si la respuesta a # 1 es sí, ¿cómo llamaría a un programa que usa una combinación de C y C ++?

Un programa es C o C ++ (si incluso un programa muy básico puede compilarse con un compilador C o C ++). ¿Qué compilador estás usando para compilarlo? Debería responder a tu pregunta. Harbison y Steele acuñaron el término Clean C para designar un subconjunto común de C y C ++, pero creo que fue una mala idea.

EDITAR : Sin embargo, admito que técnicamente puede vincular archivos de objetos C y C ++ en un solo programa, pero OTH hay muchos lenguajes que se pueden mezclar en un solo programa, por ejemplo, Java y C ++. Creo que usar el término programa C / C ++ solo aumenta la confusión de que está escrito en un solo lenguaje llamado C / C ++.

3. Dado que ambos son lenguajes 'diferentes', es probable que en algún momento los compiladores de C ++ dejen de admitir código escrito en el lenguaje C (dado que el C ++ moderno está divergiendo de la mentalidad C para cosas básicas como punteros, manejo dinámico de memoria, etc.)

Hay muchas características (ejemplo: matriz de longitud variable, miembro de matriz flexible _Generic, ...) de C99 o C11 que no son compatibles con ninguna versión de C ++.

Algunos programas están escritos en una mezcla de C y C ++

Esto es solo un hecho de la vida. Puede compilar archivos de objetos de C y C ++ y vincularlos. El resultado puede llamarse razonablemente "un programa C / C ++".

Pero ese es solo el programa en su conjunto. ¿Qué pasa con las unidades de compilación individuales?

Hay un subconjunto de C que también es un subconjunto de C ++

Un programa (o unidad de compilación) escrito en ese subconjunto compilará y se comportará igual bajo compiladores C y C ++ conformes. Tal programa o archivo puede llamarse correctamente "un programa C / C ++" o "un archivo C / C ++".

Un programa parcial, como un archivo de encabezado, también se puede usar en programas C y C ++. Dichos archivos de encabezado se pueden denominar correctamente encabezados C / C ++.

Citando al profesor Bjarne Stroustrup:

¿Es C un subconjunto de C ++?

En el sentido matemático estricto, C no es un subconjunto de C ++. Hay programas que son válidos en C pero no válidos en C ++ e incluso algunas formas de escribir código que tienen un significado diferente en C y C ++. Sin embargo, C ++ admite todas las técnicas de programación compatibles con C. Todos los programas de C se pueden escribir esencialmente de la misma manera en C ++ con la misma eficiencia de tiempo de ejecución y espacio. No es raro poder convertir decenas de miles de líneas de ANSI C a C ++ estilo C en pocas horas. Por lo tanto, C ++ es tanto un superconjunto de ANSI C como ANSI C es un superconjunto de K&R C y tanto como ISO C ++ es un superconjunto de C ++ como existía en 1985.

C bien escrito tiende a ser legal C ++ también. Por ejemplo, cada ejemplo en Kernighan & Ritchie: "El lenguaje de programación C (2ª edición)" también es un programa C ++.

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

Entonces sí, existe algo como C / C ++. Es cualquier cosa que sea tanto C válida como C ++ válida.

El preprocesador C es parte del lenguaje C. El preprocesador de C ++ es parte del lenguaje C ++

Puede escribir una unidad de compilación que compilará en C o C ++ y será diferente . Por ejemplo, podría tener una funcionalidad básica compilada en C pero aprovechar una biblioteca C ++ si se compila en C ++.

Si el programa es esencialmente el mismo, pero con características adicionales, no es exactamente incorrecto decir que es el mismo programa. Es lo mismo, pero también diferente.

La mayoría de los programadores de C pueden hacer al menos un poco de C ++ y viceversa.

No es irrazonable llamar a esa persona programador de C / C ++. Sí, probablemente se especialicen en uno, pero ¿hay alguien que sea un programador competente de C o C ++ que, literalmente, no pueda hacer ningún otro lenguaje? En cierto modo, ¿no son todos programadores de C / C ++?

No hay nada de malo en decir "C / C ++". Lo que importa se entiende

El idioma inglés no es una herramienta para expresar silogismos . Usted puede utilizar el Inglés para la lógica, pero por muy poco, y con gran esfuerzo.

Esto se debe a que las palabras no tienen naturalmente significados exactos, sino más bien una vaga nube de denotaciones y connotaciones. Lo que importa es si la gente entiende lo que estás diciendo.

1. ¿Debo dejar de usar el término C / C ++?

Absolutamente. No está claro qué pretende expresar esta construcción, excepto, tal vez, la confusión acerca de qué son C y C ++ en nombre de la persona que usa el término.

Dado que esta confusión es una fuente de frustración tan común, muchas personas se han vuelto bastante emocionadas al respecto y la sola aparición de ese término será motivo suficiente para que se vuelvan negativas sobre su contribución. Esto puede parecer una tontería, pero parece ser lo que tenemos.

Recomiendo que en lugar de hablar de "C / C ++" utilice un término que realmente aclare lo que quiere decir.

• Si usted está hablando de algo en C que podría o no podría también ser verdad para C ++, simplemente diga C .

  Ejemplo: ¿Cómo debe maindeclararse la función en C?

  Al principio, puede parecer que la respuesta para C ++ es la misma: int main()o int main(int, char**). Pero a medida que avanza la discusión, podría ser relevante señalar que en C ++, la función debe declararse a nivel global, lo que no tiene sentido en C, porque no tiene namespaces. Por otro lado, C permite llamar mainrecursivamente mientras que C ++ no. En C ++, hay una implícita return 0;si se "cae", mainpero en C la returndeclaración es obligatoria en cualquier ruta. La lista continúa y hace que la discusión sea mucho más simple si dejas en claro de antemano cuál es el idioma a discutir.

• Si está hablando de algo en C ++ que podría o no ser cierto para C, simplemente diga C ++ .

  Ejemplo: ¿Una malloc()matriz ed de ints inicialmente será todo ceros en C ++?

  La respuesta corta para C resulta ser la misma: no. Pero a medida que avanza la respuesta, podría valer la pena señalar que en C, callocsería una buena alternativa, mientras que en C ++, usar un std::vector<int>podría haber sido una mejor opción en primer lugar.

• Si desea señalar una similitud entre C y C ++, diga C y C ++ .

  Ejemplo: en C y C ++, se define sizeofuna intimplementación y puede variar entre compiladores y arquitecturas.

  Aquí, queremos señalar que C y C ++ se comportan de la misma manera. Estamos hablando explícitamente de ambos idiomas.

De hecho, le recomiendo que sea aún más específico y no solo hable sobre "C" o "C ++" sino también sobre la versión precisa. Ambos idiomas están evolucionando y una declaración contundente como

C ++ admite /* … */y // …comenta mientras que C solo admite el /* … */estilo.

No es ni correcto ni incorrecto.

2. Si la respuesta a # 1 es sí, ¿cómo llamaría a un programa que usa una combinación de C y C ++?

Como los lenguajes se superponen, cada programa en C contendrá partes que podrían parecerse a C ++ y viceversa. Sin embargo, los autores probablemente habrán decidido utilizar un compilador C o C ++. Entonces, diga "el programa está escrito en C " si está compilado con un compilador de C y "el programa está escrito en C ++ " si usan un compilador de C ++, incluso si pueden negarse a usar las características modernas de C ++. Algunas personas se refieren a código C ++ como C-style C ++ . La ausencia de sobrecarga, excepciones, polimorfismo, plantillas y flujos de E / S son características comunes de dicho código.

Si, en cambio, algunos archivos se escriben en C y se compilan con un compilador de C y algunos otros archivos se escriben en C ++ y se compilan con un compilador de C ++, y luego los archivos de objetos se vinculan entre sí, diría que "el programa se escribe en un mezcla de C y C ++ "como, de hecho, ya lo hizo.

Sin embargo, si, en cambio, los autores se preocuparon por escribir todos y cada uno de los archivos de tal manera que puedan compilarse con un compilador de C o C ++ y el programa resultante haría lo mismo, podría decir que "el programa está escrito en un subconjunto común de C y C ++ ".

Este último suele ser el caso de los archivos de encabezado que deben compartirse entre el código C y C ++. Escribir dicho código no es fácil, por cierto. Si desea enfatizar aún más que solo se usaron tales construcciones que son válidas en C y C ++ y que son ampliamente compatibles con diferentes proveedores de compiladores, el término un subconjunto común portátil de C y C ++ puede usarse para enfatizar esto.

3. Dado que ambos son lenguajes "diferentes", ¿es probable que en algún momento los compiladores de C ++ dejen de admitir código escrito en el lenguaje C (dado que el C ++ moderno está divergiendo de la mentalidad C para cosas básicas como punteros, manejo dinámico de memoria, etc.)?

No estoy seguro de entender esta pregunta. Como C y C ++ son lenguajes diferentes, no puede esperar que un compilador para uno acepte un programa escrito para el otro. Sin embargo, los compiladores a menudo se diseñan de forma modular y si un compilador tiene una interfaz C ++ , es muy probable que también tenga una interfaz C. (A continuación, seleccionaría cuál de ellos desea mediante un interruptor de línea de comando o un medio similar). Mientras ambos idiomas se usen ampliamente, parece muy poco probable que esto cambie. Su punto de vista sobre "C ++ moderno" creo que es básicamente una cuestión de buenos estándares de codificación y la biblioteca estándar. Desde el punto de vista del compilador , la evolución de ambos idiomas es más bien convergente que divergente.

4. ¿Existe ahora alguna colaboración entre las personas que hacen los estándares de C / C ++ para mantener la compatibilidad?

Si. El modelo de memoria y la biblioteca de operaciones atómicas introducidas en C ++ 11 y C11 es un buen ejemplo. Parece que los diseñadores de ambos idiomas se dan cuenta de que la compatibilidad es importante y están trabajando para mejorarla. Personalmente, desearía que la colaboración fuera más intensa y los dos grupos de trabajo de ISO quizás incluso se unieran, pero mis deseos no son importantes.

Bjarne Stroustrup habla sobre las diferencias y los puntos en común entre las diversas versiones de C y C ++ en § 44.3 de la cuarta edición del lenguaje de programación C ++ que, irónicamente, se titula "Compatibilidad C / C ++". El uso del término podría ser apropiado en este caso, ya que está claro lo que significa.

5. Si el número 4 es sí, dicha colaboración podría terminar en un futuro próximo con la aparición del moderno C ++ (14/11/17)

Como se discutió anteriormente, sucedió en C ++ 11 y se espera / espera / necesita que vuelva a suceder.

C / C ++ es la intersección de C y C ++.

int new;no es C / C ++, y tampoco lo es vector<int> foo;.

Del mismo modo, C89 / C99 es la intersección de estos dos lenguajes, donde ninguno enum bool { false, true };o for(int i = 0;;)está permitido.

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

Es posible escribir código que compila (y se ejecuta correctamente) en C ++ 11 y C ++ 14, aunque compilar en uno no implica que se compila en el otro. De hecho, mucha gente hace esto.

Y mucha gente escribe código que funciona en C y C ++.

Obviamente, cuanto mayor es la superposición, más sentido tiene; No espero ver ninguna pregunta sobre el código C / C ++ / Java.

Aunque "tiene sentido" hablar de un subconjunto común de estos lenguajes, muchas preguntas no tendrán respuestas en este subconjunto, por ejemplo, ¿Qué debería devolver main () en C y C ++?

Pero puede hablar sobre el código que funciona para múltiples especificaciones de idioma, ya sea que esas especificaciones estén diferenciadas por "versión" o "nombre de idioma" o de otra manera.

Esta es una especie de respuesta a la posición de que "este es un código para programadores que trabajan cerca del metal y está bien en un contexto de gestión" visto en algunas de las otras respuestas y comentarios.

Yo diría que incluso esa interpretación debe tomarse con cuidado.

Comenzando por lo menos a mediados de los 90, si quisieras que un programador de C ++ y alguien que se describiera como un programador de C aplicara, habrías tenido que preguntar cuánto saben sobre el diseño orientado a objetos, cuánta experiencia tienen con la depuración de un objeto contexto orientado y sobre su capacidad para usar bibliotecas de plantillas. Desea investigar exactamente esos problemas durante la entrevista y el proceso de contratación.

Por otro lado, ha pasado más de una década desde que los gurús de C ++ comenzaron a impulsar "C ++ moderno", lo que significa un énfasis en alejarse de los punteros desnudos a objetos de puntero más seguros y modismos basados ​​en iteradores. Con la aparición de C ++ 11, ahora existe un soporte explícito para la programación de paradigmas múltiples y el impulso hacia el código que no muestra punteros es muy fuerte. Lo que eso significa es que si entrevistara a un programador de C ++ para un puesto en C hoy, estaría muy preocupado por comprobar qué tan familiarizada estaba esta persona con los punteros reales habilitados para disparar los pies.

No estoy en el negocio en estos días (incluso en la medida en que lo estaba cuando Stack Overflow estaba en su infancia), por lo que no me aventuraré a adivinar con qué frecuencia ninguno de los entrevistados imaginarios tendría las habilidades de cruce, pero Creo que, como se aplica con mayor frecuencia, los idiomas ahora son muy diferentes.

En resumen, "C / C ++" debería descartarse no solo en contextos técnicos sino también en la mayoría de los contextos comerciales.

La respuesta más simple a esta pregunta es que nunca debiste haber usado ese término. Es un término que no debería existir. No tiene sentido Cada programa es C o C ++.

Y eso fue cierto hasta la aparición de C ++ x0, C ++ 11 (o el C ++ moderno 14/11/17 en general).

C ++ 98 y 03 tampoco son remotamente C con Clases tampoco. Quien te enseñó esto no sabe una mierda y puedes olvidarlo. Esto nunca fue correcto.

Conceptualmente, no debería haber ninguna dificultad particular con el diseño de archivos fuente de C para que también puedan compilarse tal cual con C ++. De hecho, puede haber algunas ventajas significativas para hacer esto. Por ejemplo, al escribir código para un sistema embebido, a veces es útil poder probar el código en un entorno de PC alojado. Si el código se compila limpiamente como C ++, es posible tener una declaración como "MOTOR_ENABLE = 1;" escriba en un bit de E / S volátil en el sistema incorporado (compilado como C), pero active la lógica de emulación en la PC (compilando como C ++). Probablemente también sea posible diseñar un tipo C ++ en la PC que se comportaría de la misma manera que un uint16_t se comporta en sistemas embebidos más pequeños (de modo que, por ejemplo u16 x=65533;, un compilador tendría que considerar el valor dex*xcomo nueve, en lugar de tener un reinado libre para hacer lo que quiera), aunque todavía ninguno de mis emuladores lo ha incluido [en parte porque los compiladores de C ++ que he usado no han hecho nada raro en tales casos].

Desafortunadamente, los programadores de C y los programadores de C ++ tienen suficiente antipatía entre sí que los lenguajes, a lo largo de los años, han evolucionado de manera compatible. Si bien C89 intentó adaptar algunas de las características más útiles de C ++ (como los prototipos de función) parece haber surgido una actitud de que los programadores que desean cualquiera de las características de C ++ deberían usar C ++, ignorando el hecho de que hay muchas situaciones en las que Ser útil para poder usar algunas de las características de C ++ (por ejemplo, la capacidad de sobrecargar funciones con enlaces estáticos o en línea estáticos sin tener que aceptar los costos asociados con otras características que no se necesitan (por ejemplo, el cambio de nombre asociado con la exportación funciones sobrecargadas).

Si bien la intersección de C89 y C ++ 98 es un lenguaje viable, el superconjunto utilizable de versiones posteriores de C con versiones posteriores de C ++ probablemente se ha reducido en lugar de crecer (gracias a cosas como la Regla de alias estricto) y las tendencias favorecen una fisura creciente.