Si trabajas con un lenguaje orientado a objetos, el polimorfismo es una opción. Otra puede ser usar herencia. Y estoy seguro que habrá otras opciones (en las cuales no caigo en estos momentos)

En cualquier caso, la idea se reduce a tener una clase base, llámese contenedor de las cadenas, con métodos comunes a todos los casos que vayas a desarrollar (lectura, escritura, destructores, constructores etc etc etc) Y luego utilizando la idea que te parezca apropiada, derivar de esa las diferentes especializaciones que necesites.

Hasta este punto hemos tratado el cómo facilitar el desarrollo para la parte que se encargará de almacenar y tratar lo que recibiremos, pero seguimos sin responder a tu pregunta. En principio lo que sigue debería ser independiente a un lenguaje orientado o no a objetos. (mayor o menor facilidad de implementación, pero  utilizable de cualquier manera.)

¿Como seleccionar?

De alguna forma u otra vas a tener que establecer una estructura condicional o algún método para separar los elementos de un conjunto de los elementos de otro. Ten en mente que NO puedes escapar de dichas condiciones y su tratamiento, por la propia lógica de tu problema, pero SI puedes amortiguar su coste, o reducir / esconder su presencia.

¿Opciones?

Tablas de dispersión (o al menos el concepto de dispersión) (hash tables).
Supongamos que tienes 3 conjuntos diferentes (Mayúsculas, minúsculas y cualquier otra cosa). La idea sería preparar una función de dispersión (hash) que devuelva a qué conjunto pertenece el elemento que recibe.

Sabemos que según la tabla ASCII las mayúsculas (conjunto 1) van del 65 al 99. Las minúsculas (conjunto 2) del 97 al 122, y todo lo demás será del conjunto 3.

Preparamos una función o método que nos resuelva esto y cada vez que necesitemos seleccionar en qué conjunto va un elemento, la usamos.

De esta forma NO replicas la lógica sino que la llamas en repetidas ocasiones.

Ventajas: Si únicamente estás usando una función para determinar la permanencia o no de un elemento al conjunto que sea, cualquier cambio en la lógica no supondría en teoría demasiado esfuerzo ni repercusión en el resto del programa.

Si antes teníamos sólo 3, y añadimos 3 conjuntos más pero estos caen en los números 4 5 y 6, nuestra lógica anterior no se ve afectada.

Desventajas: Hay que hacer un buen diseño de la función hash para evitar falsos positivos o falsos negativos. (que te dijese que un numero cae como mayúscula, que una minúscula no lo es, cosas así)

Imagino que otros podrán ver más opciones, yo en estos momentos, veo esta.

Zepheon al respecto de tu pregunta sobre recomendaciones para empezar y luego ampliar:

Quizá no esté explícitamente indicado, pero temas al respecto hay una infinidad en el foro. La recomendación habitual suele ser que aprendas programación (abre la mente y te da una base teórica mínima necesaria).

A partir de ahí, lo más probable es que te hayas dado cuenta de qué te llama más de la informática como para decidirte en qué profundizar.

You win.

Sobre la noticia: Era de extrañar que tardasen tanto en sacar alguna estafa de este estilo. A ver si noticias de este estilo ponen a la gente un poco alerta.

Tema ventajas:

Las funciones inline tienen la ventaja de no tener la sobrecarga de saltar a la función, apilar los argumentos, luego retornar, desapilar y volver a saltar a donde estábamos.

Como se podrá ver, para funciones cortas, esto supone una gran ventaja.

bool positivo(int i){
return i>0;
}

inline bool positivo2(int i){
return i>0;
}

la función positivo va a tardar posiblemente más en realizar todo el tema de apilado y return, que la comparación. El inline te salva eso.

Añado algo: Según las optimizaciones con las que compiles, funciones sin inline definidas e implementadas en el mismo lugar, pueden ser convertidas en inline.



Tema returns:

Las funciones inline, se expanden como si fuesen macros, si. PERO lo hacen de una forma oscura y "misteriosa"

Tu ejemplo del return, no es correcto por el hecho que return devuelve a la función superior a la actual, no en la que te encuentras.

b=sfdf();

Eso si sería correcto para obtener un 0 en b.

Como ya he dicho, las funciones inline se expanden de forma similar a las macros, PERO con mucha diferencia. En este tema comentaba eso:
http://foro.elhacker.net/programacion_cc/estoy_aprendiendo-t322048.0.html

Por otro lado, no tengo el conocimiento certero de como se expanden las funciones inline, pero una aproximación podria ser esta:

b=sfdf();
//se traduce por -->
{b=0}

Posiblemente los return se asignen dentro del código "empotrado" del inline a la variable que va a ser asignada. El código de la función, obviamente estará entre llaves.

Por otro lado, tenemos que pensar, que esto al fin y al cabo es trabajo del preprocesador, que simplemente traducirá esto a un código encerrado entre llaves (recordemos que esto crea el mismo tipo de ámbito de variables que en una función) en vez de una llamada a la misma.

De esta forma, el compilador, traducirá eso a código "llano" en vez de un salto a otra posición del código.

Por la intención de robar cobre con la que iba, según dicen en la misma noticia publicada en slashdot o gizmodo.

