¿C # te da "menos cuerda para ahorcarte" que C ++? [cerrado]

Joel Spolsky caracterizó a C ++ como "suficiente cuerda para ahorcarse" . En realidad, estaba resumiendo "C ++ efectivo" de Scott Meyers:

Es un libro que básicamente dice: C ++ es suficiente cuerda para ahorcarse, y luego un par de millas extra de cuerda, y luego un par de píldoras suicidas que se disfrazan de M&M ...

No tengo una copia del libro, pero hay indicios de que gran parte del libro se relaciona con problemas de gestión de la memoria que parecen ser discutibles en C # porque el tiempo de ejecución maneja esos problemas por usted.

Aquí están mis preguntas:

1. ¿C # evita las trampas que se evitan en C ++ solo mediante una programación cuidadosa? Si es así, ¿en qué medida y cómo se evitan?
2. ¿Hay nuevas dificultades diferentes en C # que un nuevo programador de C # debe tener en cuenta? Si es así, ¿por qué no podrían evitarse con el diseño de C #?

La diferencia fundamental entre C ++ y C # proviene del comportamiento indefinido .

No tiene nada que ver con la gestión manual de la memoria. En ambos casos, ese es un problema resuelto.

C / C ++:

En C ++, cuando comete un error, el resultado no está definido.
O, si intenta hacer ciertos tipos de suposiciones sobre el sistema (por ejemplo, desbordamiento de entero con signo), es probable que su programa no esté definido.

Tal vez lea esta serie de 3 partes sobre comportamiento indefinido.

Esto es lo que hace que C ++ sea tan rápido: el compilador no tiene que preocuparse por lo que sucede cuando las cosas salen mal, por lo que puede evitar verificar la corrección.

C #, Java, etc.

En C #, tiene la garantía de que muchos errores explotarán en su cara como excepciones, y le garantizamos mucho más sobre el sistema subyacente.
Esa es una barrera fundamental para hacer que C # sea tan rápido como C ++, pero también es una barrera fundamental para hacer que C ++ sea seguro, y hace que C # sea más fácil de trabajar y depurar.

Todo lo demás es simplemente salsa.

¿C # evita las trampas que se evitan en C ++ solo mediante una programación cuidadosa? Si es así, ¿en qué medida y cómo se evitan?

La mayoría lo hace, algunas no. Y, por supuesto, hace algunos nuevos.

1. Comportamiento indefinido : el mayor obstáculo con C ++ es que hay una gran cantidad de lenguaje indefinido. El compilador literalmente puede hacer explotar el universo cuando haces estas cosas, y estará bien. Naturalmente, esto es poco común, pero es bastante común que su programa funcione bien en una máquina y realmente no tiene una buena razón para no funcionar en otra. O peor, actuar sutilmente diferente. C # tiene algunos casos de comportamiento indefinido en su especificación, pero son raros y en áreas del lenguaje que se utilizan con poca frecuencia. C ++ tiene la posibilidad de encontrarse con un comportamiento indefinido cada vez que realiza una declaración.

2. Fugas de memoria : esto es menos preocupante para C ++ moderno, pero para principiantes y durante aproximadamente la mitad de su vida útil, C ++ hizo que sea muy fácil perder memoria. C ++ efectivo vino alrededor de la evolución de las prácticas para eliminar esta preocupación. Dicho esto, C # todavía puede perder memoria. El caso más común con el que se topan las personas es la captura de eventos. Si tiene un objeto y coloca uno de sus métodos como un controlador para un evento, el propietario de ese evento debe tener GC para que el objeto muera. La mayoría de los principiantes no se dan cuenta de que el controlador de eventos cuenta como referencia. También hay problemas al no disponer de recursos desechables que pueden perder memoria, pero estos no son tan comunes como los punteros en C ++ pre-efectivo.

3. Compilación : C ++ tiene un modelo de compilación retardado. Esto lleva a una serie de trucos para jugar bien con él, y mantener bajos los tiempos de compilación.

4. Cadenas : Modern C ++ lo hace un poco mejor, pero char*es responsable del ~ 95% de todas las infracciones de seguridad antes del año 2000. Para los programadores experimentados, se centrarán std::string, pero aún es algo para evitar y un problema en las bibliotecas antiguas / peores . Y eso es rezar para que no necesites soporte Unicode.

Y realmente, esa es la punta del iceberg. El problema principal es que C ++ es un lenguaje muy pobre para principiantes. Es bastante inconsistente, y muchos de los viejos y muy malos escollos han sido resueltos cambiando los modismos. El problema es que los principiantes necesitan aprender las expresiones idiomáticas de algo como Effective C ++. C # elimina muchos de estos problemas por completo y hace que el resto sea menos preocupante hasta que avance en el camino del aprendizaje.

