Unix fue reescrito en C. De hecho, (creo que) Dennis Ritchie lo inventó precisamente para reprogramar Unix.

Por ahí en la jungla de Internet existen discusiones entre desarrolladores de Linux sobre migrar el núcleo a C++, pero nah, la mayoría no quiere jaja.

Aunque solamente se guarden 3 números diferentes, no hay ningún "patrón" que puedas sacar, así que no te queda otra que un vector.

O!! la solución de Stakewinner00, que hace lo que pides perfectamente, aunque la descripción de tu ejercicio dice que debes almacenarlos (te está diciendo claramente que uses un vector), pero bueno.

Otra solución (no la he probado, pero debería funcionar):

#include <iostream>
 
int main()
{
  unsigned mes, dia; std::cin >> mes >> dia;
 
  unsigned dias[] = {
        31, 30, 28, 30, 31, 30,
        31, 31, 30, 31, 30, 31
  };
 
  dias[mes - 1] = dia;
 
  unsigned diaanno = 0;
 
  while (mes --> 0)
      diaanno += dias[mes];
 
  std::cout << diaanno << std::endl;
 
  return 1;
}

Has puesto la resolución de ámbito mal:

#include <Partit.h> //éste es el archivo donde tengo las clases declaradas
 
#include <iomanip>
#include <iostream>
using namespace std;
 
ostream& CPartit::operator<<(ostream& os, const CPartit&)
{
    os << local << gols_local << ':' << visitant << gols_visitant;
    return os;
}

Yo tampoco es que sea un experto, pero el funcionamiento general (hasta lo que yo sé) de la memoria de un programa es el siguiente:

• Todo programa tiene una capacidad máxima de memoria (estática + dinámica) igual a la capacidad máxima de RAM. Por ejemplo, una arquitectura de 32 bits tiene puede tener como máximo 4 GB de RAM, y por tanto, esa es también la capacidad máxima de memoria de CADA programa. Para arquitecturas de 64 bits, pues el máximo (ésta vez teórico) de memoria sería de 16 Exabytes (debido a que 16 EB es una barbaridad, ningún sistema operativo soporta todavía tanta memoria; todavían van por el órden de soportar algunos terabytes). Si cada programa tiene 4GB de RAM como máximo, y tu ordenador puede tener 4 GB de RAM como máximo también, y tienes dos programas que juntos suman más de 4GB, ¿qué es lo que pasa? Pues que entra en juego la memoria virtual, que es memoria de disco duro que se utiliza para los programas. Eso lo hace el SO por tí; como programador, tú crees que tienes 4GB continuos de memoria RAM como máximo.
• Cada SO pone un límite máximo en la cantidad de memoria para variables locales (tamaño de la pila, o stack), que un programa puede tener. En mi SO (Linux 3.13), la pila no puede ser más grande que 8 MB. Es decir, si mi programa tuviese una única variable local, la más grande que podría tener sería: `char var[8388608]`, o dos vectores `double[524288]`. De todas formas, aquí se me escapan los detalles, pero sé que siempre hay cierto porcentaje de la pila que el compilador utiliza para sí mismo, así que la correspondencia "variables locales del programa"/"tamaño actual de la pila", es en realidad muy difícil de calcular.
• En cualquier momento del programa, la memoria dinámica (es decir, el llamado montículo o heap; la memoria que consigues con `malloc/new`) disponible es: la máxima del programa, menos la consumida actualmente por la pila, menos otros factores adicionales que también consumen espacio. Obviando ésto último por simplicidad, si tengo un máximo de 4GB de RAM (arquitectura de 32 bits), y la pila llena (si el máximo es de 8MB, como en mi caso), pues sobrarían 3GB y 1018MB para variables locales.
  

La diferencia entre la pila y el montículo, es que la pila funciona como una pila de platos, cada nueva variable local, se coloca justo encima en la memoria de la última variable local creada. Cuando termina una función, se descartan, quitándolos de la cima de la pila, todas las variables locales y parámetros de la función, de modo que la "nueva cima", era la misma que antes de que la función fuera llamada. Como bien dice "Engel Lex", la memoria no se borra, solo se "reutiliza" (una vez que la función termina, ese espacio vuelve a estar disponible).

