이식성있는 코드 작성 방법
글쓴이: geekforum / 작성시간: 수, 2002/05/08 - 9:52오후
여러 플랫폼에서 작동하는 코드를 작성하기 위해서는 무엇을 주의해야 하고 어떤 원칙이나 기술을 활용해야 하는지요?
도스-윈도우즈나 윈도우즈-유닉스 계열, 혹은 같은 유닉스 계열에서도 이식성 있는 코드를 작성하기가 어려운 것으로 알고 있습니다. 물론 x86환경과 alpha/sparc 등 하드웨어가 다를 때도 마찬가지고, 처음에 생각했던 것과는 전혀 다른 플랫폼으로 코드를 이식해야 하는 경우도 왕왕 있겠죠.
생각할 수 있는 조합의 폭이 대단히 넓은데 각자 경험해 보신 대로 이식성 있는 코드 작성에 대한 노하우를 좀 나우어 주시면 안될까요....
Forums:
마이크로소프트 리눅스 XP가 나오면 다 호환되지 않을까요? ^^;
마이크로소프트 리눅스 XP가 나오면 다 호환되지 않을까요? ^^;
http://www.if.insa-lyon.fr/eleves/jqueli
http://www.if.insa-lyon.fr/eleves/jquelin/quadri.html
다소 엽기적이지만
perl-c 호환코드 작성법입니다. -_-
윈도 프로그램을 리눅스로 이식하는 방법에 대해Borland C++Bu
윈도 프로그램을 리눅스로 이식하는 방법에 대해
Borland C++Builder6 개발자 안내서(한글판임)
14장에 유용한 자료가 있네요.
주로 VCL 애플리케이션을 CLX로 이식하는 방법에 대한 설명이지만,
일반적인 C++과 인라인 어셈블리 코드 이식에 대한 설명도 있습니다.
다음 링크에서 다운 받으세요.
http://www.borlandkorea.co.kr/bcppbuilder/cpp6/bcb60_dg_kor.pdf
또는
http://www.borlandforum.com/impboard/attach/bcb_res/00000153/C++Builder6.zip
이식성의 개념을 정확히 이해하지 못하고 계신듯 합니다.플랫폼 간의
이식성의 개념을 정확히 이해하지 못하고 계신듯 합니다.
플랫폼 간의 이식성을 확보하기 위해서는 크게 두가지 접근 방법이 있습니다. 즉, C와 같이 각 플랫폼에서 컴파일하는 방법으로 소스 레벨의 이식성을 얻는 방법과 자바와 같이 아예 사용자 코드와 운영체제 사이에 JVM이라는 계층을 끼워넣어 바이너리 레벨의 이식성을 확보하는 방식입니다.
두 방법 모두 장단점을 가지고 있고 그렇게 쉽게 우열을 말하기 어렵습니다.
단, 개인적으로는 성능 문제가 해결된다면 자바나 닷넷 처럼 VM을 사용하는 방식이 이상적이라고 봅니다.
JVM의 경우 지금도 많은 플랫폼을 지원하고 있지만, 설사 지원하지 않는 플랫폼이 있다고 해도 VM코드만 이식한다면 (이론적으로) 모든 자바 어플리케이션이 별도의 작업 없이 해당 플랫폼에서 동작할 수 있습니다.
반면 소스레벨 이식성의 경우 사용할 프로그램을 모두 해당 플랫폼에서 재컴파일 해서 배포해야 하는데 엔드유저 입장에서는 그렇게 쉬운 문제는 아닙니다.
시스템에 VM이 안깔려 있다는 문제는 기술적인 이슈라기 보다는 정책적인 문제 아닌가요? 예를들어 MS가 차기 버전 OS를 만든다면 .NET의 CLR을 기본으로 탑재하는 건 당연하겠지요.
그럼...
잠이 덜깼나 보군요. 본문에 답장을 해버렸네요 ㅡ.ㅡ;;스카리님의
잠이 덜깼나 보군요. 본문에 답장을 해버렸네요 ㅡ.ㅡ;;
스카리님의 아래 글에 대한 답장입니다
> 엄격히 말해서 자바는 전혀 portable 하지 않습니다.
>자바는 자바 가상머신 위에서만 돌아가지 않나요?
>대상 머신에 자바 가상머신이 실려 있지 않다면
>자바로는 아무것도 할 수 없습니다.
>자바는 JVM에 너무나도 종속적이기 때문이죠
제 생각에는 비지니스 로직만 이식성있게 만들면 되고 표현 계층은 해당 시
제 생각에는 비지니스 로직만 이식성있게 만들면 되고 표현 계층은 해당 시스템에 맞게 다시 작성하는게 가장 좋을 것 같습니다.C/C++ ,자바 모두 자료구조,알고리즘 작성에 있어서 충분하고 완벽한 이식성을 제공합니다(서버프로그래밍의 경우 비지니스 로직에 네트윅 코드까지 포함시키시는 분들도 계시던데 전 반대입니다).C/C++의 경우 표현 계층의 코드까지 이식성을 고려한다면 훨씬더 복잡한 작업이 되리라 봅니다.표현계층같은경우 이미 많은 라이브러리들이존재하므로 그것들을 잘 이용해서 원하는 화면만 나오게 만들면 끝이라고 봅니다(printf함수가 C언어 스펙에 들어가지 않고 단지 표준라이브러리인 이유가 어차피 기계종속적인 ,그리고 플랫폼종속적인 i/o부분은 발전이 빠르고 변화가 심하므로 추상화하기 글렀다고 판단했기 때문입니다).자바의 얘기를 하자면 씨언어랑 비슷한 잘구성된 문법과 플랫폼 독립을 고려한 언어라는 점에서 씨와 비슷하지만 개인적으로 처음부터 무언가가 잘못된 언어라고 봅니다.일단 가상머신을 거치면 아무리 잘 만들었다고 치더라도 시스템 속도와 리소스를 잡아 먹습니다.그리고 어차피 플랫폼독립적이지 못한 i/o부분역시 해결할수 없습니다.런타임 링크가 필요하다면 차라리 MS의 COM기술같은 표준 링크사양이 필요하다고 봅니다.MS가 PC 와 서버시장에만 눈독을 들였다면 아마 .NET은 나오지 않았을거라 생각됩니다.
PC,중대형 컴퓨터에서 멀티플랫폼을 위해 자바를 선택한다고 생각하지 않습니다.자바의 선택은 안정된 코드와 뛰어난 표현력이지 멀티플랫폼이 아니라고 봅니다.즉 C++의 포인터가 없는 또다른 모습에서의 자바를 선택하여 높은 생산성을 말하는것입니다. 크로스 플랫폼에 대한 환상은 착각이 아닐까 생각합니다.
으흠...구지 이식성 보다는 현제 플렛폼에서 최적의 성능을내는대 집중
으흠...구지 이식성 보다는 현제 플렛폼에서 최적의 성능을
내는대 집중하는게 낮지 않을까요. 리눅스 vs 미닉스을 예를 들어도 이식성에 집중하다면 보면 당연히 각각의 플렛폼의 성능과 기능을 재대로 발휘을 못하니깐여..이야기가 많이 빗나간 것 같지만 제 생각은 일반적으로 보편적인 플렛폼으로 시스템 디자인을 하고 다음에 다른 플렛폼의 지원을 고려해도 늦지 않다고 봅니다. =:^)
----------------
나는야 짱구가 좋아여+_+
밑에서 말씀하신것처럼 현재까지는 autoconf 등을 사용해서 #ifde
밑에서 말씀하신것처럼 현재까지는 autoconf 등을 사용해서 #ifdef 삽질을 이용하는게 일반적인 방법인 듯 합니다. (주로 C에서...)
하지만 이 방법을 사용하기엔 경험이 적은 사람은 좀 힘들더군요.
예컨데 string관련 함수를 쓴다면... 멀티플랫폼을 #include 를 해서 string관련 함수를 사용하면 되지만, string.h가 아닌 strings.h를 include해야 되는 플랫폼도 존재하더군요.
이런 부분을 다 고려하면서 #ifdef삽질하며 코딩할 생각을 하니 머리가 아픕니다...
제가 아직 autoconf에 익숙치 않아서 제대로 사용못하는 이유도 있겠지만... 아무래도 멀티플랫폼에 대해 접근하기 쉬운 레퍼런스가 부족한 이유도 있는 것 같습니다.
그럼...
코드작성시에 아래와 같은 식으로 하면 됩니다....시스템에 비
코드작성시에 아래와 같은 식으로 하면 됩니다.
...
시스템에 비의존적인 부분(공통)
...
#ifdef (OS이름)
...
OS의존적인 코드
...
#elif (다른 OS이름)
...
OS의존적인 코드
...
#endif
...
OS비의존적인 코드
...
...
근데 문제는 적절히 함수 자르는 거지요.
시스템 의존적인 부분과 비의존적인 부분의 경계를
함수로 잘라버리는게 좋습니다.
아주 간단하다면. 함수 내에 의존코드를 넣어도 되지만
요새 NASM에 익숙해져서인지.
C preprocessor 문법이 잘 생각이 안나네요..
> 멀티플랫폼을 #include <string.h>를 해서... (오타.
> 멀티플랫폼을 #include 를 해서... (오타...)
멀티플랫폼을 신경쓰지 않는다면 #include 를 해서 사용하면 되겠지만... 신경쓴다면 configure과정에서 string.h을 체크해서 config.h에 저장하고, C파일에서 config.h를 include해서 string.h가 있는지 체크해서 #ifdef삽질로 구현해야겠죠.
지금 다시 읽어보니 상당히 표현을 미숙하게 했는데... 요즘 #ifdef 삽질된 소스코드를 보고 있자니 머리가 아픕니다.
저는 왜 이식성 있는 코드를 맹글어야 할지를 도무지 모르겠습니다..
저는 왜 이식성 있는 코드를 맹글어야 할지를 도무지 모르겠습니다..
이제 멀티플랫폼이라는말은 사라질때가 되었습니다..
이식성?? 이제 우리 후배개발자들은 이런거 모르게 될것입니다.
저도 M$를 싫어하는 사람들중에 하나입니다..
그러나 이미 현실은 M$가 컴퓨팅 세계를 평정하고 있다는거죠..
리눅스는 잊어버려도 될시대가 옵니다..
너무 쓸데 없는 소리 한거 같군요..--;;
개인용 PC의 소프트웨어에서만 우위를 보이고 있을 뿐이죠......
개인용 PC의 소프트웨어에서만 우위를 보이고 있을 뿐이죠......
이제부터는 세상이 바뀝니다..안타깝지만...windows가 이세상 모
이제부터는 세상이 바뀝니다..
안타깝지만...windows가 이세상 모든 컴을 지배할 날이 머지 않았다고
생각됩니다..
서버에서도 이제는 윈도를 많이 선택하게 될것이구요..
개인 PC에서는 100% 윈도가 되겠져...--;;
네. 맞습니다. 리눅스나 기타 잡다구리한 플랫폼들은 잊어야 합니다.대
네. 맞습니다. 리눅스나 기타 잡다구리한 플랫폼들은 잊어야 합니다.
대신 legacy(for win32-_-)라는 족쇄를 차고 개발자들은
영원한 m$의 나락에서 허우적대야 합니다.
-- 어디까지나 농담.
POSIXqtOpenGLglutANSI C : :
POSIX
qt
OpenGL
glut
ANSI C
:
:
표준이 정해져 있는 API들을 쓰고..
그리고 고수들의 코드를 보면서 항상 느끼지만..
#ifdef #ifndef 같은 프리프로세서를 잘써서 portablity 를 구현하는 것 같습니다.
자바를 쓰세요.. -.-
자바를 쓰세요.. -.-
엄격히 말해서 자바는 전혀 portable 하지 않습니다.자바는 자바
엄격히 말해서 자바는 전혀 portable 하지 않습니다.
자바는 자바 가상머신 위에서만 돌아가지 않나요?
대상 머신에 자바 가상머신이 실려 있지 않다면
자바로는 아무것도 할 수 없습니다.
자바는 JVM에 너무나도 종속적이기 때문이죠
자바가 JVM에 종속적이고 썬은 JVM의 소스 코드 자체는 공개하지 않았
자바가 JVM에 종속적이고 썬은 JVM의 소스 코드 자체는 공개하지 않았지만 실제 쓸수있는 JVM의 종류는 상당히 많습니다. 윈도우즈, 맥오에스, 리눅스, BSD계열, 솔라리스 모두 각각의 운영체제에서 돌아가는 JVM을 갖고 있지요. 심지어는 임베디드 시스템에도 JVM이 돌아가고 있는 상황입니다. 이정도면... 자바라는 수단을 이용해 바이너리 레벨상의 이식성을 구현하는 것이 나쁘지는 않다고 봅니다.
조금 접근방법은 다르지만 파이썬이 이기종간의 이식성을 확보하는 방법도 한번쯤 지켜볼만합니다. 굳이 컴파일이라는 과정을 거치지 않고 인터프리터 레벨에서 이식성을 확보하는 방법인데요... 속도가 느리다고는 하지만 사용자 입장에서나 개발자 입장에서 쉽게 사용할 수 있는 방법입니다. 이것 역시 쓸만합니다. 앞으로 Gnome쪽에서는 파이썬이 주요 개발언어의 하나로 등장할 가능성이 높은 것 같은데 혹시나 잘하면 윈도우즈에서 Gnome 데스크탑을 깔고 여기서 Gnome용 파이썬 어플을 돌리는 상상을 해 봅니다. :)
그래도 저도 리눅스를 오래 써서인지 전통적인 유닉스 방식의 이식성이 마음에 들더군요. 소스코드를 그냥 타겟에 맞게 컴파일만 하면 그 플랫폼에 맞는 바이너리가 제대로 작동하는 구조가 친숙하네요.
그럼.
역으로 자바머신만 있으면 완전히 portable합니다.c 라이브러리없
역으로 자바머신만 있으면 완전히 portable합니다.
c 라이브러리없는 윈도우에서 C로 만든 프로그램이 돌아갑니까?
마찬가지죠
의미없는 글이라 지나칠 수 없군요..
그래도 왠만한 플랫폼에서는 JVM이 돌아가고 있지요..그렇게 따지
그래도 왠만한 플랫폼에서는 JVM이 돌아가고 있지요..
그렇게 따지면..
C같은 언어도
C컴파일러가 해당 CPU아키텍쳐를 지원해줘야 하니깐..
이식성이 없다고 할 수 있겠네요.
(물론 C컴파일러 없는 아키텍쳐는 거의 없겠지만요..)
왠만한 상황에서는 자바 사용하는게 좋다고 생각합니다.
왠만한 플랫폼의 기준이 애매하다고 생각이 듭니다.Post PC시대가
왠만한 플랫폼의 기준이 애매하다고 생각이 듭니다.
Post PC시대가 되면서 플랫폼의 범위는 점점 넓어지지 않습니까? :)
--
L.I.T
L.I.T
안녕하세용... ㅎㅎ 델파이6에서 컴파일하다 보면 Platform s
안녕하세용... ㅎㅎ
델파이6에서 컴파일하다 보면 Platform specific 이라는
경고가 가끔 뜨는데... 윈도즈에서만 된다는 뜻이죠...
요즘들어 델파이 컴퍼넌트 제작자들이 리눅스의 카일릭스와
공용할 수 있는 클릭스(CLX)를 많이 발표하고 있습니다.
패스트리포트도 그렇고... 터보파워의 많은 제품도 그렇고..
델파이에도 관심을 가져보세요^^;
클릭스 쓸 때 지금은 $IFDEFINE 으로 처리해야 하지만...
델파이.NET 에서는 그런 전처리 부분 없는 동일한 소스를
윈도즈와 리눅스에서 정말 기냥 끌어다 쓸 수 있을 것
같은데... 그건 나와 봐야 아는거고...
정말 카일릭스에서 델파이의 소스를 그대로 쓸 수 있는지
실험해 보기위해 리눅스 구하려 왔다가 글 올립니다.. ㅡ.ㅡ
리눅스가 먼지 몰라서^^;
-------------------------------------------------------
이식을 위해 가장 중요한 것은 처음부터 잘하는거라고
생각됩니다. 두 플랫폼의 세부적인 구현에 대해 잘 아는
사람이 이식을 고려하고 작성한 것과, 특정 플랫폼의
특정 기능에 의존해서만 작성된 것을 이식하는 것은 엄청
다르겠죠...
http://apr.apache.orgapr(apache portab
http://apr.apache.org
apr(apache portable runtime) library같은 것을 쓰는 것도 괜찮겠죠.. license도 제약이 많지 않으니..
몇가지가 있겠지만 역시 가장 중요한것은시스템 디펜던시를 최소화 하
몇가지가 있겠지만 역시 가장 중요한것은
시스템 디펜던시를 최소화 하는것이겠죠...
여러가지 방법이 있겠지만 저는 주로 Wrapping Class를 이용합니다.
하부구현은 시스템별로 하되 User에게는 동일한 Interface로 접근이
가능하도록 하는것이죠...
또한 DataType은 raw타입을 재정의해서 써야될것입니다.
또한 endian문제도 심각하게 고려를 해야겠지요...
이모든것을 한번에 처리할 수 있는 System Abstration Layer를 작성하신다면,
혹은 비슷한 라이브러리를 사용하신다면 훨씬 원활한 작업진행이 가능하리라 봅니다.
다양한 UNIX간의 포팅 문제라면http://www-h.eng.c
다양한 UNIX간의 포팅 문제라면
http://www-h.eng.cam.ac.uk/help/tpl/languages/C/portableC.dvi
wxwindow 라는 라이브러리도 있습니다...이걸쓰면 윈,리눅,맥에
wxwindow 라는 라이브러리도 있습니다...
이걸쓰면 윈,리눅,맥에서 다 돌아가는 GUI프로그램을 만들수있는것 같더군요...
mini-howto를 kldp서 본거 같은데...
mini-howto를 kldp서 본거 같은데...
WIN32API
WIN32API
"OOP의 모든 문제는 추상화 계층을 추가해서 해결할수 있다"->
"OOP의 모든 문제는 추상화 계층을 추가해서 해결할수 있다"
-> 명언 아닌가요? :)
그 외에,쓰지도 않을 실행코드를 달고 다니게 되겠죠.
그 외에,
쓰지도 않을 실행코드를 달고 다니게 되겠죠.
과자가 아닙니다.
cuckoo dozen, 즉.12마리의 뻐꾸기란 뜻입니다.
"쓰지도 않는 실행 코드" 가 무슨 뜻이지요? 또 OOP와 무슨 관련
"쓰지도 않는 실행 코드" 가 무슨 뜻이지요? 또 OOP와
무슨 관련이 있는지 모르겠군요.
에궁... 아랫글에 답할려고 쓴 건데... if ( 윈도우? ){
에궁... 아랫글에 답할려고 쓴 건데...
if ( 윈도우? )
{
윈도우 코드 달달달..
}
elseif ( 리눅스? )
{
리눅스 코드 주절주절..
}
else if( BSD?? )
{
BSD 코드 씨부렁씨부렁..
}
else if ( MacOS? )
{
MacOS 코드 궁시렁궁시렁...
}
이 글에 답할려고 쓴 글이었습니다.
과자가 아닙니다.
cuckoo dozen, 즉.12마리의 뻐꾸기란 뜻입니다.
추상화의 의미를 모르시는군요. :)
추상화의 의미를 모르시는군요. :)
다른 글에 대한 답장을 실수로 붙이신거라고 적혀 있네요 :) -- L.
다른 글에 대한 답장을 실수로 붙이신거라고 적혀 있네요 :)
--
L.I.T
L.I.T
if ( 윈도우? ){ 윈도우 코드 달달달..}el
if ( 윈도우? )
{
윈도우 코드 달달달..
}
elseif ( 리눅스? )
{
리눅스 코드 주절주절..
}
else if( BSD?? )
{
BSD 코드 씨부렁씨부렁..
}
else if ( MacOS? )
{
MacOS 코드 궁시렁궁시렁...
}
이야.. 벌써 4가지 종류의 운영체제에 이식되는
코드가 완성..
이렇게 하면 에러가 나겠죠윈도우의 경우 단순 if문으로하면 리눅스코드
이렇게 하면 에러가 나겠죠
윈도우의 경우 단순 if문으로하면 리눅스코드용 함수를 인식할수 없으니..
아예 원천 접근을 막아야줘
#ifdef ( 윈도우? )
윈도우 코드 달달달..
#elif ( 리눅스? )
리눅스 코드 주절주절..
#elif( BSD?? )
BSD 코드 씨부렁씨부렁..
#elif ( MacOS? )
MacOS 코드 궁시렁궁시렁...
#endif
훌륭하십니다..
훌륭하십니다..
mfc 안쓰고 gtk/qt 쓰면.이식성있는 코드가 될수 있죠...
mfc 안쓰고 gtk/qt 쓰면.이식성있는 코드가 될수 있죠...
directx 안쓰고 sdl 같은거 쓰면.....
아 언제 그런 시대가 올까나....
간단합니다.프로그램 전체 코드 중해당 시스템에 의존적인 부
간단합니다.
프로그램 전체 코드 중
해당 시스템에 의존적인 부분을 가급적이면 줄여야 합니다.
해당 시스템에 의존적인 부분을 어쩔 수 없이 써야
하는 경우가 왕왕 있을 겁니다. 이부분에 대해서는 할 수
없죠. 이식할때 노가다 좀 해야죠. 심지어는 해당 플랫폼의
기능제한 때문에 그대로 이식 못할 수도 있습니다.
시스템에 의존적인 부분들을 wrapper함수로 감싸 놓으면되지 않
시스템에 의존적인 부분들을 wrapper함수로 감싸 놓으면
되지 않을까요?
wrapper 함수에대해서 간략하게 소개해 주실 수 있을까요?
wrapper 함수에대해서
간략하게 소개해 주실 수 있을까요?
많이 들어왔는데 정작 무엇인지 모른다는.. ㅡㅡ;
꾸벅
개념이 혼동된듯.Wrapper라는건 따로 존재하는 함수가 아니라,
개념이 혼동된듯.
Wrapper라는건 따로 존재하는 함수가 아니라,
어떤 함수들를 포장하라는 의미이지요.
쉽게 말하자면 OOP에서의 추상 클래스나 Interface와 같습니다.
즉 구현 코드와 사용자 코드를 분리하라는 말입니다.
이때의 사용자 코드는 프로그래머가 만드는 임의의 코드가 아니라
이 객체를 사용하는 입장에 놓여진 코드 부분을 의미합니다.
이렇게 해두면 나중에 이식할때 Wrapper 내에 있는 OS에 독립적이지 못한 코드들을 바꿔가면서 재구현함으로써 이식을 완료할 수가 있지요.
답 : ANSI 쿠달달 ~
답 : ANSI 쿠달달 ~
내가 선택한 답 : ISO 흐흐흐! America 싫어!
내가 선택한 답 : ISO 흐흐흐! America 싫어!