본문으로 이동

컴퓨터공학/C샵/기초문법 강의

링크 추가
위키배움터

개요

[편집]

목표

[편집]

본 강의에서는 C#의 문법과 기본적인 사전에 정의된 키워드에(Pre-defined Keyword) 대해 소개하고, 아주 기본적인 예제들을 살펴보겠습니다. 덤으로 간단한 도전 과제도 풀어보도록 하죠.

또한, 이 강의에서 설명하는 내용들은 외우기 보다는 자연스럽게 손에 익을 수 있도록 지속적으로 참고하는 것에 초점을 맞춰주세요. 왜냐하면, 당신이 어릴적 한국어를 누구에게 배웠나요? 배웠다기 보다는 자연스레 습득했다는 표현이 옳습니다. 누가 강제로 가르친게 아니고, 스스로 듣고, 보고, 느끼면서 그 의미를 파악하고 잘 생각이 안나면 다시금 되집어보는 일련의 과정을 통해서 습득한 것이죠.

프로그래밍 언어 또한 그 맥락이 비슷합니다. 따라서 문법을 억지로 외우려 하기 보다는 되도록이면 자연스럽게 습득 할 수 있도록 학습하는 것이 바람직할 것입니다.(개인적인 견해) 이 강의에서 괄호 속 내용과 영문은 C# 언어에서 각 단어를 표현하는 용어이며, 그 자체로 보충 설명이자 그 개념, 의미를 명확히 하고자 기술하였습니다.

목차

[편집]

본 강의는 4개의 하위 주제로 구성되어 있습니다.

  1. 기초 문법
  2. 계층 구조와 추상 계층
  3. 객체의 생명 주기
  4. 템플릿

미리 보기

[편집]

뒤에서 설명할 내용은, 인간의 언어라고 가정했을 때, "객체(인스턴스, Instance)"와 그 "형태(클래스, Class)"를 선언하고, "의미(멤버, Member)"를 부여하며, 그 객체가 어떤 "동작(메서드, Method)"을 수행할 수있는지 정의하고, "문장 구조(명령문 및 문장, Statement and Expression)"를 형성하는 것에 초점을 맞춥니다.

이 강의에서 자세히 설명하지는 않는 내용이지만 "콘솔(Console, "System.Console")"이라는 이미 선언된 클래스에 소속된 정적 멤버(Static Member) 메서드 몇가지를 활용합니다. 이에 대해선 개별 파트에서 보충 설명을 하도록 하겠습니다.

(작성중 ...)

기초 문법

[편집]

객체를 이루는 요소

[편집]

프로그래밍 언어에서 "객체"는 분명히 논리적인 사물입니다. 실제 형태는 없고 개념만 있지만, 실제로 존재하는 것 처럼 취급합니다. 아이러니하게도, 논리적인 사물(추상적인 객체)을 설명하는 가장 좋은 방법은 아무래도 역시 현실에 존재하는 어떤 사물에 빗대어 설명하는 것이겠지요. 그래서 준비했습니다, 깡통을 한번 "프로그래밍적인 시각"으로 분석 해보도록 하죠.

깡통 분석
퀴즈 깡통[1]이라는 사물에서 "객체"는 "깡통" 그 자체입니다. 그렇다면, 그 "깡통"의 "형태"로 만든 어떤 "사물"은 "깡통"이라고 볼 수 있을까요? 만약 그렇다면 그 사물도 뭔가를 담을 수 있는 기능이 있을까요?

사전적으로 정의하자면 깡통은 "얇은 금속 재질로 된 용기[1]"라고 정의할 수 있습니다. 사전적인 정의와는 별개로 각자 "깡통은 무엇이다."라고 정의(객체의 정의)를 내리고, 그 단어를 떠올릴 때 그게 뭔지 굳이 떠올릴 필요 없이 인식합니다.

위 사진에 나온 그림 처럼 생긴 물건을 "깡통"이라는 이름(식별자, Identifier)으로 부른다는 걸 알기 때문일겁니다. 결국은 우리들은 깡통이라는 단어(식별자)를 어떻게 사용하느냐에 따라서 사물의 한 종류로서 깡통(클래스 식별자, Class Identifier)인지, 자신이 갖고 있는 깡통 한 개 또는 여러개(인스턴스, Instance)를 의미하는지 이해하게 되는 것이죠.

