전역변수에 어울리는 변수는??

필요하고, 현재 구조에서 전역 변수의 사용이 소스를 간결하게 할수 있다면 굳이 전역변수를 없앨 필요는 없다고 생각합니다.
module 별로 파일이 나누어져 있다면 symbol 충돌을 방지하기 위해 static 키워드로 충분할거라고 봅니다.

남의 프로그래밍 철학을 억지로 끼워 맞출려고 하시는게 아니신지 생각됩니다.
전역 변수와 goto 사용의 자제와 같은 남이 만든 룰에 억매이지 마셨으면 하는게 제 생각입니다.
CPU, OS 그리고 사람을 고려해서 자신이 생각하기에 가장 합당하다고 생각 할때는 전역 변수든 goto든 필요하다면 사용하는 것이 자신의 철학 정립하는 길인것 같습니다.

제 프로그래밍 철학을 잠깐 말씀드리겠습니다.
저는 goto에 대해서 할말이 참 많은 사람중에 하나입니다.
대학교 정규 과정을 거친 사람중에 goto를 무조건 쓰면 안된다고 말하는 사람들이 많은것 같습니다.
제가 아는 사람중에 한 사람이 다른 사람이 goto를 쓴걸보고 뭐라고 하더군요.

"goto를 쓰면 안돼는데 왜 썼냐고."

별로 친하지 않고 함부로 대할 수 없는 상황이였기에 말을 하지 않았는데. 그 사람의 요지는 이거였습니다.

"goto를 쓰면 안된다."

스파게티 코드 운운하더군요.
과연 그 사람은 goto가 instruction으로 jmp또는 b로 번역 되는것을 알았는지 궁금하더군요.
if, for, while, switch 모두 내부적으로 goto가 번역되는 jmp, b로 번역되는데 한페이지도 넘어가지 않은 함수에서 goto 하나의 사용에 대해서 운운하는게 우스웠습니다.
switch문의 case가 local label 번역 된다는것을 그 사람은 알고 그런말을 한다고 생각하지 않았습니다.

누군가가 하는 말을 들었을거라는 생각이 들더군요.

결국 그 사람은 자신의 철학이 없는 사람이였고, 그래서 어쩔수 없이 자신이 아는 사람중에 가장 권위 있는 사람의 철학을 모방했을거라고 생각합니다.

정말 자신이 생각하기에 전역 변수를 없애야 한다면 없애세요.
그건 자신의 프로그래밍 철학입니다.
그렇지만 만약에 지금이 더 간단한데 단지 "전역 변수는 없는게 좋은거니깐..." 이라고 생각한다면 (물론 symbol 충돌이 아주 적게 발생하는 상황에서...) 그건 자신의 프로그래밍 철학이 아닙니다.

만약 그렇다면 자신의 프로그래밍 철학을 만드십시요. 전자, TTL, CMOS, CPU, 컴파일러, OS, language, 사람등등 하나씩 정복해 나가면서 자신의 철학을 만드시길 바랍니다.

goto를 쓰건 (void *)를 남발하건 자신이 뭘 하고 있는지 잘 알고 있다면
사용하는 것 자체를 문제삼을 수는 없죠. 전역 변수 또한 마찬가지구요.
다만 어떤 코딩 스타일을 가진 다는 것은 의도적으로 노력하지 않으면
쉽지 않은데다가 오래 걸리기까지 하죠. 그러니 가급적 '의도적'으로 좋은
방향으로 가야 할 것 같습니다.

제 경우 C로 작업할 경우에는 거의 전역변수를 사용하지 않습니다.
지금 작업하고 있는 것을 보면... 없군요.

전역 변수를 없애는 가장 간단한 방법은 우선 전역 함수를 사용하는 것입니다.
전역 변수를 직접 엑세스하는 대신 get/set 함수 호출을 사용하는 것이죠.
이로써 읽기 위한 엑세스와 쓰기 위한 엑세스가 구분이 되죠.

다음으로는 특정 모듈에 종속적인 변수들은 파일 안에 static으로 만들어
주면 차후에 이 변수를 외부에서 엑세스하는 것을 막을 수 있죠.

가급적 함수를 만들 때에는 모듈 로컬 변수와 파라미터, 그리고 자동 변수
외에는 사용하지 않도록 하세요. 소스 코드 읽기도 좋아지고, 전역변수
문제도 점차 사라질 겁니다. 어떤 변수를 엑세스해야 한다면 caller가 그
변수값을 넘겨주던 포인터를 넘겨주던 하여간 파라미터로 넘겨주게 디자인
해보세요.

