Cuando compiles en modo release el compilador, al optimizar, seguramente convierta esa función en inline, ya que no tiene bucles ni condicionales... overhead cero. Si eso no te convence piensa que un bucle for o while tiene saltos igualmente...

En cualquier caso es lo que digo... las prácticas de programación son un momento perfecto para aprender buenos hábitos. Es como cuando te sacas el carnet... ningún conductor se tira 45 minutos dando vueltas por las calles más puñeteras de una ciudad para no ir a ningún sitio... esto es igual... vale que la función quizás no merezca la pena en términos de productividad, mantenimiento y rendimiento... pero son habilidades y hábitos que adquieres al aprender y eso te ayuda a evitar malos vicios después.

Para poder manipular datos en c ( quien dice c, dice c, c++, c#, java, perl, ruby, ... ) éstos tienen que estar en tipos propios del lenguaje ( int, char, double, char*, ... ).

Luego esa información, como norma general, los programadores tienen la extraña necesidad de almacenarla en disco. Para realizar esta tarea hay tres formas diferentes:

• Guardar datos binarios.
• Guardar los datos en formato legible.
• Almacenar la información en una base de datos.

El primer formato es el más sencillo, ya que coges los datos tal cual los tiene tu programa y los vuelcas a un fichero de texto. Esto presenta el inconveniente de que la información almacenada es complicado editarla de forma manual.

El segundo caso requiere un proceso de "formateo" de la información, la idea es que la información generada por el programa pueda ser leída y fácilmente modificada por una persona... es el caso de usar XML, los antiguos INI, etc.

En el tercer caso delegamos la responsabilidad de almacenar los datos en un programa o código externo, éstos como normal general ( por cuestiones de rendimiento, escalado, comodidad, ... ) se guardan en formato binario, pero eso a nosotros nos da igual, ya que solo necesitamos conocer la forma de interactuar con el motor de la base de datos para conseguir interactuar con la información que almacena.

Dicho esto, si tienes los datos almacenados en XML, tendrás que hacer un pequeño parche que lea esos datos y los vuelque a tu base de datos.

Yo fíjate que propondría una tercera forma... ponerlo en una función independiente.

En el mundo de la programación se le puede sacar bastante rendimiento al "divide y vencerás".

void CreaMatriz( char letra, int* filas, int* columnas )
{
  system("cls");
  printf("Dame el numero de filas de %c :", letra);
  scanf("%d",filas);
  printf("Dame el numero de columnas de %c : ", letra);
  scanf("%d",columnas);
}

En este caso la función es sumamente simple... pero nunca está de más adquirir buenas costumbres a la hora de programar.

Mi experiencia es que generalmente los profesores se preocupan más de que la gente conozca las funciones del lenguaje que de que enseñar buenos hábitos.

 for(*opcion=1;*opcion<=7;opcion++)

en el último "opcion" te falta un asterisco... si no lo pones lo que haces es modificar la dirección a la que apunta el puntero.

 for(*opcion=1;*opcion<=7;(*opcion)++)

Usa Sqlite... no requiere servidor, no requiere instalación, su rendimiento es aceptable y usa sql para interactuar con la aplicación.

Es una suite de aplicaciones para el sector naval

Sobre lo de trabajar en equipo... lo de las notaciones está bien... pero cuando los grupos crecen se complica el asunto hasta niveles insospechados.

Hay mucha diferencia entre tener el control de todo lo que se hace porque eres el único desarrollador a encontrarte en medio de una tormenta con código de todas las formas tamaños y colores.

Mi caso es un poco extremo... pero en un proyecto como en el que estoy... de 13 millones de líneas de código... y 70 personas picando código... acabas detestando un poco los returns a mitad de función.

No es por el que lo hace... sino por el que luego va a meter mano ahí.

Pero es cierto, es cuestión de gustos.

A mi me rechina un poco en el segundo for la instrucción

(j > 0+i)

Funcionar funcionará... pero ese for no queda más claro así?

for(j=n-1;(j > i)&&(tri_sup);j--)

y luego lo que dice satu, ese if else sobra también. Dado que tri_sup tiene un valor inicial 1, el bucle solo debería preocuparse de darle valor 0 cuando proceda... volver a poner un 1 es absurdo, te hace poner más líneas de código que no solo no aportan nada sino que a la larga dificultan la lectura del código.

Hombre, eliminar returns intermedios siempre es una buena opción como norma general... ya que es fácil si no saltarse alguna tarea a realizar antes de salir... como liberar memoria.

void func( int numero )
{
  char* buffer = new buffer[ 10 ];
 
  // ...
 
  if ( numero < 0 )
    return;
 
 // ...
 
  delete buffer;
}

Ejemplos similares a este me he encontrado a patadas.

No obstante también digo que funciones con muchos niveles, si con returns mejora muchísimo la claridad... ahí me pienso si poner o no returns

std::string prueba;
 
std::cout << sizeof( prueba ) << std::endl;
 
 prueba = "ASDFASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDASDFASDFASDFA";
 
std::cout << sizeof( prueba ) << std::endl;

resultado:
32
32

expilcación:

sizeof es un operador estático que se resuelve en tiempo de compilación, por este motivo no te va a devolver nunca el tamaño real de un buffer dinámico.

Para trabajar con sockets suele ser más adecuado crear estructuras con tamaños definidos y delimitados y enviar esos paquetes se usen o no todos los bytes.

Me explico:

struct Paquete
{
  char[50] cadena;
};
 
// ...
 
int Sender::SendMensaje(Mensaje &pMensaje)
{
  struct Paquete to_send;
  strncpy( to_send.cadena, pMensaje.getMensaje( ), 49 );
 
  return send(this->host->getSocket(), &to_send , sizeof(struct Paquete), 0);
}

Y para recibirlo es similar... creas otro paquete, almacenas los datos en el paquete y después guardas el contenido en pMensaje.