따라서, "식별자"라는 단어는 "어떤 형태나 객체를 식별하기 위한 어떤 글귀"라고 정의 내릴 수 있는 것입니다. 아주 간단한 예를 들자면 "나"라는 단어는 화자(話者) 자기자신을 가르키는 일종의 식별자 라고 볼 수 있는 것이죠.

우리들은 소설이나 신문 기사를 읽으면서 어떤 단어나 개념을 이해할 때, 그 것의 명칭과 단어의 배열을 기반으로 사고를 확장하고, 그 의미를 해석합니다. 그게 가능한 이유는 우리가 그 명칭을 이미 알고 있고, 어떤 의미인지 이해하고 있기 때문입니다. 예를들어, 사과를 먹으면 죽는다라는 이야기를 들었을 때, 백설공주라는 소설을 읽어 봤거나 디즈니 애니메이션으로 시청해본 적이 있다면 이게 그거를 비유한 것이라는걸 자연스레 인지하게 되는 것이죠. 읽어본 적없는 이들은 그게 무슨 이상한 소리야?(예외, Exception)라고 반응할지도 모를 일입니다.

설명이 엉뚱한 갈래로 빠져 들었을지도 모르지만, 컴퓨터가 저런 문장을 이해할 수 있다면 위 맥락에서 후자에 해당되는 반응을 보이겠죠. 그래서 컴퓨터에게 어떤 개념를 주입해 주고, 어떤 식별자에 대하여 설명해 줘야하는 것입니다. 이것을 정의한다(Define)고 표현(객체의 정의)합니다.

객체의 형태, 클래스(Class)

[편집]

독자분이 위에서 본 깡통을 설명하실 수 있는 방법은 정말 많습니다. 특히 한국어로 설명하려고 하면 아마 수없이 많은 표현들이 가능할 겁니다. 그 표현들은 규격도 다양하고, 서로 형태와 구성이 매우 다채로울 것 입니다. 하지만, 보통은 "이 물건은 깡통이라고 불리는..." 의미적 형태는 변하지 않을 것입니다. (언어로서 형태는 예외로 해 두죠)

C# 이라는 언어에서 그 형태를 정의하는 방법은 다소 단순합니다.

알류미늄 캔을 정의하는 방법(?) 일반적인 방법 (일반화) 
class AluminumCan {
    ... 여기에 클래스의 멤버들을 작성합니다 ...
}

class ClassName {
    ... 여기에 클래스의 멤버들을 작성합니다 ...
}
ClassName: 클래스의 이름을 지어서 바꿔주세요.

클래스의 이름 지정할 때(식별자를 만들 때) 반드시 지켜줘야 하는 규칙이 있습니다. 사람 이름을 지을 때 사회적 관례를 따라서 세 글자로 짓는 것과 유사한 규칙이라고 보시면 될 것 같네요. 물론 사람 이름을 짓는 것과 그 격과 강제성이 다르지만 비슷한 맥락으로 이해하시면 될 것이라 봅니다.

식별자는

  1. 언더바('_')를 제외한 특수문자를 포함할 수 없습니다.
  2. 반드시 특수문자나 숫자가 아닌 글자로 시작해야 합니다.
  3. 공백 문자나 줄 바꿈 등 제어 문자(Control Character)를 포함할 수 없습니다.
  4. 이미 존재하는 식별자나 예약어(키워드, Keyword)와 중복될 수 없습니다.

위 네가지 규칙은 강제적인 규칙입니다. 그 외에도 선택적인 규칙으로서, 식별자에 대한 표기법이란걸 규정하고 사용하기도 합니다. 그것은 강제적인 규칙이 아닙니다만(관례상 존재하는 규칙들이지만) 이를 따르는 것은 개발자의 성향에 따라 다르며, 개발팀 혹은 개발사(업체) 별로 달라집니다. 그 대표적인 예로 카멜 표기법(camel Case)과 파스칼 표기법(Pascal Case)이 있는데요,

카멜 표기법[2]을 따르는 식별자는

  1. 맨처음 문자는 반드시 소문자로 표기해야 합니다.
  2. 각 단어의 첫 문자를 대문자로 표기하고 붙혀 씁니다.

카멜 표기법에 맞춰서 식별자를 짓다 보면(네이밍, Naming), camelCase, backgroundKnowledge, niceTypeName 처럼 단어들이 낙타 등처럼 보입니다. 실제로, 낙타 등 처럼 보인다고 해서 카멜(낙타, Camel) 표기법이라고 부르죠.

카멜 표기법

