Errores comunes en env os a jueces autom ticos

Introducción 
Este  documento  explica  la  dinámica   de  juzgamiento  en  una  competencia  de  CCPL  usando  el  juez 
BOCA.  También  recopila  y  lista  los  errores   más  comunes  que  generan  juzgamientos  de 
"Compilation  Error"​
,  ​
"Runtime  Error"  y  ​
"Time  limit  exceeded"​
.  En  particular,  este  documento 
puede ser de gran utilidad para participantes novatos. Dinámica de juzgamiento 
Cada  envío  en  el  juez  BOCA  es  juzgado  por  2  jueces   diferentes:  dos  personas diferentes revisan  un 
juzgamiento  preliminar  dado  automáticamente  por  el  sistema  y  seleccionan  uno  de  los  veredictos  
disponibles  teniendo  en  cuenta la salida estándar de error y la comparación  entre salidas  oficiales.  En algunas ocasiones también se inspecciona incluso el código fuente enviado por los competidores.  
 
Solo  se  les   comunica  un  veredicto  a  los  equipos  cuando  los  veredictos  dados por los dos jueces son 
iguales,   entonces  es  poco  probable  que  ambos  jueces  se  equivoquen  de  la  misma  manera.  Cuando 
no  concuerdan  los  veredictos  de  los  dos  jueces,   un  tercero  (el  “juez  jefe”),  es  informado  y  él  toma la decisión de seleccionar el veredicto definitivo; solo entonces se le comunica al equipo. 
 
Según  nuestra  experiencia  como  jueces,  esa  equivocación  en  la  que  no  concuerden  dos  veredictos 
pasa  una  de   cada  300  veces,  tal  vez  menos.  El  error  más  común  (de  los  pocos que hemos visto) en 
juzgamiento  es  seleccionar  un  ​
“Runtime  error”  en  lugar  de  un ​
“Compilation Error”​
, esto porque el 
veredicto  automático  preliminar  de  BOCA  en  casos  como  cuando  no  está  bien  el  nombre de la clase 
en  Java  es  ​
“Runtime  Error”​
,  pero  debería  ser  ​
“Compilation  Error”​
.  Nuevamente,  estos  errores 
humanos de juzgamiento ocurren muy poco. 

Errores de compilación 
Algunos  situaciones,  sobre  todo   cuando  se  está  empezando  a  participar  en  competencias  de programación, ocurren errores que se apartan de la estrategia  de solución y están más bien alineados 
con  la  falta  de  experiencia  a  la  hora  de  usar  un  lenguaje  de  programación  (o  por   simple  por 
desconocimiento  de  las  políticas  de  seguridad  del  robot  de  juzgamiento)  producen  ​
"Compilation 
Error"​
 en el juez BOCA. 
A  continuación  se   enumeran,  para  los diferentes  lenguajes  de  programación,  algunas  de  estas 
situaciones que son recurrentes durante una maratón. 

En C/C++ 
●
●
●

●
●
●
●

Tengan  en  cuenta  que  el  compilador  del  juez,  no  es  necesariamente  el   mismo  que  tienen  en 
sus computadores. 
El  compilador  está  instalado  en  linux,  por  lo  que  cosas  como  system(“pause”),  system(“color 0a”) y system(“cls”) producen error de compilación 
Se  deben  incluir  las  librerías  necesarias:  en  algunas  ocasiones  una  implementación  funciona 
en  los  IDEs  (ejemplo  en  dev­cpp)  pero  no  en  el  juez;  ejemplo:  usar   printf  o  scanf  sin  incluir 
cstdio  o  stdio.h,  usar  memset  sin  incluir  string.h,  o  usar las funciones min o max que  no están 
en las librerías que han importado. Enviar proyectos completos comprimidos; se debe enviar sólo un archivo fuente (.cpp o .cc). 
Usar librerías o funciones no estándar como conio, itoa o getch. 
Intentar abrir archivos de entrada cuando no se pide; generalmente la entrada es la estándar. 
El  "basename"  (nombre del archivo) debe llamarse como se indica en el enunciado y ​
NO debe 
contener tener espacios; ejemplo add.cc. 

●
●
●

●

●
●

Algunos  usos  de  typedef pueden  causar  conflictos  entre versiones del compilador y ocasionar  
que algunas soluciones compilen o no dependiendo de la versión del compilador. 
Enviar otra cosa diferente al archivo fuente; ejemplo: enviar add.exe en lugar de add.cc 
Escribir  caracteres  especiales   (ñ,  Ñ  á,  é,  í,  ó  ,  ú,  etc) en comentarios, nombres de variables o 
mensajes  de ...