글 읽기 - 질문 게시판 공지사항

공통

질문 검색을 먼저 해서 자신에게 필요한 답변이나 반례가 없는지 확인하고 질문을 남겨주세요.
문제를 복사/붙여넣기 하지 말아주세요.
프로그램을 꼭 실행해서 문제에 적혀있는 예제가 올바르게 나오는지, 컴파일은 되는지 확인하고 질문을 남겨주세요.
답변이 남겨져있는 글 내용을 자주 삭제하는 경우에는 사이트 이용에 제한을 받게 됩니다.

틀렸습니다

몇 %에서 틀렸다는 것은 의미가 없습니다. 몇 %에서 틀렸다는 내용을 올리지 마세요.
맞았는데 틀리는 경우는 거의 없습니다. 만약 데이터가 잘못되어서 틀린 경우라면, 오타/오역/요청 게시판으로 글을 올려주세요.
내 컴퓨터에서는 되는데, 제출하면 틀리는 경우도 없습니다. 더 많은 예제를 입력해보세요.
- Visual Studio에서는 되는데, 이클립스에서는 되는데, 엑스코드에서는 되는데, 실행은 되는데, 제 컴파일러에서는 되는데, gcc에서는 되는데, 등등의 표현도 사용하지 말아주세요.
문제에서 출력하라고 한 내용 이외의 말을 출력 하면 안됩니다. 문제의 출력 형식을 지키는지 다시 한 번 확인해보세요.
예제만 채점하는 것이 아니기 때문에, 예제가 잘 나오는 것도 큰 의미가 없습니다. 질문 게시판에서 해당 문제를 검색하거나, 직접 다른 데이터를 만들어서 테스트해보세요.
더 읽어보면 좋은 글
- BOJ 101

시간 초과

시간 제한은 테스트 파일 하나 당 독립적으로 측정됩니다.
언어별로 추가 시간이 주어질 수 있으며, 이 내용은 언어 도움말에서 확인할 수 있습니다.
문제마다 언어별 추가 시간이 없는 경우가 있을 수도 있습니다.
입/출력하는데 시간이 오래 걸릴 수 있습니다. 다음 링크를 확인해보세요. (입력 속도 비교/출력 속도 비교)
언어에서 제공하는 함수 또는 문법의 시간 복잡도도 계산에 포함시켜야 합니다.
- C에서 strlen의 시간 복잡도는 O(N) 입니다.
- C++ STL에서 find 함수의 시간 복잡도는 O(N) 입니다.
- Python에서 x in [1, 2, 3]과 같이, list에서 사용하는 in 연산의 시간 복잡도는 O(N) 입니다.

컴파일 에러

채점 현황/맞은 사람 페이지의 "컴파일 에러" 링크를 클릭하면, 컴파일 에러 이유를 볼 수 있습니다.
언어 도움말에 적혀있는 컴파일러로 시도해보세요.

런타임 에러

런타임 에러는 프로그램이 올바르게 종료되지 않았을 때 발생합니다.
주로 배열의 크기를 잘못 설정한 경우, 함수 호출이 끝나지 않는 경우에 발생합니다.
C, C++ 이외의 언어는 입력 파일의 형식이 문제에 나와있는 형식과 다른 경우에도 발생할 수 있습니다. 이 때는, 오타/오역/요청 게시판으로 글을 올려주세요.
런타임 에러 이유는 보여주지 않습니다.
stderr (Standard error stream)에 출력을 하면 런타임 에러를 받게 됩니다.
프로그램이 수행하다가 Exception이 발생하면 런타임 에러를 받게 됩니다. (별다른 에러 처리를 하지 않으면 에러 메시지가 stderr에 출력되기 때문)

출력 초과

틀렸습니다와 동일합니다.
정답 파일보다 너무 많은 출력을 해서 중간에 실행을 종료시킨 경우에 해당됩니다.

출력 형식이 잘못되었습니다

문제에 나와있는 출력 형식을 지키지 않은 경우입니다.
- 두 정수를 공백 하나로 구분해 출력하라고 했을 때, 이를 공백 두 개로 구분했을 때
- 두 정수를 한 줄에 하나씩 공백으로 구분해 출력하라고 했을 때, 이를 두 줄에 나눠서 출력할 때
- 각 줄의 앞에 의미 없는 공백이 있을 때

메모리 초과

말 그대로 프로그램이 문제에 적혀있는 메모리 제한보다 많은 메모리를 사용했을 때 발생합니다.
C/C++과 같은 경우에는 함수를 호출 할 때, 함수 내에서 수정하지 않는 변수를 call-by-value로 호출했는지 확인해보세요.

스페셜 저지

스페셜 저지는 정답을 검증하는 프로그램을 통해서 정답 여부를 검사할 때 사용합니다.
하나의 문제에서 여러 개의 정답이 있는 경우, 실수 오차를 검사해야 하는 경우에 사용합니다.
이를 사용하는 문제는 스페셜 저지가 문제에 표시되어 있습니다.

기타

소스 A와 B에서 다른 부분이 없는데, 다른 결과를 받게 됩니다.
- 물론 채점 프로그램의 버그일 수도 있지만, 아닐 수도 있습니다.
- 두 소스를 비교했을 때, 다른 부분이 존재하는 경우가 채점 프로그램의 버그인 경우보다 훨씬 많았습니다.