파스칼 표기법을 따르는 식별자는 각 단어의 첫 문자를 대문자로 표기할 뿐(첫번째 글자 또한 대문자로 표기합니다) 특별한 차이는 없습니다. 또한 일부 개발자들은 파스칼 표기법을 카멜 표기법의 한 가지로 분류하기도 합니다. 그 외에도 많은 표기법이 있지만 Microsoft의 MSDN 문서들은 주로 파스칼 표기법을 사용하며 Visual Studio의 경우 기본 네이밍 규칙을 파스칼 표기법으로 지정하고 있는 것으로 보아 "파스칼 표기법"이 권장되는 것으로 생각되어집니다.

클래스의 정체성

[편집]

일상적으로 우리 주변을 살펴보면 휴대폰이나 컴퓨터, 모니터, TV 같은 "주변기기"들도 있고, 책상이나 서랍장 같은 가구 같은 수많은 사물(객체)들이 어떤 "장소"에 배치되어 있습니다. 그리고 우리는 그러한 사물들을 특정한 기준으로 분류 합니다. 그 분류가 제조사 별 분류일 수도 있고, 종류 별 분류일 수도 있죠. 사람마다 서로 그것들을 분류하는 방법은 매우 다양하지만, "각자의 기준"에 따라(네임스페이스, Namespace) 분류한다는 점은 분명 공통된 점일 것입니다.

네임스페이스 (Namespace)

[편집]

네임스페이스를 가장 단순하게 설명하자면, 위에서 표현한 대로 "각자의 기준에 따른 분류"라고 볼 수 있습니다.

퀴즈 아래에 나열된 단어들을 "이동식 사물"과 "고정식 사물"로 분류한다고 가정하고 아래 사물들을 각각의 분류에 넣어 보도록 합시다.
휴대폰, 노트북, 책상, 서랍, 변기, 식칼, 가위, 데스크톱, 침대, 이불, 베개

아마도, 물리적인 개념이 아주 다르지 않은 경우라면 보통은 아래 표에 나열된 것처럼 분류할 것입니다.

이동식 사물 고정식 사물
휴대폰, 노트북, 식칼, 가위, 이불, 베개 책상, 서랍, 변기, 데스크톱, 침대

아마도 바닥에 시멘트로 고정된 "변기"를 "이동식 사물"로 해석하는 분은 없을 거라고 생각하지만, 각자 나름의 기준이기 때문에 크게 문제가 있지는 않을 것입니다. 위 예시처럼 아주 단순한 경우라면 크게 문제가 되지는 않을 것입니다만,

"네가 필기한거 노트북(Notebook), 그, 그거 있잖아? 그거좀 아무튼 거기다가 좀 정리해 줄래?"

이 문장에서는 아마 그 상황의 문맥을 모른다면 "노트북"이 가르키는 바가 무엇인지 알기 어렵습니다. 물론 이 문장은 억지로 끼워 맞추느라 너무 단순해졌지만, 보통은 Notebook이라고 하면 "Notebook PC(또는 Laptop)"를 의미합니다. 그런데, Note-book은 "수첩"을 의미하기도 합니다. 결론적으로, 우리는 그 차이를 집어내서 이해할 수 있지만 상황에 따라 오해의 여지가 있고, 두가지 의미로 분기되기 때문에 보다 명확하게 지칭할 필요가 있습니다.

프로그래밍 언어에서도 유사한 상황이 비교적 자주 발생됩니다, 아니 오히려 인간 언어보다 상황이 좋지 못하죠. 우리는 모호한 단어를 듣게 되면 문맥을 되집어보고, 상대방에게 재차 물어봐서 확인을 거치지만, 프로그래밍 언어에서는 식별자가 중복되면 그게 정확히 뭐를 가르키는지 알 수 없기 때문에(Ambiguous, 모호하기 때문에) 오류로 간주됩니다.

업체 A와 업체 B가 같은 종류의 휴대폰을 생산한다고 가정했을 때 우리는 휴대폰의 모델명으로 그 제품 두가지 중 하나를 지칭하는데 유사한 맥락의 개념으로 "네임스페이스"가 있죠.

A사가 제조한 알류미늄 캔 B사가 제조한 알류미늄 캔 일반화된 네임스페이스 선언 
namespace CompanyA {
    class AluminumCan {
        ... 여기에 클래스의 멤버들을 작성합니다 ...
    }
}