Puedes implementar y definir funciones en los .h Poder puedes. PERO cuando tienes diversas funciones y con bastante código, es engorroso y es cuando entonces dejas en el .h las declaraciones, y en el .c / .cpp / .cc las implementas. Para que sea más fácil de leer.

Como siempre se dice, poder puedes hacerlo, pero en unos casos te puede ayudar (para dos funciones cortas y un par de defines un .cpp puede sobrar) pero tal cual vas aumentando, mejor separar para una mejor lectura. Sobretodo si estás trabajando en equipo.

Añado algo más, he estado buscando un poco de información sobre lo que preguntabas de JavaDocs, parece ser que en visual studio una de las opciones que comentan es DoxyGen, como ya has dicho. (no he buscado mucho así que es posible que haya otras)

Sobre el tema del javaDoc que comentas, eso me suena a una función del entorno de desarrollo.

Si te has acostumbrado a eclipse, por qué no te instalas el plugin CDT para usar C/C++?

En principio no le veo problema a las funciones. Salvo que si las tienes ya definidas e implementadas (tu caso) en el .h, no necesitas volver a implementarlas en el .cpp  que es posiblemente lo que esté mareando al compilador, si he entendido bien el problema. ¿Podrías aportar más datos sobre los errores?

Añado un comentario: puedes tener un "pequeño" problema que tienes ahí, es que el char es 1 byte, lo cual te permite 256 valores, y las letras suelen estar por el 60 alto si no me falla la memoria.

Entonces, estás haciendo que el char pueda estar desbordando el valor en el momento que sumes 4 letras mayúsculas (o menos todavía si son minúsculas) y que cuando llegues a 127, a la siguiente iteración te encuentres con -128 o algo por el estilo.

En el caso que el char llegue hasta 255 (que no recuerdo ahora si lo hace por defecto, si lo haría siendo unsigned) no tendrías el mismo problema salvo que llegaría un momento que te saldrías del valor representable con caracteres. A menso que sea una exigencia de alguna tarea o algo por el estilo, quizá deberáis plantearte hacer el sumatorio usando enteros (se puede hacer conversión implícita de char a entero).

Vale, te comento donde está el problema. Aviso que me remito a este post y todavía no he leído a fondo los demás puesto que veo que el problema puede estar aquí:


El problema aquí, es que según la guía de backtrack, has renombrado la carpeta linux-source-2.xxxxxx como linux.

Dos opciones al respecto: modifica el nombre de la carpeta que has modificado según la guía de backtrack para ponerla como linux-source-versión_la_que_sea o bién modifica el make para que en vez de hacer referencia a linux-source-etcetcetc haga referencia simplemente a linux.

Creo que eso en principio debería solucionar el problema

Veamo, si no me equivoco, la cuestión está en que cuando instalaste el paquete "linux-source" automáticamente extrajo el tar.bz2 en la carpeta linux-source-2.6.35.8 . Por tanto, el paso de descomprimir deberías ignorarlo.

Por si acaso, aconsejaría que volvieses a empezar, y el "open-vm.tar.bz2" de la carpeta modules, a menos que algo te especifique que lo uses, déjalo como estaba.

A menos que se me pase algo en este momento, lo que necesitas hacer es prácticamente lo mismo que en el enlace que te puse, salvo este cambio:
Como puedes ver, el antiguo 3er paso, no está.

En principio así debería irte.

Te sorprendería la cantidad de veces que nos pasa a TODOS caer en las situaciones más tontas.

Por poner el ejemplo, intentar usar el debugger en un programa, que no funcione, y después de haber perdido un buen rato pensando qué narices pasa, darte cuenta que esa no era la compilación de debugging. Por eso lo pregunté, no por darte la sensación de inferioridad, ni mucho menos, sino para que le echases un ojo a la config de debug por si las moscas. Mala suerte, supongo, si lo malinterpretaste.

Cambiando de tema, no se qué pinta ahora el tema de tu pregunta sobre html, pero que no te extrañe saber la enorme frecuencia con la que algunos ponen los ejemplos tal cual. Ejemplos sobre eso en el foro hay muchos. Aunque eso si, fallo mío por leer como leí la respuesta en aquel tema (que como ya he dicho, no se que pinta ahora).

Y por último, sobre el tema de la memoria. Es muy bonito sacar las cosas de contexto y mezclar posts que no son, ¿a qué si?

http://foro.elhacker.net/programacion_cc/mi_programa_no_libera_memoria_estoy_usando_heapdestroy_y_heapcreate-t322500.0.html

Post 1

Post2:

Igualito a lo que citaste, oiga. Hace falta volver a decir que todos hemos caído en fallos de ese estilo?


Si no te gusta que te corrijan, entonces para qué preguntas por tus fallos?

Tampoco nadie te obliga a ti a postear nada en este foro. Si no quieres que te respondan, no lo pongas, búscalo por tu cuenta. Así de simple.

Y sinceramente, no se a qué viene esto ahora.

PD: Si tienes problemas con el inglés, un posible "parche" puede ser navegar con Chrome para aquellas páginas que estén en inglés, y activar la traducción automática.