틀렸습니다 문단에서 몇 %에서 틀렸는지가 보통 크게 의미는 없지만, 만일 데이터 수십 가지를 돌파한 후 90%를 넘어가서 틀린다면 경계값 케이스들을 먼저 의심해볼만은 하다는 생각입니다. BOJ의 데이터 순서상 가장 작은 케이스들이 최후반부에 위치해 직접 데이터를 입력해보기도 용이하니, 이런 경우 질문을 올리는 대신 그런 경계값들을 시험해보라는 취지의 글을 추가하는 것이 어떨까 합니다.

또한 드물지만 " 내 컴퓨터에서는 되는데, 제출하면 틀리는 경우"가 있기는 합니다. 다만 이런 식으로 질문을 올리는 분들은 실제로 모든 데이터를 검증해본 것이 아니라 대체로 예제만 돌려보고 잘 나온다고 생각하는 것이므로, 그 아래에 "예제만 채점하는 것이 아니기 때문에~~" 의 설명이랑 합치는 것이 더 좋아 보입니다.

런타임 에러 문단에 "함수 호출이 끝나지 않는 경우"라는 말이 어떤 경우를 의미하는지 와닿지 않습니다. 무한 재귀호출을 말씀하시는 건가요? 그렇다면 그렇게 쓰는 것이 더 명확할 것 같습니다.

출력 초과 문단에 "중간에 실행을 종료시킨" 주체가 "채점 프로그램"이라는 것을 밝히면 더 좋을 것 같습니다.

메모리 초과 문단에서 call-by-value라는 용어를 사용하셨는데 쉬운 용어는 아니기도 하고, C의 경우 모든 인자는 call-by-value이므로 (포인터는 call-by-reference가 아니라, 그와 비슷한 효과를 내기 위해 쓸 수 있는 것입니다) 따로 구분을 할 수 없습니다. 이보다는 "구조체, 객체 내부의 값을 변경하지 않을 경우 포인터 또는 레퍼런스로 넘겨줘야 불필요한 객체 복사가 일어나는 것을 방지할 수 있습니다." 정도로 설명하는 것이 좋아 보입니다. 또한 제가 지금까지 답변하면서 본 메모리 초과 질문의 대다수는 BFS 방문 체크 위치 문제거나 재귀함수가 너무 깊이 들어간 것이 문제였고, 레퍼런스 대신 값을 넘겨주어 너무 커지는 경우는 오히려 드물었습니다. 이 정도로 예시를 적으면 좋을 것 같습니다.

bupjae 6년 전 20

"질문하기 전에 문제에서 주어질 수 있는 최대 크기의 입력 데이터를 직접 만들어서 실행해 보세요" 정도의 설명을 추가하는 것도 좋을 것 같습니다.

moonhi123 6년 전 32

가끔 답변을 하다 보면 답변을 달려고 하는데 삭제된 글인 경우가 종종 있는 것 같습니다.

제 생각에는 답변이 해결됬어도 삭제하지말고 '해결 됨'으로 바꾸는데 그 문제를 푸는 다른 분들에게도 좋고, 답변을 다는 사람에게도 좋다고 생각합니다.

그래서 "만약 문제가 해결되면 삭제하지 말고, 다른 사람들을 위해 '해결 됨'으로 바꿔주세요" 라는 내용을 추가하면 좋을 것 같습니다.

sgh1939 6년 전 8

읽었습니다.

2468ab 6년 전 8

감사합니다

djm03178 6년 전 13

코드의 로직을 간략하게 설명하라는 내용도 있으면 좋겠습니다. 수백 줄짜리 코드를 설명 한 줄 없이 올리고 문제점을 찾아달라는데 반례를 못 찾으면 막막할 뿐입니다.

zxcv551133 6년 전 26

저는 개인적으로 몇프로에 틀렸다는 정보가 없는것 보다는 나은 것 같습니다.

테케가 제공되지 않는 boj이지만,

만일 질문을 본 답변자가 같은 퍼센트에서 틀린 경험이있다면 (물론 추후 테케가 추가되고 변경되면서 바뀌었을 가능성도 있습니다)

해당 반례를 빠르게 지적할 수 있다고 생각합니다.

wsx3672 6년 전 6

읽었습니다

yeongjae8066 6년 전 6

읽었습니다!

sbj8388 6년 전 4

읽었습니다.

genius_choi 5년 전 4

읽었습니다.

djm03178 5년 전 5

틀렸습니다 문단에 있는 대부분의 내용이 공통 문단으로 가야 할 것 같습니다. TLE나 RTE 등을 받으신 분들이 틀렸습니다 문단을 안 읽으시는 것 같습니다. 틀렸습니다 문단에는 "출력이 정답과 다르면 받게 됩니다." 를 추가하고 "문제에서 출력하라고 한 내용 이외의 말을 출력 하면 안됩니다. 문제의 출력 형식을 지키는지 다시 한 번 확인해보세요." 만 남기고 나머지는 공통으로 옮기면 좋을 것 같습니다.