블로그 이미지
안녕1999

카테고리

전체 (3067)
자바스크립트 (20)
안드로이드 (14)
WebGL (4)
변비 (17)
정치,경제 (35)
C언어,ARM (162)
컴퓨터(PC, Note Book, 윈.. (41)
전자회로, PCB (27)
유머,안웃긴,GIF,동영상 (118)
국부론60 (71)
모듈(PCB) (3)
건강 (2)
FreeCAD (25)
PADS (43)
퇴직,퇴사,구직,취업 활동 (3)
C# (86)
엑셀 (8)
워드 (0)
LabView (6)
레고 (30)
FPGA (0)
Total
Today
Yesterday

달력

« » 2024.5
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

공지사항

최근에 올라온 글

거의 최신 비쥬얼 스튜디오에서 작성된 소스를 VC++6.0에서 컴파일하려고한다. 물론, 2017년인 지금은 윈도우7이 대다수이고, 윈도우10도 있고, 윈도우XP는 점점 사라지는 추세이다. 윈도우7도 판매를 안한다. 어쨌든, 컴파일을 하려고한다.

물론, 내가 만든 소스가 아니다. 다른사람이 만든 소스를 컴파일할때는,

- 안쓰는 코드도 있다. 제거하라

- 최신기술(?)을 사용하는 사람들은 그게 어떻게 돌아가는지 모르는 경우도 많다.

내부를 모르니, 어찌 어찌 하다보면, 완전 소모적이고, 덩치크고, 어이없는 코드를 작성하는 경우도 많다. 간단하게 해결될것을 말이다.

특히 C++ 클래스 기능을 사용하다보면, 내부에서 어떻게 돌아가는지 알길이 없다. 그러니, 중복에 중복을 해서, 덩치크고, 무거운 프로그램이 만들어진다.

복잡한 코드는 생각보다 훨씬 간단한 코드로 대체될 수 도 있다.


우선 유니코드로된 파일이 몇개있다. 메모장에서 열어서 ANSI로 저장했다. 메모장에서 깨져서 열리는 파일은, 워드패드로 열어서, MS-DOS형식으로 저장, 메모장에서 열어서, ANSI로 저장. fatal error C1083: Cannot open include file: 'afxcontrolbars.h': No such file or directory 리본막대컴트롤 VC++6.0에서는 사용불가 참고문서

일단, 주석처리 using namespace Gdiplus;//주석처리 알수없는 DLL 헤더파일 #include는 헤더파일 찾아서, 전체경로명 넣어줌. include에서는 전체경로명에는 \가 아니라, \\로 해야함.


#include <set>//주석처리

#include "json.h" 위키문서 참조 JSON(제이슨[1]JavaScript Object Notation)은 속성-값 쌍으로 이루어진 데이터 오브젝트를 전달하기 위해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷이다. 비동기 브라우저/서버 통신 (AJAX)을 위해, 넓게는 XML(AJAX가 사용)을 대체하는 주요 데이터 포맷이다. 특히,인터넷에서 자료를 주고 받을 때 그 자료를 표현하는 방법으로 알려져 있다. 자료의 종류에 큰 제한은 없으며, 특히 컴퓨터 프로그램의 변수값을 표현하는 데 적합하다.

std::numeric_limits 이게 문제이다.
사용하는 코드(함수)인지 검색해본다.

사용안하면, 삭제


파일을 못찬느다는 에러나는 include는 과감하게 주석처리했다.

불필요한 코드도 대부분(?) 제거했다.


우선 메인부터 찾는다.

이 프로그램은 다이얼로그로 만들어져있다.

OnInitDialog, OnPaint, 통신, 키보드, 마우스, 파일처리등을 살펴본다.


static_cast<int>는 (int)(...)으로 바꾸면된다.

dynamic_cast<xxx*>는 (xxx*)로 바꾸면된다.




Posted by 안녕1999
, |

'i'는 'include'의 약자인듯함.
prefix는 '접두어', '미리 준비된' 등으로 해석하면 될듯함.
-iprefix 옵션은 include 디렉토리를 설정하는듯 함.


https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

 -iprefix prefix

Specify prefix as the prefix for subsequent -iwithprefix options. If the prefix represents a directory, you should include the final ‘/’. 

gcc 폴터에 있는 lib 폴더를 삭제하니, 컴파일 오류가 남.


arm-none-eabi-gcc: error: CreateProcess: No such file or directory

-iprefix XXXXXXXX\bin\../lib/gcc/arm-none-eabi/2.1.2/
-isysroot XXXXXXXX\bin\../arm-none-eabi


Posted by 안녕1999
, |

컴파일러 옵션에 "Link Incrementally" 기능이 있는경우가 있다.
이는 디버깅할때, 컴파일시간(링크시간)을 줄이기 위한 방법이다.
함수(코드)나 데이터 메모리 구간별로 어느정도 간격을 두어, 수정된 항목이 크지않다면,
해당 위치에 그냥 끼워넣는 링크 방식이다.
결과적으로 만들어진 실행파일은 좀더 커지나, 실행파일을 만들때 링크되는 시간이 감소하여,
조금더 빨리 디버깅을 할 수 있다.
디버깅할때, 컴파일(링크) 시간이 길다면, "Link Incrementally" 옵션을 켜는것이 좋다.

Posted by 안녕1999
, |

gcc컴파일러에, 사용하지 않는 변수를 경고나 에러처리할 수 있는 기능이 있나?



Posted by 안녕1999
, |

unresolved external symbol __imp__


DLL링크할때, DLL라이브러리가 없으면 발생함.

DLL관련 라이브러리를 찾아서, 해당 폴더에 넣어주어야 함.

Posted by 안녕1999
, |

void main()

{

int a;

int b;

int c;


a=1;

b=1;

c=a+b;

...

}


위와 같은 코드가 있을때,

컴파일 속도에 영향을 미치는 요인은 어떤것들이 있을까요?


눈에는 보이지 않지만, 문장의 끝에는 \r\n 2개의 문자가 들어 있습니다.

그리고 앞에는 Tab문자가 들어 있습니다.

컴파일러는 1문자당 1바퀴 루프를 돌게 되는게 일반적입니다.

루프문 1바퀴를 돌려면, 여러가지 조건이 있고, 이 조건을 포함해서 돌게되면,

최소 몇 클럭은 필요합니다.

1문자 때문에 최소 몇클럭씩 낭비가 되는것입니다.


위 코드를 아래와 같이 바꾼다면,


void main()

{

int a,b,c;


a=1;

b=1;

c=a+b;

...

}


개행문자(\r\n) 4문자와 "int " 2개, Tab 2개가 없어졌으니,

총 4+4+4+2=14문자가 사라졌습니다.

컴파일러는 14문자만큼의 루프를 덜 돌아도 되며, CPU클럭으로 따지면, 

1문자당 3클럭으로 계산해도, 최소 42클럭이상 빨라진것입니다.

또한 소스코드를 로딩할때도 이미 소모된 클럭이 있으므로, +@로 처리시간이 단축됩니다.


여기서 조금 더 나아가면,

- 변수명을 짧게

- 불필요한 공백을 사용안함


하면 +@의 효과를 얻을 수 있습니다.

물론, 코드의 가독성은 떨어집니다.

적당히 줄이세요.


"그거 줄여봐야 얼마나 되겠어?"

"요즘 CPU가 얼마나 빠른데?"


하시겠지만, 이런 수천 라인의 소스파일, 수천개를, 컴파일하게되면, 분명히 시간차이가 발생합니다.


또한, 파일에 저장하기위한 공간도 줄어듦니다.


무리하게 할 필요는 없고, 지금부터라도, 불필요한 공백은 자제합시다.



요약 : 불필요한 중복된 문자(동일한 변수형 반복), 불필요한 개행문자, 긴 변수명은 자제하자.





우스개 소리로, 예전에 마이크로 소프트사와 유닉스 진영에서 개행문자(\r\n)에 대한 논의(?)가 있었습니다.

유닉스진영에서는 개행문자가 \n 1바이트입니다만, 마이크로 소프으 윈도우에서는 \r\n 2바이트입니다.


컴퓨터에 있는 파일의 적지않은 용량의 파일이 택스트 문서이고,

해당 문서에서 개행문자때문에 소모되는 공간도 무시할 수 없다는 것입니다.

지구상의 모든 컴퓨터의 하드디스크에서 무시할 수 없는 공간이 낭비된다는 것입니다.

하드디스크 공간이 비약적으로 늘어나서, 그 피해가 너무 작을뿐, 낭비되는것은 맞습니다.


마이크로 소프트사에서는 이 문제 때문에, \r\n을 \n 으로 바꾸려는 시도를 하기도 했었습니다만, 엑셀, 비쥬얼베이직 같은 프로그램에서 문제가 발생하여, 중단한것으로 알고 있습니다.


유니코드문자를 사용하는 요즘에는 2배로 낭비되고 있습니다. ㅎㅎ

Posted by 안녕1999
, |

최근에 달린 댓글

글 보관함