제목에도 밝혔지만 이런 일반적인 얘기가 통하지 않는 경우도 있습니다.
이런 경우에는 마음껏 전역변수를 써도 상관없겠죠. 예를 들어 제 경우엔
16비트 마이컴에서 타이머 쪽에서 전역변수를 사용합니다. 이쪽은 속도가
매우 중요해서 파라미터로 넘겨주고 어쩌고 하다가는 스펙 아웃이라서...

필요한 전역 변수가 매우 많다면 이 변수를 구조체로 묶어서 보내주는 방법도
있구요. 포인터를 넘겨줄 때에는 그것이 read only인지 writable인지 꼭
명시하세요. const를 사용하면 됩니다.

이정도면 웬만한 전역변수는 없어질 것 같네요.

전역변수 사용에 대한 이야기에서 잠깐 빗나가는 것 같은데,
goto문 사용에 대한 이야기가 나와서 저도 한가지만 언급하겠습니다.

매우 유명한 프로그래머가 있죠? Don Knuth라고...

그 할아버지가 Adventure라는 일종의 머드게임(?)을 작성하시면서, 서두에
한 말이 있습니다. (그 프로그램에는 goto문이 참 많이도 쓰였더군요.)

"By the way, if you don't like goto statements, don't read this.
(And don't read any other programs that simulate multistate systems.)"

goto문을 무조건 쓰지 말아야 하는 것은 아닌가 봅니다.
그래도 피할 수 있다면 goto문 사용을 자제하는 방향으로... :)

goto는 예외적인 상황에서만 사용하는게 좋습니다.
로우레벨 언어에 익숙한 구문이고 함수의 길이를 길게 만들수
있는 경향이 높습니다. 압축적으로 표현하기보다는 길게 표현할려는
경향이 짙어집니다.

저도 goto문은 그런식으로 처리하는데 사용합니다. 오히려 저런 경우에 goto문을 안쓸려고 하면 더욱더 스파게티 코드가 되어가더군요..

저도 첨에 책에서 본것과 강사들의 강의로 goto문을 쓰면 안된다라는 세뇌를

당했더랬죠. 실무를 하다보니 아니왜 goto를 쓰면 안되 써보자. 써보니 이때는

코딩 개념이 잡혀서 일까요? goto문을 쓰면 오히려 깔끔하게 처리 되더군요.

그 이후 이런류의 글을 보면 "아나 왜?"라는 의문 부터 해봅니다.

저의 경우 오히려 반대군요. goto문을 사용했을때 더 읽기 쉬운 코드가 됬습니다.

//a.h
extern int a;

// a.cpp
int a;

//a.h
int GetA();
void SetA(int);

// a.cpp
int a;
int GetA() { return a; }
void SetA(int val) { a = val; }

이렇게 하면 변수와의 종속성을 좀 더 느슨하게 만들어주지요...

*PS : 저도 Knuth 박사의 'goto 문의 유용성' 논문은 들은적이 있습니다만, 그거 작성 년도가 무지무지 옛날일껍니다.... 아마도 goto 문의 유용성에 대해 논의 하던 시기에 나온 논문일듯...

*PS: 경우에 따라 전역을 피하지 못하는 경우는 발생합니다. 어쩔수 없이 말이죠.
하지만, 좋은 설계는 전역 변수를 줄이는 것입니다. 커플링과 코헤젼 개념으로 전역 변수의 나쁜점을 설명하는 책들이 많이 있으니 참고하세요.

글쎄요. goto가 더 깔끔한 코드를 만든다? 그런 경우는 전혀 없다고 해도 과언이 아닐 겁니다. 다음과 같은 코드는..

error_code = 2;
goto ON_ERROR;
.
.
.
ON_ERROR:
// common clean-up like memory deallocation
return error_code

이렇게 바꿀 수 있죠.

  return handleError(2);
  .
  .
}

int handleError(int error_code) {
  // handle error
}

후자 대신 전자를 택해야 하는 경우는 딱 한 가지 경우입니다. function call의 overhead조차 부담스러운 경우죠. 이런 경우가 전혀 없는 건 아니지만 요즘은 웬만한 hard real time에서도 function call을 줄여야 하는 경우는 잘 없죠. 정 문제되면 inline이나 매크로를 쓸 수도 있구요.
[/code]