Respecto al montículo también funciona como una pila de platos, pero un poco diferente; algo así como una pila fragmentada. En teoría (en realidad, cada SO puede tener sus propias políticas para manejar el montículo), cada vez que tú pides al SO un nuevo dato dinámico (`malloc`/`new`), él lo coloca encima del último dato dinámico creado. Si se borra un objeto dinámico (free/delete), se queda un hueco libre en medio de la pila (y reutilizable), pero el tope del montículo sigue siendo el mismo. Ésto se diferencia de la pila en que la pila funciona como un muelle que se estira y se encoje a medida que se llaman a nuevas funciones y éstas terminan, mientras que el montículo es una "pila fija", destruir un objeto nunca "encoje" el montículo, sino que deja huecos entre medio.

Cuando has solicitado tantos objetos que el montículo ha llegado a su tope, entonces cuando solicites un nuevo objeto dinámico al SO, éste empezará a buscar un hueco en medio del montículo lo suficientemente grande para dicha variable, y lo colocará ahí. Si no quedase un hueco lo suficientemente grande, la verdad es que no sé qué haría el sistema operativo (puede que reordene el montículo para juntar huecos y conseguir un hueco más grande --al igual que cuando desfragmentas un disco duro; lo que no creo, porque invalidaría los punteros; o puede que sencillamente te diga que no queda memoria, ¡aunque la suma de huecos sea lo suficientemente grande!).

Por último, hay que tener en cuenta que, como el montículo puede ser enorme, el SO te "virtualiza" el montículo para que lo veas como una pila contigua con huecos, cuando en realidad, cada "trozo" de montículo puede estar colocado en diferentes lugares de la RAM y memoria virtual (disco duro). Si has reservado memoria para un objeto, y éste se encuentra actualmente en disco y no en RAM, y quieres "utilizar" dicho objeto (acceder a un campo de él por ejemplo), el SO cogerá el "trozo" de memoria virtual (página), que contiene a tu objeto, y lo colocará en RAM, y posiblemente, cogerá un trozo de RAM que ahora mismo tu programa no esté utilizando, y lo enviará a disco como intercambio (aunque si hay suficiente RAM disponible, seguramente evitará ésto último). Así que el sistema operativo se encarga de mover las páginas de memoria virtual entre disco y RAM a medida que vas utilizando tus objetos dinámicos. Por ese motivo, aunque el montículo sea enorme y uno tenga la tentación de enviarlo todo allí, utilizar el montículo siempre es MUCHÍSIMO más lento que utilizar la pila.

Ahora, teniendo en cuenta todo ésto, ¿qué ocurre con el montículo (memoria dinámica) cuando el programa termina? Pues el SO mantiene un rastreo de toda la memoria dinámica que ha consumido el programa, y cuando éste termina, la elimina. Así que un programa finalizado no dejará memoria utilizada, ni en RAM, ni en memoria virtual.

Con la pila pasa lo mismo, y además con una ventaja. Como la pila nunca está en memoria virtual, y es como un bloque fijo en la RAM, solo hay que quitar dicho bloque de la RAM y listo. Eso no supone ningún problema para ningún SO, y no necesitan "rastrear" nada, con saber dónde empieza la pila y donde acaba es suficiente (y por éste motivo, los SOs restringen los tamaños de las pilas --compara 8MB de pila con 4 gigas de RAM; para que todas las pilas de todos los programas y del SO estén en RAM siempre).

De todas formas, aunque el SO libere toda la memoria de tu programa sin problemas, DEBES liberar toda memoria que hayas consumido en cuánto ya no la necesites. No solo para evitar el riesgo de que tu propio programa se quede sin memoria (lo cuál es muy raro, ya que con 32 bits tienes 4GB de RAM, y si tu arquitectura es de 64bits, pues mucho más), sino para evitar el riesgo de que tu "ordenador como un todo", se quede sin memoria mientras tu programa está aún en ejecución.

Date cuenta que, aunque cada programa tenga 4GB de RAM como máximo, tu programa podría ejecutarse en un ordenador con 2GB físicos de RAM (por que, por ejemplo, el dueño decidió no comprar otra tarjeta de memoria RAM adicional para completar los 4 GB). Además, la cantidad de memoria de disco que puede utilizar el SO también está limitado, y un usuario de tu programa puede tener configurado su sistema operativo para que la memoria virtual no consuma demasiado espacio en disco (el trozo de disco duro que el SO reserva para colocar páginas de memoria virtual se llama memoria de intercambio). Un motivo para hacer ésto, es que cuánto más pequeña sea la memoria de intercambio, más probable es que el SO coloque páginas de memoria virtual en RAM en vez de en disco (para evitar que la memoria virtual se llene), haciendo que todos los programas vayan más rápido.

