Programaci´ on 2 Curso 2015/2016 Pr´

Programación 2
Curso 2015/2016
Práctica 2
Imperial Commander (parte 2)
En esta segunda práctica se ampliará la primera práctica para permitir combates
entre escuadrones de cazas, y para la gestión del almacenamiento en ficheros de
los datos del destructor y de la nave enemiga.
1.
1.1.
Normas generales
Entrega
1. El último dı́a para entregar esta práctica es el viernes 22 de abril, hasta
las 23:59. No se admitirán entregas fuera de plazo.
2. La práctica debe tener sólo un fichero llamado “imperialCommander.cc”.
3. IMPORTANTE: si se entrega la práctica antes del 23 de marzo, hasta las 23:59, con al menos las opciones 1 a 5 del menú funcionando
correctamente, se obtendrá un punto adicional. Es decir, es posible sacar
un 11 en esta práctica. Por supuesto, aunque la práctica se entregue antes
del 23 de marzo, se podrá volver a entregar más adelante con el resto de
opciones correctamente implementadas (las prácticas se pueden entregar
más de una vez, sólo se corrige la última versión).
1.2.
Detección de plagios/copias
En el Grado en Ingenierı́a Informática, la Programación es una materia fundamental, que se aprende programando y haciendo las prácticas de las diferentes
asignaturas (y otros programas, por supuesto). Si alguien pretende aprobar las
asignaturas de programación sin programar (copiando), obviamente tendrá serios problemas en otras asignaturas o cuando intente trabajar. Concretamente,
en Programación 2 es muy difı́cil que alguien que no ha hecho las prácticas supere el examen de teorı́a, por lo que copiar una práctica es una de las peores
decisiones que se puede tomar.
La práctica debe ser un trabajo original de la persona que la entrega; en
caso de detectarse indicios de copia de una o más prácticas se suspenderá la
asignatura a todos los alumnos implicados (tanto al que copia como al que
se deja copiar), y se enviará un informe a la dirección de la EPS, para
que se tomen las medidas disciplinarias oportunas.
1.3.
Otras normas
1. La práctica se debe entregar exclusivamente a través del servidor de prácticas del departamento de Lenguajes y Sistemas Informáticos, al que se puede acceder desde la página principal del departamento ( www.dlsi.ua.es,
2
INTRODUCCIÓN
2
“Entrega de prácticas”) o directamente en la url http://pracdlsi.dlsi.
ua.es.
No se admitirán entregas por otros medios (correo electrónico, Campus Virtual, etc.).
El usuario y contraseña para entregar prácticas es el mismo que se
utiliza en el Campus Virtual.
La práctica se puede entregar varias veces, pero sólo se corregirá la
última entrega (las anteriores entregas no se borran).
2. El programa debe poder ser compilado sin errores con el compilador de
C++ existente en la distribución de Linux de los laboratorios de prácticas;
si la práctica no se puede compilar su calificación será 0. Se recomienda
compilar y probar la práctica con el autocorrector inmediatamente antes
de entregarla.
3. La corrección de la práctica se hará de forma automática, por lo que es
imprescindible respetar estrictamente los textos y los formatos de salida
que se indican en este enunciado.
4. Al principio de todos los ficheros fuente entregados se debe incluir un
comentario con el nombre y el NIF (o equivalente) de la persona que
entrega la práctica, como en el siguiente ejemplo:
// NIF
12345678X
GARCIA GARCIA, JUAN MANUEL
5. El cálculo de la nota de la práctica y su influencia en la nota final de
la asignatura se detallan en las transparencias de la presentación de la
asignatura.
2.
Introducción
Aunque es posible lanzar un solo caza al combate contra los cazas rebeldes,
es mucho más efectivo enviar un escuadrón de varios cazas. Por ese motivo,
el comandante imperial podrá enviar al combate un escuadrón formado por
uno o más de los cazas del destructor. De igual manera, el comandante rebelde
también ha decidido organizar sus cazas en escuadrones para responder a esta
nueva estratagema imperial.
3.
Funcionamiento de la práctica
En esta práctica, las opciones 1, 3 y 5 del menú, correspondientes a listar
los datos de las naves y a reparar/mejorar los cazas, no sufrirán cambios. Sin
embargo, se cambiarán las opciones para añadir cazas a la nave (opción 2) y la
opción 4 (Launch fighter) se cambiará para lanzar escuadrones de cazas en
vez de cazas individuales. Además, se añaden nuevas opciones para almacenar y
recuperar los datos de las naves de ficheros binarios, y para importar/exportar
la dotación de cazas del destructor imperial. Finalmente, se añade también la
posibilidad de recuperar datos e importar cazas desde la lı́nea de órdenes, usando
los argumentos del programa.
El nuevo menú del programa serı́a el siguiente:
3
FUNCIONAMIENTO DE LA PRÁCTICA
3
1- List ship info
2- Add fighters
3- Repair/improve fighter
4- Launch squadron
5- List enemy info
s- Save data
S- Save enemy data
l- Load data
L- Load enemy data
x- Export data
i- Import data
q- Quit
Option:
3.1.
Descripción de las opciones que cambian
Add fighters : En esta opción, la introducción de nuevos cazas en la nave se
hará en un único paso, con una cadena que indique cuántos cazas y de
qué tipo. Por ejemplo, si la cadena es:
12 tf, 3tb;8ti///2/tf
se añadirán a la nave 12 TIE-Fighters, 3 TIE-Bombers, 8 TIE-Interceptors
y finalmente otros 2 TIE-Fighters. El tipo de caza se indica con su abreviatura, y el número de cazas es el número entero inmediatamente anterior a la abreviatura. Entre números y abreviaturas puede aparecer cualquier carácter (blancos, comas, etc), siempre que no sea ni una letra ni un
número, o bien es posible que no haya nada (como en los TIE-Bombers
y TIE-Interceptors del ejemplo). El formato de estas cadenas será siempre correcto, no es necesario comprobarlo, es decir, siempre habrá parejas
de un número seguido de una abreviatura (nunca aparecerá un número
sin abreviatura, ni al revés), aunque es posible que se produzcan varios
errores:
1. El tipo de caza no es correcto (p.ej. un caza rebelde), en cuyo caso
hay que emitir el mensaje de error WRONG_FIGHTER_TYPE
2. La nave no tiene suficientes créditos para añadir esos cazas; el mensaje de error a emitir serı́a NO_FUNDS
3. Los cazas no caben en la nave (se excede la capacidad de la nave),
en cuyo caso el mensaje de error serı́a CAPACITY_EXCEEDED
Debe tenerse en cuenta que:
En todos los casos se procesará la cadena de izquierda a derecha,
pareja a pareja, y toda la parte de la cadena que sea posible. Por
ejemplo, si la nave tiene créditos para comprar los 12 TIE-Fighters
pero no para los TIE-Bombers, se añadirán los TIE-Fighters a la
nave, se emitirá el error NO_FUNDS y no se hará nada más (no se
intentarán añadir los TIE-Interceptors ni los 2 últimos TIE-Fighters
aunque podrı́a haber créditos suficientes).
Si al procesar una pareja de número y abreviatura, no caben en la
nave todos los cazas, o no tiene créditos para todos los cazas (por
3
FUNCIONAMIENTO DE LA PRÁCTICA
4
ejemplo si tiene créditos sólo para 9 TIE-Fighters de los 12), no se
añadirá ninguno.
Las abreviaturas de cazas pueden aparecer más de una vez en la
cadena, y pueden aparecer en cualquier orden.
La cadena se pedirá con el mensaje:
Enter fighters:
AVISO: la inicialización de la dotación inicial de cazas de las naves se
hará con una cadena con el mismo formato que la que se usa en esta
opción, por lo que el código que se diseñe debe servir también para la
inicialización (la dotación inicial también cuesta créditos a la nave). La
dotación inicial de las naves se representará con estas cadenas:
const string initialImperialShipDotation="10tf/ 5 tb, 5 ti, 5;ta";
// 10 TIE-Fighters, 5 TIE-Bombers, 5 TIE-Interceptors, 5 TIE-Advanced, ....
const string initialRebelShipDotation="10xw,5yw, 8aw, 5bw";
// 10 X-Wing, 5 Y-Wing, 8 A-Wing, 5 B-Wing
Por tanto, los vectores que se utilizaban en la práctica 1 para la inicialización de las naves deben sustituirse por estas cadenas, y el código debe
adaptarse a este cambio, reutilizando funciones de la opción Add fighter.
Launch squadron : esta opción sustituye a la anterior opción Launch fighter,
y tiene que hacer lo siguiente:
1. Como en la práctica anterior, se debe comprobar que ambas naves,
la imperial y la rebelde, tienen al menos un caza. Si no es ası́, se
emitirá el error NO_FIGHTERS y se volverá al menú.
2. Pedir el número de los cazas con el mensaje:
Select fighter numbers:
y leer una cadena con los números de los cazas.
3. A partir de esa cadena, se creará un escuadrón (que no es más que un
vector de cazas, vector<Fighter>), en el que se meterán los cazas
que ha indicado el usuario, eliminándolos del vector de cazas de la nave. Por ejemplo, si el usuario mete la cadena (que solo tendrá números
y blancos):
9 3 12
se extraerán los cazas 3, 9 y 12 de la nave y se meterán en el escuadrón. Es necesario implementar bien esta tarea, porque si se extrae
de la nave el caza 9, el caza número 12 pasa a ocupar la posición 11;
aunque hay otras formas de implementarlo, se debe usar la siguiente:
a) Crear un vector<int> con los números introducidos por el usuario,
b) ordenarlo de mayor a menor,
3
FUNCIONAMIENTO DE LA PRÁCTICA
5
c) extraer de la nave e insertar en el escuadrón en el orden indicado
en el vector, con lo que se empezarı́a siempre por el último, con
lo que los movimientos de naves en el vector no afectarı́an. En el
ejemplo anterior, se extraerı́a primero el 12 (que afectarı́a a las
posiciones de los cazas siguientes, pero no a las de los anteriores),
luego el 9 y finalmente el 3. Por tanto, en el escuadrón imperial
los cazas aparecerán de mayor a menor, primero el 12, luego el 9
y finalmente el 3.
Si el número de algún caza es incorrecto (p.ej. si es mayor que el
número de cazas disponibles), se debe ignorar dicho número sin emitir ningún error. Por simplificar, se debe suponer que no aparecerán
números repetidos (no es necesario comprobarlo). Si todos los números son incorrectos se debe emitir el mensaje de error WRONG_NUMBER
y salir de la opción sin hacer nada más, ya que el escuadrón imperial
estarı́a vacı́o.
4. Una vez creado el escuadrón imperial, se debe crear de forma aleatoria
el escuadrón rebelde (a partir de los cazas del jugador rebelde que
controla el programa). El escuadrón rebelde tendrá un tamaño que
será el del escuadrón imperial más un margen (el margen será un
número aleatorio entre -3 y 3), y al menos tendrá un caza; si el
tamaño calculado para el escuadrón rebelde es por ejemplo 10 y la
nave solamente tiene 7 cazas, el tamaño del escuadrón debe ser 7,
obviamente. El escuadrón rebelde se creará eligiendo al azar los cazas
de los disponibles en la nave rebelde, de la siguiente manera:
a) Se elige un número c al azar entre 0 y el número de cazas de la
nave menos 1.
b) Se mete el caza en la posición c en el escuadrón (al final).
c) Se elimina ese caza del vector de cazas de la nave.
d ) Si todavı́a no se ha completado el escuadrón según el tamaño
previsto, se vuelve al paso a).
5. Una vez creados ambos escuadrones, se debe simular el combate:
a) Inicialmente, se mostrarán ambos escuadrones,1 como en el siguiente ejemplo:
Squadron A
[1] TIE-Bomber (v=80, a=150, s=45, c=75)
[2] TIE-Fighter (v=150, a=75, s=30, c=45)
[3] TIE-Fighter (v=150, a=75, s=30, c=45)
Squadron B
[1] Y-Wing
[2] A-Wing
[3] A-Wing
[4] B-Wing
[5] X-Wing
(v=90, a=150, s=90, c=90)
(v=200, a=60, s=50, c=45)
(v=200, a=60, s=50, c=45)
(v=120, a=200, s=90, c=100)
(v=175, a=90, s=75, c=65)
donde el escuadrón A es el escuadrón imperial (formado por los
cazas 12, 9 y 3), y el B es el escuadrón rebelde.
b) Se elige un número aleatorio entre 0 y 99; si es menor que 10, el
combate entre los escuadrones termina
1 Para
mostrar los cazas se debe usar la función listFighters de la práctica 1.
3
FUNCIONAMIENTO DE LA PRÁCTICA
6
c) Se elige un caza del escuadrón imperial aleatoriamente, y a continuación un caza rebelde (también aleatoriamente), y se extraen
ambos de sus escuadrones.
d ) Se simula el combate entre ambos cazas como en la práctica
anterior, es decir, reutilizando el código de la dicha práctica. El
caza o los cazas supervivientes se añaden al final del escuadrón
correspondiente.
e) Si alguno de los escuadrones ha quedado completamente destruido, el combate termina. En caso contrario, se vuelve a realizar
otro combate entre cazas, volviendo al paso b (volviendo a elegir
un número aleatorio entre 0 y 99).
f ) Cuando termina el combate se vuelven a mostrar ambos escuadrones
Se debe llevar un registro de victorias2 y derrotas3 de cada nave,
para actualizar los datos de cada nave al terminar el combate entre
los escuadrones. Además, los créditos de cada nave se incrementarán
según el coste de los cazas enemigos destruidos en el combate, es
decir, si por ejemplo en un combate el escuadrón imperial destruye un X-Wing y un B-Wing, los créditos del destructor imperial se
incrementarán en 65 + 100 = 165 créditos.
6. Finalmente, al acabar el combate entre los escuadrones, los cazas
supervivientes se añadirán al final de los vectores de sus respectivas
naves (sin coste alguno para el jugador, evidentemente).
Un ejemplo completo de combate entre escuadrones serı́a:
Squadron A
[1] TIE-Bomber (v=80, a=150, s=45, c=75)
[2] TIE-Fighter (v=150, a=75, s=30, c=45)
[3] TIE-Fighter (v=150, a=75, s=30, c=45)
Squadron B
[1] Y-Wing (v=90, a=150, s=90, c=90)
[2] A-Wing (v=200, a=60, s=50, c=45)
[3] A-Wing (v=200, a=60, s=50, c=45)
[4] B-Wing (v=120, a=200, s=90, c=100)
[5] X-Wing (v=175, a=90, s=75, c=65)
------- begin fight
TIE-Fighter (v=150, a=75, s=30, c=45)
A-Wing (v=200, a=60, s=50, c=45)
-TIE-Fighter (v=150, a=75, s=-5, c=45)
A-Wing (v=200, a=60, s=41, c=45)
-- end fight
-- begin fight
TIE-Fighter (v=150, a=75, s=30, c=45)
X-Wing (v=175, a=90, s=75, c=65)
-TIE-Fighter (v=150, a=75, s=10, c=45)
X-Wing (v=175, a=90, s=72, c=65)
-- end fight
2 Una
3 Una
victoria es un caza enemigo destruido.
derrota es un caza propio destruido.
3
FUNCIONAMIENTO DE LA PRÁCTICA
7
-- begin fight
TIE-Bomber (v=80, a=150, s=45, c=75)
X-Wing (v=175, a=90, s=72, c=65)
-TIE-Bomber (v=80, a=150, s=27, c=75)
X-Wing (v=175, a=90, s=54, c=65)
-- end fight
-- begin fight
TIE-Bomber (v=80, a=150, s=27, c=75)
X-Wing (v=175, a=90, s=54, c=65)
-TIE-Bomber (v=80, a=150, s=-9, c=75)
X-Wing (v=175, a=90, s=40, c=65)
-- end fight
-- begin fight
TIE-Fighter (v=150, a=75, s=10, c=45)
A-Wing (v=200, a=60, s=50, c=45)
-TIE-Fighter (v=150, a=75, s=-3, c=45)
A-Wing (v=200, a=60, s=50, c=45)
-- end fight
-----Squadron A
Squadron B
[1] Y-Wing
[2] B-Wing
[3] A-Wing
[4] X-Wing
[5] A-Wing
3.2.
(v=90, a=150, s=90, c=90)
(v=120, a=200, s=90, c=100)
(v=200, a=60, s=41, c=45)
(v=175, a=90, s=40, c=65)
(v=200, a=60, s=50, c=45)
Descripción de las nuevas opciones
Save data/Save enemy data : En estas opciones se debe guardar toda la información de una nave (el destructor imperial o la nave rebelde, según
la opción elegida) en un fichero binario. La información que se almacenará será, en este orden:
1. Los datos de la nave, usando el siguiente registro:
typedef struct {
bool side;
int maxCapacity;
int credits;
int wins;
int losses;
} ShipBin;
2. Los datos de todos los cazas que contiene la nave, usando el siguiente
registro para cada caza:
typedef struct {
char type[3];
int velocity;
int attack;
int shield;
int cost;
} FighterBin;
// tf, xw, ...
El campo type de este registro tendrá la abreviatura de dos caracteres
del tipo de caza, y el “\0” del final de la cadena.
3
FUNCIONAMIENTO DE LA PRÁCTICA
8
Los datos se almacenarán en un fichero binario cuyo nombre se pedirá al
usuario con el siguiente mensaje:
Filename:
Si el fichero no se puede abrir, se debe emitir el error CANT_OPEN_FILE
(véase la sección de implementación)
Load data/Load enemy data : En estas opciones se recuperarán los datos de
una nave a partir de un fichero binario. Inicialmente, se pedirá el nombre
del fichero y, si se puede abrir, se pedirá confirmación para sobreescribir
los datos de la nave a partir de los del fichero con el siguiente mensaje:
This operation will erase current data. Confirm? (y/n)
Si el usuario introduce exactamente una “y” se leerán los datos del fichero;
en caso contrario se saldrá de la función (cerrando el fichero, por supuesto)
sin hacer nada más.
Como es posible que el usuario se despiste, cuando se lean los datos de
la nave del fichero binario, antes de leer los datos de los cazas, se debe
comprobar que la nave es del bando adecuado, es decir, que no se van a
meter los datos de una nave rebelde en un destructor imperial. Para esto se
debe comprobar que el campo side que hay en el fichero binario coincide
con el de la nave que se va a leer; si coincide, se borrará el vector de cazas
(usando el método clear de la clase vector) y se leerán los datos de los
cazas. Si no coincide se debe emitir el mensaje de error WRONG_SIDE y no
leer los datos de los cazas, obviamente (en este caso la nave debe quedarse
como estaba, no se debe modificar ningún dato).
Export data : Cuando se elige esta opción se exportarán los datos de los cazas del destructor imperial a un fichero de texto, pidiendo primero el
nombre del fichero como en las opciones anteriores, y emitiendo el error
CANT_OPEN_FILE si no se puede abrir el fichero. Los datos de los cazas se
guardarán en el fichero de texto con el formato del siguiente ejemplo:4
TIE-Fighter (v=150, a=75, s=30, c=45)
TIE-Fighter (v=150, a=75, s=30, c=45)
...
TIE-Bomber (v=80, a=150, s=45, c=75)
...
TIE-Interceptor (v=180, a=65, s=30, c=55)
...
TIE-Advanced (v=160, a=80, s=90, c=95)
TIE-Advanced (v=160, a=80, s=90, c=95)
TIE-Advanced (v=160, a=80, s=90, c=95)
TIE-Advanced (v=160, a=80, s=90, c=95)
TIE-Advanced (v=160, a=80, s=90, c=95)
Import data : Esta opción permite añadir al destructor imperial los cazas
contenidos en un fichero de texto con el formato descrito en el ejemplo
anterior. Debes tener en cuenta las siguientes cuestiones:
4 Aquı́ se muestran solo algunos de los cazas, no todos. En la práctica se deben exportar
los datos de todos los cazas de la nave.
3
FUNCIONAMIENTO DE LA PRÁCTICA
9
1. Como en las opciones anteriores, se debe pedir el nombre del fichero,
abrirlo y dar el error CANT_OPEN_FILE si no se puede.
2. El formato del fichero será correcto, pero es posible que el tipo de caza
no esté entre los incluidos en la tabla de datos de cazas imperiales
(porque por ejemplo sea un caza rebelde), en cuyo caso hay que
emitir el error WRONG_FIGHTER_TYPE y seguir con el siguiente caza
del fichero.
3. El tipo del caza será siempre una cadena que no tendrá espacios en
blanco (no es necesario comprobarlo)
4. Si un caza no cabe en la nave, se emitirá el error CAPACITY_EXCEEDED
y se dejará de leer el fichero (si no cabe ese caza no caben los siguientes)
5. Los cazas del fichero se añaden al final del vector de cazas, sin coste
para la nave (no se descuentan créditos).
3.3.
Argumentos del programa
El usuario puede invocar el programa desde la lı́nea de comandos con los
siguientes argumentos (opcionales), o bien sin argumentos:
Opción -l <fichero> : cuando se invoca el programa con esta opción, lo primero que debe hacer el programa es recuperar los datos del destructor
imperial del fichero binario que se le pasa como parámetro después de la
opción “-l”, pero sin pedir confirmación para borrar los datos actuales.
Si el fichero puede abrirse, se leerán los datos (reutilizando código de la
opción Load data del menú), y a continuación se iniciará el programa como si no hubiera habido argumentos, mostrando el menú.5 Si el fichero no
se puede abrir, después de emitir el mensaje correspondiente el programa
terminará (sin hacer nada más ni emitir ningún mensaje más).
Opción -L <fichero> : lo mismo para la nave rebelde.
Opción -i <fichero> : al poner esta opción, y el programa importará en el
destructor imperial los datos de los cazas contenidos en el fichero (como en
la opción Import data del menú), e iniciar el programa como si no hubiera
habido argumentos, mostrando el menú. Como en las opciones anteriores,
si el fichero no puede abrirse se emitirá el correspondiente mensaje de error
y se terminará el programa.
Las opciones no pueden aparecer repetidas y son compatibles entre sı́, es
decir, el usuario puede invocar el programa con una de las opciones, con dos, con
tres o con ninguna. Si se produce algún error en los argumentos del programa, se
debe emitir el siguiente mensaje de error WRONG_ARGUMENTS y salir del programa
sin hacer nada, es decir, no se debe leer ningún fichero hasta haber acabado de
comprobar todos los argumentos.
Si el usuario introduce varias opciones en la lı́nea de comandos, el orden para
ejecutar las acciones es: primero se debe leer el fichero binario de la nave imperial, luego el de la nave rebelde y finalmente el fichero para importar cazas. En
5 La implementación es muy sencilla: en la función main se debe comprobar y gestionar los
argumentos justo antes del bucle do-while que implementa el menú.
4
IMPLEMENTACIÓN
10
cualquier caso, el programa primero debe inicializar las naves antes de procesar
los argumentos, aunque luego alguna opción podrı́a sobreescribir los datos del
destructor imperial o de la nave rebelde.
4.
Implementación
Para implementar la práctica debes tener en cuenta las siguientes cuestiones:
1. En esta práctica se deben añadir tres nuevos mensajes de error a la función
error, junto con las constantes correspondientes:
case CANT_OPEN_FILE:
cout << "can’t open file" << endl;
break;
case WRONG_SIDE:
cout << "wrong binary data" << endl;
break;
case WRONG_ARGUMENTS:
cout << "Wrong arguments, syntax: imperialCommander [-l file | -L file | -i file]" << endl;
break;
2. Como se explica al final de la opción Add fighter, la inicialización de la
dotación inicial de cazas del destructor imperial y de la nave rebelde debe
hacerse a partir de cadenas, que sustituyen a los vectores de enteros de la
práctica 1 (que tenı́an el mismo nombre):
const string initialImperialShipDotation="10tf/ 5 tb, 5 ti, 5;ta";
// 10 TIE-Fighters, 5 TIE-Bombers, 5 TIE-Interceptors, 5 TIE-Advanced, ....
const string initialRebelShipDotation="10xw,5yw, 8aw, 5bw";
// 10 X-Wing, 5 Y-Wing, 8 A-Wing, 5 B-Wing
3. Como en la práctica anterior, se dejará en la web de la asignatura un
autocorrector para que comprobar algunos casos de funcionamiento de la
práctica.
4. Existe en esta práctica mucho código que se puede reutilizar en otras opciones del menú, diseña tus funciones de manera que se puedan reutilizar.
Y si es necesario, rediseña tu código para adaptarlo y que se pueda reutilizar.
5. El formato de los ficheros será siempre correcto (excepto en los casos que
se indica), y no habrá errores de lectura/escritura (no es necesario controlarlos).
6. Cuando un programa admite argumentos desde la lı́nea de comandos, se
pueden gestionar de varias maneras: si hay una o dos opciones, se puede
tratar de capturar todas las posibilidades con una secuencia de sentencias
if; sin embargo, con tres o más opciones, el número de posibilidades aumenta considerablemente y no es práctico usar únicamente sentencias if,
es necesario utilizar un bucle while para recorrer los argumentos y hacer
las comprobaciones necesarias, y extraer la información de los argumentos.
En cada paso de dicho bucle se debe comprobar si el argumento coincide
4
IMPLEMENTACIÓN
11
con alguna de las opciones y, si no aparece repetida, se debe comprobar
que a continuación hay otro argumento que se tomará como el nombre del
fichero correspondiente a la opción. Este proceso es el mismo para las tres
opciones, por lo que es recomendable usar una función para no duplicar
código, además de la función especı́fica para comprobar los argumentos.6
6 Cuando hay varios argumentos la comprobación y extracción de la información de los
argumentos debe hacerse en una función aparte, no en el main.