글쎄요. 실제 코드를 보여주시면 역시 비교가 좀더 명확하게 되리라 생각합니다만 그냥 이론상으로 이야기한다면, goto를 extract method하는 건 오히려 orthogonality를 높여 주기 때문에 coupling이 줄어듭니다. 만약에 두 함수가 똑같은 free를 해야 하는 상황이면 함수 내의 goto로 해결할 수 없기 때문에 두 함수에 똑같은 코드가 들어가죠. 반면 함수로 처리하면 두 함수에서 그냥 호출하면 되니까 coupling이 줄어듭니다. goto보다 function call이 유리한 점이 바로 이런 거 아니겠습니까. 그리고 error 처리를 하고 돌아와서 함수 종료 전에 free를 해도 되는 거구요.

덧붙여, 요즘은 OOP에 익숙한 사람들이 C로 회귀하는-_- 일이 많아지면서 C에서도 OOP적인 개념으로 코딩하는 경우가 많아지고 있습니다. struct와 function pointer를 사용하는 방식을 말하는 게 아니라 C에서 file이 하나의 scope라는 점을 이용해서 file을 class로 간주하고 file scope의 전역 변수를 클래스 멤버 변수, file scope의 함수를 private method, 전역 함수를 public method로 간주하죠. 이런 경우 destructor 개념의 함수를 하나 둬서 여기서 일괄적으로 free 작업을 해주기도 합니다. 물론 다형성 같은 건 function pointer의 도움 없이는 어렵지만요. 사실 이런 스타일은 별반 새로운 게 아니라 C에서 원래 많이 쓰이던 스타일이고 리눅스 커널의 코드에서도 왕왕 보이는 스타일인데 OOP 개념의 흡수로 좀더 체계화되어 가고 있죠.

 // one.h
struct TheOne { };
extern struct TheOne neo;

// useNeo.c
#include "one.h"

// twiddling with neo at users' own risk

// one.h
struct TheOne;

struct TheOne* whoIsThere(void);
void playSuperman(struct TheOne*);

// one.c
#include "one.h"
struct TheOne { };

struct TheOne neo;

struct TheOne* whoIsThere(void) { return &neo; }

이제 하나의 전역 함수에서 (서로 연관성이 없는) 모든 변수를 처리하도록 하는 것이
별로 좋은 방법이 아니라는 것도 이해하셨으리라 믿습니다.

내부적으로 구현이 어떻게 되느냐와 스파게티 코드가 될 수 있는 가능성 간에는 상관관계가 없습니다. 이 이야기는 에져 다익스트라의 이야기를 하면서 보충하겠습니다.

크누스 교수의 논문이 오래된 것이라면 에져 다익스트라의 "Goto statements considered harmful"은 더 오래된 글입니다. 오래되었다고 해서 배척할 이유는 없습니다. 오히려 더 소중한 글들입니다.

에져 다익스트라가 주장했던 것은 프로그래머가 흐름을 쫓아갈 수 없기 때문에 (texual index를 잃어버린다고 표현합니다.) GOTO가 문제가 된다는 것이었습니다.

1: i := 4
2: i := i + 1
3: goto 3

위의 코드가 있다면 이 코드에서 현재 실행 시점이 2번이라고 할때 1번 수행 다음인지 3번 수행 다음인지 알 수 없고 이것이 프로그래밍을 어렵게 만드는 요인이라고 보았던 것입니다. 그리고 현재 실행지점이 2번일때 1번 후인지 3번 후인지 설명하실 수 있는 분이 없다면 이 코드를 스파게티 코드로 불러도 무방할 것입니다.

이 문제를 해결하기 위해서는 필연적으로 고수준의 syntax sugar가 필요하다는 것이 밝혀졌고 반복과 분기 등을 이용하는 프로그래밍 기법이 발전해나갔습니다. 이것이 구조적 프로그램의 시작입니다.

여기서 주목할 부분은 두가지가 있습니다. 첫째는 에져 다익스트라가 비판한 이유가 textual index를 잃어버리기 때문에 비판했다는 것입니다. 위에서 많은 분들이 이야기 하셨던 예외 처리와 같이 사실상 순수한 프로그램의 로직과 별도로 고려해야 하는 부분은 goto를 배격할 이유가 없다는 것입니다. 그래서 다익스트라도 편집자가 자신의 논문에 "Goto statements considered harmful"이란 이름을 붙인 것에 대해서 매우 아쉬워했습니다.

