utilizado - ¿Habrá(y debería) enchufes en C++ 11?
voltaje en argentina (5)
Creo que debería hacerlo, ya que muchos otros lenguajes populares admiten operaciones de socket como parte del lenguaje (no obligan al usuario a usar ninguna API específica del sistema operativo). Si ya tenemos secuencias de archivos para leer / escribir archivos locales, no veo por qué no podemos tener algún método de transferencia de datos con sockets.
¿El nuevo C ++ 11 contendrá cualquier biblioteca de socket? Para que uno pueda hacer algo de manera estándar std::socket -ish?
Al ver cómo se agregará std::thread , se siente como si también se agregaran sockets. Los enchufes estilo C son un dolor ... Se sienten extremadamente contra-intuitivos.
De todos modos: ¿Habrá enchufes C ++ en C ++ 11 (lo busqué en Google pero no pude encontrar una respuesta)? Si no, ¿tienen planes para agregar esto? Por qué por qué no)?
La página wikipedia para C ++ 0x suele estar bastante actualizada y la sección sobre cambios en la biblioteca no parece mencionar los sockets.
No habrá en C ++ 0x. Hay propuestas para agregarlos en una versión futura.
La cantidad de cosas nuevas en C ++ 0x tuvo que ser limitada para darle al comité tiempo para lidiar con todo esto a fondo.
No habrá enchufes en C ++ 11. La diferencia entre subprocesos y sockets es que los hilos implican hacer más garantías sobre ordenar, si su programa implica hilos. Para una plataforma con solo un núcleo, C ++ 11 no exige que su CPU tenga un núcleo adicional. Los zócalos, por otro lado, serían ... difíciles de implementar de forma portátil y fallar con elegancia en los sistemas que no los tienen.
No, no es. En cuanto al futuro cercano, el comité de estándares de C ++ ha creado un grupo de estudio que está desarrollando una propuesta de capa de red . Parece que van hacia un enfoque ascendente, comenzando con una capa básica de socket, y luego construyendo el soporte HTTP / etc encima de eso. Están buscando presentar la propuesta de socket básico en la reunión del comité de octubre.
En cuanto a por qué no pusieron esto en C ++ 11, eso es puramente especulativo.
Si quieres mi opinión sobre el asunto, es por esta razón.
Si está creando un programa que hace algo, que tiene una funcionalidad específica, puede elegir bibliotecas por una de dos razones. Una razón es porque esa biblioteca hace algo que es necesario para implementar su código. Y el otro es porque hace algo útil para implementar el código en general.
Es muy difícil para un diseño de un programa en particular decir: "¡Debo usar un std::vector para guardar esta lista de elementos!" El diseño de un programa no es tan específico. Si está creando un navegador web, a la idea de un navegador no le importa si contiene sus pestañas en std::vector , std::list o un objeto creado por el usuario. Ahora, algunos diseños pueden sugerir ciertas estructuras de datos. Pero rara vez el diseño dice explícitamente que algo de bajo nivel como una std::list es absolutamente esencial.
std::list podría usarse en casi cualquier programa. Como puede std::vector , std::deque , etc.
Sin embargo, si está creando un navegador web, el embotellamiento dentro de ese diseño es la creación de redes . Debe usar una biblioteca de red o escribir una capa de red usted mismo. Es un requisito fundamental de la idea.
El término que uso para el tipo anterior, para las bibliotecas que se pueden usar en cualquier cosa, son las bibliotecas de "utilidad".
Threading es una biblioteca de utilidad. El diseño puede alentar el enhebrado a través de la necesidad de responder al usuario, pero hay formas de responder sin tipeo múltiple preventivo. Por lo tanto, en la mayoría de los casos, el enhebrado es una opción de implementación. Enhebrar es por lo tanto una utilidad.
Las redes no lo son . Solo usa redes si su diseño específicamente lo requiere. No decide simplemente volcar redes en un programa. No es un detalle de implementación; es un requisito de diseño.
En mi opinión, la biblioteca estándar de C / C ++ solo debería implementar utilidades. También es por eso que estoy en contra de otras ideas de peso pesado como los analizadores XML, etc. No está mal que otras bibliotecas tengan estas cosas, pero para C y C ++, estas no son buenas opciones.