Sea por lo que sea, SIEMPRE borra tu memoria dinámica en cuánto no la necesites. Si los programadores no liberaran nunca la memoria porque el SO hace el resto, en cuánto tuvieses 4 o 5 programas abiertos, más todos los servicios y demonios que se ejecutan en segundo plano, más el propio sistema operativo en sí, podrías quedarte sin memoria (a no ser que cierres una de las aplicaciones).

Así también es una opción:

++num_characters;
 
while (num_characters-- > 0)
    printf("%u ", num_characters);

Y si desplazas el postdecremento una posición:

++num_characters;
 
while (num_characters --> 0)
   printf("%u ", num_characters);

parece una flechita

Bueno, es bastante obvio, viendo las dos primeras líneas del programa, que está programando en C++.

Todo programa debe tener una única función llamada `main`, aunque tengas varios `cpp`. Cuando tu ejecutas una aplicación, el sistema le "da paso" llamado a su función `main`. Es el convenio seguido para que el SO pueda "darle el control" a tu aplicación.

Cuando uno tiene varios `.cpp`,  y los compilas, el compilador genera un fichero binario (llamado código objeto, con extensión `.o`), por cada `cpp`, y luego un programa llamado enlazador une todos los `.o` en un único fichero binario ejecutable.

Es ese fichero final el que importa; y ese único fichero final es tu programa, y ahí reside `main`. Como verás, no hay ninguna magia en "saber donde está el `main`".

Si tuvieras un `.cpp` sin `main`, e intentases crear un ejecutable, el enlazador te chillaría diciendo que no encuentra `main`. Si hubiese varias funciones (o varias globales, como en tu caso) llamadas igual, también chillaría. Y supongo que si tuvieses dos `main`, chillaría el doble.

sizeof(char) == 1. El estándar no dice que ésto signifique un byte: para el estándar, un `char`es la unidad mínima de memoria, y por defecto `sizeof(char) == 1`, y cualquier otro tipo se mide en X veces un char. Así, `sizeof(int) == 4` significa que un `int` ocupa lo mismo que 4 `char`s (`char[4]`).

Cuánto ocupe en bytes un `char`se deja a mano del compilador, pero es universalmente 1 y no te vas a encontrar un contraejemplo.

Si te interesa la historia de la informática, con ésto lo "vas a flipar". Ésta muy chulo, la historia personal de un informático que estuvo entre la primera generación de programadores de España. Muchos detalles, y cuenta con mucho detalle (y de forma muy entretenida), cómo era programar por esos tiempos:

http://eltamiz.com/elcedazo/series/historia-de-un-viejo-informatico/

Yo soy jóven así que no he tenido mucha experiencia por su puesto jaja, pero por lo que he leído, lo que hace que mejore la productividad no es tanto "el lenguaje", como el "paradigma".

C no fue el primer lenguaje de su paradigma (estructurado no-ensamblador), ya que Fortran o Pascal vinieron antes, pero fue ésta forma nueva de programar, basada en tipos y estructuras de control y con mayor nivel de abstracción, lo que aceleraría el desarrollo. Lo que quizás lanzó a la fama C era su capacidad de ser un lenguaje de propósito general, mientras que Fortran y Pascal eran lenguajes más basados en el cómputo numérico (por aquellos tiempos, los ordenadores se imaginaban más como un "machador de números" --algo así como una calculadora de propósito general, más que como un "machacador de símbolos" --más centrado en el algoritmo que en los datos sobre los que actúa, por eso los lenguajes de alto nivel tuvieron difícil aceptación al principio.

Por otro lado, C++ tampoco fue el primer lenguaje orientado a objetos. Creo que Smalltalk fue el primero o uno de los primeros: pero la evolución nuevamente va en dirección a la facilidad para "organizar las ideas" dentro de un código, más que las características técnicas de un lenguaje sobre otro. Luego la experiencia va dictaminando que características son más útiles que otras, pero lo que importa para acelerar el desarrollo es la abstracción y las nuevas formas de pensar más cómodas que los nuevos lenguajes van ofreciendo.

Respecto al "cuánto se agilizó el desarrollo", la verdad es que no sé decirte, pero con el enlace que te he puesto arriba, seguro que te haces una buena idea.

Perdón Stackewinner0. De todas formas, pensé que era "el autor de éste hilo" (en éste caso bash) quién había hecho esa pregunta (no me fijo mucho en quién es quién la verdad).