#7#9 con que se pongan a dar vueltas por el carril exterior de las rotondas lo tienen fácil para colapsar muchas de las vías principales. Con 4 o 5 taxis por rotonda yo creo que les basta.
CC #17: si te colapsan las vías, del transporte público solo se salvan metros y tal vez tranvías.
#115 Es trivial, pero esa aplicación no lo hace, por lo menos en la demo.
Y aunque lo hiciese, eso no resuelve el problema de asegurar que el voto sea único.
#111 he encontrado la cita del paper, pero de momento no he encontrado el paper completo.
Sin embargo he encontrado otro que evalúa 4 métodos de pago, incluyendo el que dices. En la descripción del sistema dice:
"In addition, the bank certifies a user’s identity (v), which is blinded by a one-way hash function (g) so that the real customer identity will not be revealed to the broker at redemption."
El anonimato es de cara al que cobra. No al sistema. El banco sabe quién ha pagado y quien ha cobrado. En un sistema de votación es necesario que el voto dea completamente anónimo.
Lo más que he encontrado hasta ahora sobre voto electrónico viable son sistemas basados en firma de anillo. Y tiene unas limitaciones tremendas. Por ejemplo creo recordar que había que votar en orden de suscripción y si alguien suscrito no votaba, la votación era inservible. También había que hacer algún apaño para que el último en votar no pudiese decidir su voto en función del resultado. Y escalaba muy mal; no recuerdo ni si se podría aplicar a nivel de mesa electoral.
#106 de hecho si el sistema no comprueba (y permite verificar) la unicidad, ¿cómo garantiza que el hash no se lo ha dado a nadie más?
Si en unas elecciones se puede elegir entre X e y, Ana vota X y recibe el hash 1, Blas vota X y recibe el hash 1 y Carlos vota X y recibe el hash 1. Resultado de las elecciones: Y gana con 2 votos y X se queda con un voto. Ana. Blas y Carlos comprueban sus respectivos resguardos y todo está en orden.
O la demos es muy pobre o el sistema es de juguete.
#89 he votado en la demo que tienen. No me ha pedido ningún tipo de autenticación, así que no parece tener en cuenta la unicidad del voto. De hecho en la documentación que he leído solo hacen hincapié en el anonimato y en la integridad.
#41 es que son tres los requisitos del voto: unicidad, anonimicidad e integridad. Y lo que no se puede es satisfacer los tres a la vez.
Si ignoras la unicidad, sí que es posible implementar un sistema que satisfaga los requisitos de anonimicidad e integridad.
#18 el tercer pilar que te falta es la unicidad, es decir, que una persona solo pueda emitir un voto válido.
Por otra parte, con firmas de grupo sí se puede conseguir. El problema es que no escala, así que es aplicable solamente a grupos pequeños. en.m.wikipedia.org/wiki/Group_signature
#107 sin benchmarks para el caso concreto que tuvieses tú no te puedo decir.
Pero hay varias cosas que hay que tener en cuenta:
Construir un std:: string alloca memoria y hace una copia del char* original, así que puede tener una penalización. Por otra parte todas las implementaciones modernas de std:: string hacen uso del small string optimization, por lo que una implementación en c++ puede ser más rápida que una en c.
El método c_str, siendo de una clase templarizada, lo más probable es que el compilador lo meta inline y no añada nada de overhead.
En c++17 dependiendo del caso se puede usar un string_view, que ahorraría la copia y la alocación.
Pero la ventaja principal de std::string sobre char* es que evita problemas.
Si tienes esta función en c:
const char * getname();
no sabes si tienes que llamar a free o no, salvo que leas la documentación o vayas al código de la función.
En c++ std:: string getname(); o std::string_view getname(); no tienen ese problema. No te tienes que preocupar de liberar la memoria y la implementación de c++ no tiene por qué ser menos eficiente que la de c.
#100 En primer lugar, std::string se puede construir implícitamente de un char * y ofrece los métodos data y c_str para obtener su char* /const char*. También tienes la opción de trabajar entonces la parte de C++ directamente con el char*. Yo lo que suelo hacer en esos casos es hacer un wrapper, para abstraerme de esos problemas (en mi experiencia son más abundantes los const_cast y los reinterpret_cast de void* porque las librerías en C se pasan por el forro el const correctness y el type safety brilla por su ausencia).
En segundo lugar eso es como decir que en Java/C#/ python tienes que estar con JNI/pinvoke/cython porque hay una librería que solo está en C.
#98 El patrón fundamental que creo que hay que saber en C++ es RAII. Si lo usas consistentemente te olvidas de los "memory leaks". Desgraciadamente los "dangling pointers" siguen siendo un problema. RAII es parecido al "using" the C# o al "with" de python, pero aplica a todos los recursos (memoria, ficheros, locks, transacciones).
Todavía hay mucho código viejo que es más bien C con clases, pero poco a poco se van imponiendo los patrones propios de C++.
El segundo punto es familiarizarse con la STL, incluso aunque no puedas usarla por restricciones del proyecto. Verás que aquí hay un montón de Chase RAIi como string, vector, fstream, unique_lock... En cppreference.com hay documentación buena, normalmente con ejemplos.
También puedes ver los vídeos de CppCon, CppNow o Meeting C++. Hay más conferencias, y casi todas suben los vídeos a YouTube. El problema es que hay muchos, y es complicado diferenciar la paja de los buenos (aunque el nivel suele ser muy bueno) y sobre todo los vídeos básicos de los avanzados. Hay un vídeo de Kate Gregory que se llama"stop teaching C" qué seguramente te pueda dar más pistas de por dónde tirar.
Y que conste que me parece que C++ tiene muchos problemas, especialmente con los templates y la metaprogramación (no por el lenguaje en sí, si no por lo que la gente se puede llegar a flipar). También es un lenguaje con un montón de corner cases y casos raros. De hecho, ahora que lo pienso, igual es mejor que te quedes en C (pero mira lo de RAII).
También puedes echarle un vistazo a Rust. Es C++ bien hecho.
#21 --193560-- 
(pero mira lo de RAII).