namespace CompanyB {
    class AluminumCan {
        ... 여기에 클래스의 멤버들을 작성합니다 ...
    }
}

namespace NamespaceName {
    class ClassName {
        ... 여기에 클래스의 멤버들을 작성합니다 ...
    }
}
NamespaceName을 자신만의 식별자로 바꿔보세요!

이 때에 AluminumCan이라는 식별자는 "어느 곳에 소속된"이라는 "수식어"를 갖게 됩니다. 그렇다면, 정확히 A사의 알류미늄 캔을 지칭하려면 어떻게 해야 할까요?

힌트 우리는 어떤 회사가 생산한 어떤 제품을 "어떤 회사의 어떤 제품"이라고 표현하기도 합니다. 그런 비슷한 개념이 있지 않을까요?

C#이라는 프로그래밍 언어에서도 '~~의', 'of ~~' 등과 처럼 범위를 제한하는 표현이 있습니다. 바로 '멤버 접근 연산자'[3]라는 게 있습니다. 자세한 내용은 아래 "멤버" 섹션에서 설명하겠지만, 그 사용법 부터 짚어 볼까요?

위 클래스 두개는 각각 CompanyA.AluminumCan과 CompanyB.AluminumCan 처럼 명시적으로 지칭할 수 있습니다. 앞에 붙는 네임스페이스의 이름에 따라서 어떤 클래스를 지칭할 것인지 달리하게 되는 것이죠.

(TODO: Scope 개념에 대한 보충 설명 필요 - 그러나 "객체에 독립적인 멤버 (Static) 섹션"으로 유도)

클래스와 유사한 개념, 구조체 (Structure)

[편집]

클래스라는 개념은 어떤 객체의 형태를 표현하는데 초점이 맞춰져 있습니다. 그 행위와 동작, 데이터 등을 포함 한다고 설명할 수 있습니다. 그렇다면, 객체가 아닌 데이터를 표현하는 방법은 뭐가 있나요? 예를 들자면 대학교에서 시험을 치면, 학기 말에 성적 통지서가 발송됩니다. 성적 통지서는 "종이"라는 객체에 "성적"이라는 데이터(값)를 인쇄한 것이죠. 그 내용는 커터 칼로 긁어내서 변조한 후 부모님께 보여드릴 수 있는 "사본"입니다. 그러나 대학교 학생 정보 시스템에는 "원본" 데이터가 그대로 보관되어 있을 것입니다. 그래서 부모님의 확인전화 한통이면 언제든지 야구 방망이로 맞을 수 있는 기회(?)가 찾아옵니다.

물론, 클래스 정의로 데이터의 이러한 성질도 구현할 수 있지만, 자연스러운 방법은 아닙니다. 상식적으로, 휴대폰이라는 객체는 새 제품으로 바꿀 순 있지만, 그건 전혀 다른 객체이지 않을까요? 왜냐하면 그 안에 들어있는 데이터가 분명히 다르며 클라우드니 뭐니 해서 완전히 동일한 데이터로 동기화를 받더라도, 물리적인 상태는 외양이 동일해 보일 뿐 온전히 동일한 상태로 만들 수는 없기 때문입니다.

힌트 여러분이 맨 위의 사진[1]처럼 생긴 깡통 한개를 도색 공장에 보냈다고 가정해 보죠. 추가로 빨간색으로 도색해달라고 주문도 했어요. 보내기 전에 실수로 한번 깔고 앉아서 찌그러졌지만 아마도 도색 이후에 받은 깡통의 색은 빨간색일 겁니다. 그리고 또 찌그러진 채로 도색이 되어 있겠죠. 아, 찌그러진걸 보니 그 깡통이 이 깡통이에요.

C#에서 객체를 유통할 때, 기본적으로 "참조(Reference)"를 전달합니다, 현실적인 개념으로 생각해 보자면, 제 컴퓨터를 원격 조종할 수 있는 계정(참조)을 나눠주는 것 입니다. 따라서 그 객체를 가지고 무슨 짓을 하면 돌이킬 수가 없어요. 찌그러진 깡통이 색갈만 바껴서 그대로 돌아온 것 처럼 말입니다.

C# 객체 전달에 대한 보충 자료

이러한 전달 방식을, ByRef(By Reference, 객체 자체를 제공)라고 하며, 반대되는 전달 방식은 앞서 설명했던 "사본"과 "원본"이 따로 구분되는 것, ByVal (By Value, 값만 전달)이라고 합니다.