¿Hay nuevas dificultades diferentes en C # que un nuevo programador de C # debe tener en cuenta? Si es así, ¿por qué no podrían evitarse con el diseño de C #?

Mencioné el problema del evento "pérdida de memoria". Esto no es un problema de lenguaje, ya que el programador espera algo que el lenguaje no puede hacer.

Otra es que el finalizador para un objeto C # no está técnicamente garantizado para ser ejecutado por el tiempo de ejecución. Esto generalmente no importa, pero hace que algunas cosas se diseñen de manera diferente de lo que cabría esperar.

Otro problema que he visto a los programadores es la semántica de captura de funciones anónimas. Cuando captura una variable, captura la variable . Ejemplo:

List<Action> actions = new List<Action>();
for(int x = 0; x < 10; ++x ){
    actions.Add(() => Console.WriteLine(x));
}

foreach(var action in actions){
    action();
}

No hace lo que ingenuamente se piensa. Esto imprime10 10 veces.

Estoy seguro de que hay muchos otros que estoy olvidando, pero el problema principal es que son menos penetrantes.

En mi opinión, los peligros de C ++ son algo exagerados.

El peligro esencial es este: mientras C # le permite realizar operaciones de puntero "inseguras" utilizando unsafe palabra clave, C ++ (que en su mayoría es un superconjunto de C) le permitirá usar punteros cuando lo desee. Además de los peligros habituales inherentes al uso de punteros (que son los mismos con C), como pérdidas de memoria, desbordamientos de búfer, punteros colgantes, etc., C ++ presenta nuevas formas para que arruines las cosas.

Esta "soga extra", por así decirlo, de la que Joel Spolsky estaba hablando , básicamente se reduce a una cosa: escribir clases que manejan internamente su propia memoria, también conocida como la " Regla de 3 " (que ahora se puede llamar la Regla de 4 o regla de 5 en C ++ 11). Esto significa que si alguna vez desea escribir una clase que administre sus propias asignaciones de memoria internamente, debe saber lo que está haciendo o su programa probablemente se bloqueará. Debe crear cuidadosamente un constructor, un constructor de copia, un destructor y un operador de asignación, que es sorprendentemente fácil de equivocar, lo que a menudo resulta en extraños bloqueos en el tiempo de ejecución.

SIN EMBARGO , en la programación real de C ++ todos los días, es muy raro escribir una clase que administre su propia memoria, por lo que es engañoso decir que los programadores de C ++ siempre deben ser "cuidadosos" para evitar estos escollos. Por lo general, solo harás algo más como:

class Foo
{
    public:

    Foo(const std::string& s) 
        : m_first_name(s)
    { }

    private:

    std::string m_first_name;
};

Esta clase se parece bastante a lo que haría en Java o C #: no requiere una administración de memoria explícita (porque la clase de la biblioteca std::stringse encarga de todo eso automáticamente), y no se requiere nada de "Regla de 3" desde el valor predeterminado El constructor de copia y el operador de asignación están bien.

Solo cuando intentas hacer algo como:

class Foo
{
    public:

    Foo(const char* s)
    { 
        std::size_t len = std::strlen(s);
        m_name = new char[len + 1];
        std::strcpy(m_name, s);
    }

    Foo(const Foo& f); // must implement proper copy constructor

    Foo& operator = (const Foo& f); // must implement proper assignment operator

    ~Foo(); // must free resource in destructor

    private:

    char* m_name;
};

En este caso, puede ser complicado para los principiantes obtener la asignación, el destructor y el constructor de copia correctos. Pero para la mayoría de los casos, no hay razón para hacer esto. C ++ hace que sea muy fácil evitar la gestión manual de la memoria el 99% del tiempo mediante el uso de clases de biblioteca como std::stringy std::vector.

Otro problema relacionado es la gestión manual de la memoria de una manera que no tiene en cuenta la posibilidad de que se produzca una excepción. Me gusta:

char* s = new char[100];
some_function_which_may_throw();
/* ... */
delete[] s;

Si some_function_which_may_throw()en realidad no lanzar una excepción, uno se queda con una pérdida de memoria debido a que la memoria asignada para sque nunca se recuperó. Pero, de nuevo, en la práctica esto ya no es un problema por la misma razón por la que la "Regla de 3" ya no es realmente un problema. Es muy raro (y generalmente innecesario) administrar su propia memoria con punteros sin formato. Para evitar el problema anterior, todo lo que debe hacer es usar un std::stringo std::vector, y el destructor se invocará automáticamente durante el desenrollado de la pila después de que se haya lanzado la excepción.