두번째는 기존의 반복과 분기문으로 개념적으로 깨끗한 해결이 못될 경우에는 저 논리를 따를 필요가 없다는 것입니다. 예외의 경우에 고전적인 구조적 프로그래밍에서 깔끔하게 다룰 방법이 없습니다.

따라서 우리가 첫번째와 두번째에 어긋나는 사안에 대해서 goto를 적용하는 것은 에져 다익스트라도 환영할 것입니다. 반면에 우리가 쓸모없는 goto를 사용하는 것은 수십년 전에 선인들의 논쟁에서 어떠한 교훈도 얻지 못한 것입니다.

마지막으로 에져 다익스트라가 쓴
Goto staments considered harrmful(http://www.acm.org/classics/oct95/)을 소개합니다.

goto 문이 매무 유용했던 적이라면.....
for랑 if가 겹쳐서 블럭이 약 10개정도까지 들어간적이 있었는데...
몇몇 경우에는 조건을 비교하고는 만족하면
바로 가장 바깥 for문으로 나가야 했죠 =_=
for문만 4개... if문으로 매번 비교해가면서 나가는건 거의 불가능...

결국 goto로 한번에 해결됐었습니다.

for ( ) {
    for ( ) {
        for ( ) {
            for ( ) {
                ...
                if ( test( ) ) goto RESTART
                ...
            }
        }
    }
    RESTART :
}

이런 경우였다고나 할까요 =_=;;
여기서 break를 써서 돌아오려면
저 test 함수의 return을 저장해둘 변수가 필요하고
for문 블록 뒤에 매번 if문을 둬서 break 시켜야하고....
더 복잡해지죠 보기도 더 어렵고요.
(실제로는 for문 앞에 if문도 붙고 해서 더 깊이 들어가 있었죠..
지금은 for문만 표시한거구요.)

에져 다익스트라는 반복문조차도 필요없는 요소라고 보았습니다. 하지만 현실적인 이유로 (스택의 과도한 사용이나 속도 등의 이유로) 반복문을 사용하는 것을 추천했습니다.

오프 토픽이지만 분기, extract method 만으로 재귀구문이 일상화 되는 날이 올까요? 컴퓨터의 성능은 올라가지만 그만큼 요구되는 성능도 같이 올라가는게 아쉽습니다.

전역변수를 쓰는 기준중 하나는

전역변수가 있다는 사실을 몰라도 무방할 때 라고 봅니다.

간단한 예로 turnLeft() , turnRight() 함수를 통해서

Direction변수를 컨트롤 하는 겁니다. 개발자는 Direction이라는

변수가 있는지 알필요도 없고 변수자체를 추적할 필요도 없습니다.

만약 전역변수의 값을 개발자가 추적하고 이를 조건문등에서

평가해야할 필요가 있다면,

전역변수의 값이 어디서 어떻게 바뀌는지 꿰뚫고 있는다는 것은

그야말로 오쒯~ 입니다 --a

====================

goto에 관한 것은 예외처리시 매우 쓸만하는 것~

당신이 본 글 아래에 있습니다.

간단한 방법으로 for의 조건절 안에 break 조건을 적을 수 있죠. while이나 do-while을 적절히 활용하는 것도 경우에 따라선 for보다 나을 수 있구요.

요즘은 전역변수보다는 싱글톤의 해악이 점점 더 커지고 있지 않은가 하는 생각도 듭니다. 전역변수가 허용되지 않은 몇몇 언어는 전역변수의 용도로 싱글톤이 사용되는 느낌이 듭니다. 역시 사용자가 바뀌지 않는 한 시스템이 바뀌어도 마찬가지가 아닌가 생각도 드네요.

void 반복함수()
{
    struct CFunc {
        static bool NestedFunc(변수1, 변수2, 변수3)
        {
            if(조건검사)
                return false;
            ...
            return true;
        }
    };

    반복문1() 반복문2() 반복문3()
        if( CFunc::NestedFunc(반복변수1,반복변수2,반복변수3) == false )
            return;
}

이런 방법은 어떨지...
정말 이런경우 nested function 이 있었으면 하는 바람이...