성적표 데이터 일반화된 구조체 선언 
struct ScoreData {
    ... 여기에 클래스의 멤버들을 작성합니다 ...
}

struct StructName {
    ... 여기에 클래스의 멤버들을 작성합니다 ...
}
StructName을 자신만의 식별자로 바꿔주세요~

그리고, 클래스는 기본적으로 Reference Type (참조 형식)이며, 구조체는 기본적으로 Value Type (값 형식)입니다. (TODO: 좀더 자세하고 이해하기 쉽게 수정할것)

멤버 (Member)

[편집]

이 섹션은 어떤 객체가 "어떤 기능"을 수행할 것이냐, 또는 "어떤 데이터"를 보관하고 "어떻게" 가공할 것이냐에 관한 내용입니다.

멤버의 종류

[편집]

클래스를 구성하는 요소 중, 멤버가 차지하는 비율은 거의 99% 입니다. 1%는 클래스 정의 그 자체라고 봐도 무방합니다. 멤버의 하위 개념으로, 필드, 메서드, 속성, 이벤트 등을 꼽을 수 있는데, 이들에게 부여하는 수식어에 따라서 그 명칭과 접근성이 변화하게 됩니다. 필드의 가장 좋은 사례는, 은행 계좌를 예로 들어보죠. 누군가에게 송금할 때 저희는 "잔고"를 확인하고, 부족하다면 추가로 "입금"을 하거나 송금을 포기합니다. 그 때 그 잔고를 통장이라는 클래스의 "멤버"라고 할 수 있습니다. 

namespace Bank {
    class Account {
        // 계좌 잔고를 보관하는 정수입니다.
        private int m_Balance;

        // 잔고를 확인하거나 잔고를 추가하고, 잔고를 뺍니다.
        public int Balance {
            get => m_Balance; 
            set { 
                if( value < 0 ) Get(-value);
                else Put(value);
            } 
        }

        // 예금 합니다.
        public void Put(int HowMuch) => m_Balance += HowMuch;

        // 예금했던 돈을 되찾아 갑니다.
        public void Get(int HowMuch) => m_Balance -= HowMuch;
    }
}

이런 형태로 표현할 수 있을 겁니다. 위에서 설명하지 않았던 생소한 문장들이 다수 보입니다. 아래로 내려가면 설명이 있으니 걱정하지 마시고, 계속 읽어주세요.

위 코드에서 멤버들을 짚어보자면,

코드 종류 접근성 목적 
private int m_Balance;
정수 필드 비공개 계좌 잔고를 보관합니다. 
public int Balance {
    get => m_Balance; 
    set { 
        if( value < 0 ) Get(-value);
        else Put(value);
    } 
}
정수 속성 공개 잔고를 확인하거나 잔고를 추가하고, 잔고를 뺍니다. 
public void Put(int HowMuch) => m_Balance += HowMuch;
메서드 공개 예금을 추가 합니다. 
public void Get(int HowMuch) => m_Balance -= HowMuch;
메서드 공개 예금했던 돈을 되찾아 갑니다.

뭐가 뭔지는 모르지만, Bank.Account 라는 은행 계좌가 보관해야 할 것과, 수행할 수 있어야 하는 동작을 정의하고 있습니다. 결론을 먼저 살펴보자면, 어떤 동작을 수행할 것인지, 무엇을 보관할 것인지에 따라서 사용하게 될 멤버 종류가 달라진다는 것이죠.

멤버의 종류는

  1. 필드: 어떤 값이나 객체를 보관하는 목적으로 사용됩니다.
  2. 메서드: 내부의 필드들을 가공하는 등의 어떤 동작을 수행합니다. 우리 말로 치면 동사인 셈이죠.
  3. 속성: 필드를 직접 수정하거나 읽어 가기 전 특별한 가공을 해줘야 할 때 사용됩니다.
  4. 이벤트: 객체 내에서 어떤 "사건"이 발생한 경우 알려줘야 할 때 사용됩니다.

이렇게 4가지로 구성됩니다. (필드, 메서드, 속성, 이벤트에 대한 간략한 설명)

아무나 접근 할수 있다고?

[편집]

C#에서는 "한정자"라고 불리는 키워드들을 달아주지 않으면 기본적으로 비공개 "한정자"가 달려 있는것으로 가정하게 됩니다. 자기 자신을 제외한 다른 객체들이 접근 할 수 없게 되는 것이죠. 위에서 미리 살펴본 public, private라는 키워드들이 하는 역할입니다. 이들을 "접근 제한 키워드"라고 부르기도 합니다.