Por lo tanto, un tema general aquí es que muchas características de C ++ que no se heredaron de C, como la inicialización / destrucción automática, los constructores de copias y las excepciones, obligan a un programador a tener mucho cuidado al hacer la gestión manual de la memoria en C ++. Pero, de nuevo, esto es solo un problema si tiene la intención de hacer una gestión manual de la memoria en primer lugar, lo que casi nunca es necesario cuando se tienen contenedores estándar y punteros inteligentes.

Por lo tanto, en mi opinión, aunque C ++ le proporciona una gran cantidad de soga adicional, casi nunca es necesario usarlo para ahorcarse, y las trampas de las que Joel hablaba son trivialmente fáciles de evitar en C ++ moderno.

Realmente no estaría de acuerdo. Quizás menos dificultades que C ++ tal como existía en 1985.

¿C # evita las trampas que se evitan en C ++ solo mediante una programación cuidadosa? Si es así, ¿en qué medida y cómo se evitan?

Realmente no. Reglas como la Regla de tres han perdido importancia masiva en C ++ 11 gracias a unique_ptry shared_ptrsiendo estandarizadas. Usar las clases estándar de una manera vagamente sensata no es "codificación cuidadosa", es "codificación básica". Además, la proporción de la población de C ++ que sigue siendo lo suficientemente estúpida, desinformada o ambas para hacer cosas como el manejo manual de la memoria es mucho menor que antes. La realidad es que los profesores que desean demostrar reglas como esa tienen que pasar semanas tratando de encontrar ejemplos donde aún se aplican, porque las clases estándar cubren prácticamente todos los casos de uso imaginables. Muchas técnicas efectivas de C ++ han seguido el mismo camino: el camino del dodo. Muchos de los otros no son realmente tan específicos de C ++. Déjame ver. Saltando el primer elemento, los siguientes diez son:

1. No codifique C ++ como si fuera C. Esto es realmente solo sentido común.
2. Restrinja sus interfaces y use encapsulación. OOP
3. Los escritores de códigos de inicialización de dos fases deben quemarse en la hoguera. OOP
4. Sepa qué valor tiene la semántica. ¿Es esto realmente específico de C ++?
5. Restrinja sus interfaces nuevamente, esta vez de una manera ligeramente diferente. OOP
6. Destructores virtuales. Si. Este probablemente todavía sea válido, de alguna manera. finaly overridehe ayudado a cambiar este juego en particular para mejor. Haga su destructor overridey le garantiza un buen error de compilación si hereda de alguien que no hizo su destructor virtual. Haga su clase finaly no puede aparecer un matorral pobre y heredar de ella accidentalmente sin un destructor virtual.
7. Suceden cosas malas si fallan las funciones de limpieza. Esto no es realmente específico para C ++: puede ver el mismo consejo para Java y C #, y, bueno, casi todos los lenguajes. Tener funciones de limpieza que pueden fallar es simplemente malo y no hay nada de C ++ o incluso POO sobre este elemento.
8. Tenga en cuenta cómo el orden de los constructores influye en las funciones virtuales. Hilarantemente, en Java (actual o pasado) simplemente llamaría incorrectamente la función de la clase Derivada, que es incluso peor que el comportamiento de C ++. En cualquier caso, este problema no es específico de C ++.
9. Las sobrecargas de los operadores deben comportarse como la gente espera. No muy específico Demonios, apenas es una sobrecarga específica del operador, lo mismo podría aplicarse a cualquier función; no le des un nombre y luego hagas que haga algo completamente poco intuitivo.
10. Esto en realidad ahora se considera una mala práctica. Todos los operadores de asignación muy seguros de excepciones se ocupan de la autoasignación muy bien, y la autoasignación es efectivamente un error lógico del programa, y ​​verificar la autoasignación simplemente no vale el costo de rendimiento.

Obviamente no voy a revisar todos los elementos de Effective C ++, pero la mayoría de ellos simplemente están aplicando conceptos básicos a C ++. Encontraría el mismo consejo en cualquier lenguaje de operador sobrecargado orientado a objetos con tipo de valor. Los destructores virtuales son casi el único que es una trampa de C ++ y aún es válido, aunque, posiblemente, con la finalclase de C ++ 11, no es tan válido como lo fue. Recuerde que Effective C ++ se escribió cuando la idea de aplicar OOP, y las características específicas de C ++, todavía era muy nueva. Estos elementos apenas tratan sobre las trampas de C ++ y más sobre cómo hacer frente al cambio de C y cómo usar OOP correctamente.

