http://jdgarcia-vision.blogspot.com/2011/08/estandar-c-reunion-de-bloomington.html

De todas formas, D todavía no está suficientemente maduro como para iniciar un proyecto en él, por eso sigo con C++, aunque creo que es un lenguaje a tener MUY en cuenta para futuros desarrollos, de ahí que te hiciese la pregunta (y muchas gracias por la respuesta).

Pero antes de iniciar un proyecto piensa en un punto importantísimo: más que la disyuntiva C++ / D, ¿existen librerías en D que te den la funcionalidad que vas a necesitar?

Las ventajas principales de C y C++ es que existen literalmente miles de librerías para absolutamente cualquier cosa que necesites… Casi todas las librerías de otros lenguajes (perl, Python,…) realmente son «bindings» a librerías originales en C/C++.

Aún así, creo que C++ no es todo lo claro que debería ser; vamos, para mí es bastante «enrevesado», por eso últimamente me estoy interesando bastante por el lenguaje D (http://www.digitalmars.com/d/2.0/index.html ) y me gustaría saber qué opinas del mismo.

Un saludo.

Vamos, lo que de toda la vida hemos apañado creando métodos «copy()» y «copyRemoveSource()», o incluso métodos swap() específicas dentro de los tipos como T::swap(T&o) que internamente eviten copiar bloques de memoria y solamente hagan swap() de punteros.

Pero en vez de cada uno inventarnos nuestros nombres para esos métodos, ahora se podrá hacer todo con constructores normales y operator =() que acepten de entrada T&&, que se sacan de la nueva template «std::move()», y así unificar un poco criterios; y a quien no se le ocurriesen estas fricadas, pues que se enteren ya y empiecen a no desperdiciar el potencial de C++ 😉

Mira esto: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html

De todas maneras, la única de estas cosas que pinta bien es lo de las plantillas con argumentos variables, y en menor medida las funciones lambda anónimas.

Lo de meter más cosas en la STL no me acaba de gustar, prefiero tener un lenguaje pequeño y bibliotecas aparte (o hacértelas tú misma). Lo contrario lleva a no hacer código optimizado con la excusa perenne de «no reinventar la rueda».

Eso de las referencias a referencias, ¿no es un simple puntero?