접근 한정자 설명
public 이 키워드를 지정하게 되면, 해당 멤버는 모두가 읽거나 쓰는 등 완전한 접근이 가능해집니다.
protected 상속 구조에 대해 자세히 다루지는 않았지만, 클래스간의 상속 구조에서, 상속을 받은 경우에만(자식 클래스에서만) 접근할 수 있도록 제한합니다.
private 자기 자신 이외의 다른 객체에서 접근하는 것을 제한합니다. (자기 자신만 접근할 수 있습니다)
internal 같은 어셈블리(추후 설명)에 속한 클래스간의 접근만 허용합니다.

(public, protected, private, internal 접근 한정자)

객체에 독립적인 멤버 (Static)

[편집]

(static 수식어 설명)

자료형도 멤버의 일종인가? (Nested Type)

[편집]

(계층 구조에 관한 간단한 설명, 목차에 있는 계층 구조와 추상계층으로 유도)

스코프 (Scope) 개념

[편집]

(네임스페이스, 클래스, 구조체 등 '자료형(이름 공간)'의 중첩을 마트료시카[4]에 빗대어 설명)

한 줄로 늘어선 마트료시카.

객체의 기억, 필드 (Field)

[편집]

(멤버 변수, 즉 필드의 개념과 초기화 시점 설명, 정적 멤버 변수에 대한 설명도...) (배열에 대한 설명도...)

객체가 수행할 동작, 메서드(Method)

[편집]

(멤버 메서드에 대한 설명, 정적 멤버 메서드에 대한 설명)

지역 변수 (Local Variable)

[편집]

(메서드에서 지역 변수의 한계, 역할 설명)

호출 인수 (Parameter)

[편집]

(호출 인수가 지역 변수로 취급되는 이유와 out, ref 키워드 설명)

반환형과 그 값 (Return Type and its Value)

[편집]

(return 키워드 설명)

객체의 초기화, 생성자 (Constructor)

[편집]

(더 세부적인 내용을 객체의 생명주기 여기로,... 기본 생성자에 관한 내용만 여기서 다룰 것)

객체의 속성 (Property)

[편집]

(n차 가공된 필드의 개념과, getter, setter 설명)

뭔 일 있으면 좀 알려줄래? 이벤트 (Event)

[편집]

(객체 외부에서 특정 동작을 연계할 수 있는 여지, 확장성에 대한 설명) (이벤트 핸들러로 하면 안 되는거 소개)

C# 코드의 실행과 진입점

[편집]

간단한 예제

[편집]

Hello World

[편집]

으음,...

[편집]

도전과제

[편집]

LinkedList 구현하기

[편집]

Tree 구현하기

[편집]

결론

[편집]

ㅇㅇ

과제 C#으로 사람과 인간관계를 표현해봅시다!

결론

[편집]

이 강의의 결론을 기술합니다.

과제 한번 쯤 만들어 보면 좋을 프로그램을 짜 보는 간단한 과제를 제시합니다. (Futhermore의 개념)

디자인 패턴(인 경우에만 작성합니다)

[편집]

이 강의가 디자인 패턴과 관련되어 있을 때 혹은 있다고 판단될 때 기술합니다.

-->

같이 보기

[편집]

관련 강의

[편집]

<-- 위키 배움터 내 게시글을 배열합니다. 예:

  1. 포털:컴퓨터공학/C샵

-->

외부 링크

[편집]
  1. Value type and reference type (위키백과)
  2. .NET Memory Management Poster by @konradkokosa

각주

[편집]
  1. ↑ 1.0 1.1 1.2 위키백과 인용, 깡통(-筒←can통, 캔)은 얇은 금속 재질로 된 용기를 말한다. N.아페르에 의해 발명된 통조림이 그 시초이다.
  2. ↑ 카멜 표기법: 위키백과, 낙타 대문자
  3. ↑ 멤버 접근 연산자: 마이크로소프트 공식 문언, 멤버 접근 연산자
  4. ↑ 마트료시카, 위키백과 참조: https://ko.wikipedia.org/wiki/%EB%A7%88%ED%8A%B8%EB%A3%8C%EC%8B%9C%EC%B9%B4
원본 주소 "https://ko.wikiversity.org/w/index.php?title=컴퓨터공학/C샵/기초문법_강의&oldid=27301"