Editar: Las trampas de C ++ no incluyen cosas como las trampas de malloc. Quiero decir, para uno, cada error que puede encontrar en el código C también puede encontrarlo en un código C # inseguro, por lo que no es particularmente relevante, y en segundo lugar, solo porque el Estándar lo define para la interoperación no significa que su uso se considere C ++ código. El estándar también lo define goto, pero si tuviera que escribir una pila gigante de espagueti con él, lo consideraría su problema, no el idioma. Hay una gran diferencia entre "codificación cuidadosa" y "Seguir modismos básicos del idioma".

¿Hay nuevas dificultades diferentes en C # que un nuevo programador de C # debe tener en cuenta? Si es así, ¿por qué no podrían evitarse con el diseño de C #?

usingapesta Realmente lo hace. Y no tengo idea de por qué no se hizo algo mejor. Además, Base[] = Derived[]y casi todos los usos de Object, que existe porque los diseñadores originales no notaron el éxito masivo de las plantillas en C ++, y decidieron que "Hagamos que todo herede de todo y perdamos toda la seguridad de nuestro tipo" fue la elección más inteligente . También creo que puedes encontrar algunas sorpresas desagradables en cosas como las condiciones de carrera con los delegados y otras cosas divertidas. Luego hay otras cosas generales, como cómo los genéricos apestan horriblemente en comparación con las plantillas, la colocación forzada realmente innecesaria de todo en una class, y esas cosas.

¿C # evita las trampas que se evitan en C ++ solo mediante una programación cuidadosa? Si es así, ¿en qué medida y cómo se evitan?

C # tiene las ventajas de:

• Al no ser compatible con C, se evita tener una larga lista de características del lenguaje "malvadas" (por ejemplo, punteros en bruto) que son sintácticamente convenientes pero que ahora se consideran mal estilo.
• Tener una semántica de referencia en lugar de una semántica de valor, lo que hace que al menos 10 de los elementos efectivos de C ++ sean discutibles (pero introduce nuevas trampas).
• Tener menos comportamiento definido por la implementación que C ++.
  • En particular, en C ++ la codificación de caracteres de char, string, etc. es definido por la implementación. El cisma entre el enfoque de Windows para Unicode ( wchar_tpara UTF-16, charpara "páginas de códigos" obsoletas) y el enfoque * nix (UTF-8) causa grandes dificultades en el código multiplataforma. C #, OTOH, garantiza que a stringes UTF-16.

¿Hay nuevas dificultades diferentes en C # que un nuevo programador de C # debe tener en cuenta?

Si: IDisposable

¿Existe un libro equivalente a "Effective C ++" para C #?

Hay un libro llamado Effective C # que es similar en estructura a Effective C ++ .

No, C # (y Java) son menos seguros que C ++

C ++ es localmente verificable . Puedo inspeccionar una sola clase en C ++ y determinar que la clase no pierde memoria u otros recursos, suponiendo que todas las clases referenciadas sean correctas. En Java o C #, es necesario verificar cada clase referenciada para determinar si requiere algún tipo de finalización.

C ++:

{
   some_resource r(...);  // resource initialized
   ...
}  // resource destructor called, no leaks here

C#:

{
   SomeResource r = new SomeResource(...); // resource initialized
   ...
} // did I need to finalize that?  May I should have used 'using' 
  // (or in Java, a grotesque try/finally construct)?  No way to tell
  // without checking the documentation for SomeResource

C ++:

{
    auto_ptr<SomeInterface> i = SomeFactory.create(...);
    i->f(...);
} // automatic finalization and memory release.  A new implementation of
  // SomeInterface can allocate and free resources with no impact
  // on existing code

C#:

{
   SomeInterface i = SomeFactory.create(...);
   i.f(...);
   ...
} // Sure hope someone didn't create an implementation of SomeInterface
  // that requires finalization.  In C# and Java it is necessary to decide whether
  // any implementation could require finalization when the interface is defined.
  // If the initial decision is 'no finalization', then no future implementation  
  // can acquire any resource without creating potential leaks in existing code.

Sí, 100% sí, ya que creo que es imposible liberar memoria y usarla en C # (suponiendo que se administre y no entre en modo inseguro).

Pero si sabes programar en C ++, lo que no hace un número increíble de personas. Estás bastante bien. Al igual que las clases de Charles Salvia, realmente no manejan sus recuerdos, ya que todo se maneja en clases STL preexistentes. Raramente uso punteros. De hecho, fui a proyectos sin usar un solo puntero. (C ++ 11 hace esto más fácil).

En cuanto a cometer errores tipográficos, errores tontos, etc. (por ejemplo: if (i=0)bc, la clave se atascó cuando presionó == realmente rápido) el compilador se queja, lo cual es bueno, ya que mejora la calidad del código. Otro ejemplo es olvidar las breakdeclaraciones de cambio y no permitirle declarar variables estáticas en una función (que a veces no me gusta, pero es una buena idea).