To Escape

종로5가역 2번출구, 큰 길 안쪽에 위치한 '남해 굴국밥'. 각굴은 너무 큰 경우가 있지만 굴국밥에 들어가는 굴은 적당해서 좋습니다. 굴의 양은 흡족할 정도로 많지 않아 아쉽긴 했지만 맛은 좋네요. 메뉴에 홍어도 있다는 걸 보고서 다음 날에도 방문했습니다. 위 사진은 홍어전. 혼자 먹기엔 많은 양이라 3점 남겼습니다. 오랜만에 입 안이 다 벗겨졌네요. 혓바닥까지 벗겨지는 경험은 처음이었습니다. 😂😂😂😂😂 🍖🍖🍖🍖 (4/5점)

5. 데이터형 규정 5. 2 고정 크기 정수 규정 정수형의 크기가 중요하다면 고정 길이 데이터형을 char, short, int, long, 또는 long long형 대신 사용해야 한다. 부호 없는 또는 부호 있는 고정 길이 정수형은 아래 표와 같다. Integer Width Signed Type Unsigned Type 8 bits int8_t uint8_t 16 bits int16_t uint16_t 32 bits int32_t uint32_t 64 bits int64_t uint64_t 키워드인 short, long은 사용할 수 없다. 키워드인 char의 사용은 문자열에 관한 선언 및 연산으로 제한되어야 한다. 이유 C90 표준에서는 의도적으로 char, short, int, long 그리고 lon..

5. 데이터형 규정 5. 1 명명 관례 규정 구조체(structure), 유니언(union) 및 열거(enumeration)를 포함한 모든 새로운 데이터형의 이름은 소문자와 단어 내부의 밑줄로만 구성되어야 하며 ‘_t‘로 끝나야 한다. 모든 새로운 구조체, 유니언형 및 열거형은 typedef 통해 명명되어야 한다. 모든 public 데이터형의 이름은 모듈 이름과 밑줄을 앞에 붙여야 한다. 예시 typedef struct { uint16_t count; uint16_t max_count; uint16_t _unused; uint16_t control; } timer_reg_t; 이유 데이터형 이름과 변수 이름은 종종 유사합니다. 예를 들어, 주변장치에서 타이머 제어 레지스터 세트가 'timer_reg' 이..

4. 모듈 규정 4. 4 파일 템플릿 규정 헤더 및 소스 파일에 대한 템플릿은 프로젝트 수준에서 유지 관리되어야 한다. 이유 새 파일을 작성할 때 템플릿을 이용하면 첫머리 코멘트 블록의 일관성이 보장되고, 저작권 고지 사항을 확실히 할 수 있습니다. 시행 파일 형식의 일관성은 코드 검토시 시행되어야 합니다.

4. 모듈 규정 4. 3 소스 파일 규정 각 소스 파일에는 하나의 entity를 제어하는 적절한 동작만 포함해야 한다. entity의 예로는 캡슐화된 데이터 타입, 활성 객체, 주변장치 드라이버(예: UART), 통신 프로토콜 또는 계층(예: ARP) 등이 있다. 각 소스 파일에는 다음 섹션의 일부 또는 전부가 열거된 순서대로 구성되어야 한다. 주석 블록, #include문, 데이터 유형, 상수 및 매크로 정의, 정적 데이터 선언, private 함수 프로토타입, public 함수 몸체 그리고 private 함수 몸체. 각 소스 파일은 컴파일러가 public 함수와 해당 프로토타입이 일치하는지 확실히 할 수 있도록 동일한 이름의 헤더 파일을 포함해야 한다(예: 파일 adc.c에는 #include "adc..

아이패드에서 리디북스로 이북을 읽으며 애플 펜슬 더블탭을 하면 다음장으로 넘어가는 기능이 있네요. 이제사 발견했는데 언제부터 지원했는지 몰겠지만 누워서 볼 때 유용할듯.

2006년 출간. 저자는 레이 커즈와일과 테리 그로스만 미래학자인 레이 커즈와일이 공동 저자라 알게되어 읽었다. 먹거리에 대한 조언들, 첨단 현대의학을 소개하며, 광범위한 보충제나 약도 소개한다. 특히 심장병, 암에 대해 자세히 설명하며 뇌, 호르몬, 성 호르몬, 보충제, 운동, 스트레스도 별도의 장을 할애했다. 🍖🍖🍖 (3/5점)

4. 모듈 규정 4. 2 헤더 파일 규정 각 소스 파일에 대해 정확하게 하나의 헤더 파일이 있어야 하며, 항상 동일한 루트 이름을 가져야 한다. 각 헤더 파일은 아래의 예와 같이 다중 include에 대응하기 위한 전처리기를 포함해야 한다. 헤더 파일에는 (프로토타입 또는 매크로, #define 및 typdefs를 통해) 다른 모듈과 비교해 엄격하게 알릴 필요가 있는 프로시저, 상수 및 데이터 형식만 표시해야 한다. 헤더 파일에 (extern을 사용한) 어떤 변수도 선언하지 않는 것이 선호되는 관행이다. 어떤 변수에 대한 저장 공간도 헤더 파일에서 할당되어서는 안된다. public 헤더 파일은 private 헤더 파일을 #include 할 수 없다. 예시 #ifndef ADC_H #define ADC_H..

4. 모듈 규정 4. 1 명명 관례 규정 모든 모듈 이름은 소문자, 숫자 및 밑줄로 구성되어야 합니다. 헤더 및 소스 파일 이름에 공백을 사용하면 안됩니다. 모든 모듈 이름은 앞 8자에 의해 고유해야 하며 헤더 및 소스 파일 이름에 대해 각각 .h와 .c로 끝나야 합니다. 모듈의 헤더 파일 이름은 C 또는 C++ 표준 라이브러리의 헤더 파일 이름을 공유해서는 안 됩니다. 예를 들어 모듈의 이름은 “stdio” 또는 “math“로 지정해서는 안됩니다. main() 함수를 포함하는 모듈은 소스 파일 이름의 일부로 “main”라는 단어를 포함해야 합니다. 예시 /** @file crc.h * * @brief Compact CRC library for embedded systems for CRC-CCITT, C..

3. 공백 규정 3. 6 출력되지 않는 문자 규정 가능하면 모든 소스 코드 라인은 'CR'-'LF'(0x0D 0x0A)가 아닌 단일 문자 'LF'(ASCII 0x0A)로만 끝나야 한다. 소스 코드 파일에서 허용되는 또다른 출력되지 않는 문자는 form feed 문자 'FF'(ASCII 0x0C)뿐이다. 예시 출력되지 않는 문자는 나타낼 수 없습니다. 이유 다중 문자 'CR'-'LF'는 단일 문자 'LF'보다 다중 플랫폼 개발 환경에서 문제를 일으킬 가능성이 높습니다. 이러한 문제중 하나는 유닉스 플랫폼의 다중 라인 전처리기 매크로와 관련있습니다. 시행 에디터 프로그램은 LF를 사용하도록 설정되어야 합니다. 또한 자동화된 도구는 빌드 중에 모든 새 소스코드 또는 수정된 소스코드 파일을 스캔하여 CR-LF ..