* 의존성관리 C 와 같은 헤더 파일들은 의존성 분석과 빠른 컴파일을 하는 것과는 상반된 형태를 가지고 있다 . * 인기있는 시스템 언어들은 GC 와 병렬 계산에 대한 지원이 부족하다 .
세미콜론이 필요없다는 얘기
64 가장 좋고 arm: 불완전하지만 Nexus One 에서 테스트되었고 The compilers can target the FreeBSD, Linux, and OS X (a.k.a. Darwin) operating systems. (A port to Microsoft Windows is in progress but incomplete. See the Windows Port page for details.) 쉘로 가서 gtug/hello 들어가서 8g, 8l 등 컴파일 실행파일 비교 컴파일 , Makefile 사용 go/ 소스트리 대충 설명
() 는 없고 , { 는 필수
() 는 없고 , { 는 필수
() 는 없고 , { 는 필수
iota - 극히 적은 양
slice 는 size 없이 선
slice 는 size 없이 선
slice 는 size 없이 선
slice 는 size 없이 선
T type 을 위한 메모리를 할당하고 그 주소를 리턴한다 . Because we need to make a slice, not just allocate the memory. Note make([]int, 10) returns []int while new([]int) returns *[]int. slice, map, channel 같은 type 은 사용하기 전에 반드시 초기화 되어야 하는 data structure 를 레퍼런스 하고 있기 때문에 make 를 사용해야 한다 . new 를 사용하면 저렇게 된다 .
duck typing 얘기 .. Go 는 클래스가 없지만 메서드를 붙일 수 있다 . 메서드는 리시버를 가진 function 이다 . built-in type 들한테 메서드를 만들 수는 없지만 type Foo int func (f *Foo) MyFunc() { println("OK") } func main() { var a Foo a.MyFunc() } 이렇게 가능하다 . (f *Foo) 와 (f Foo) 의 차이가 뭐지 . 이렇게 function 이 method 가 되면 function 처럼 호출 안됨 (undefined error)
* interface 는 구현하지 않은 메서드들의 집합이라는 점은 다른 언어와 같다 . * inheritance 가 아닌 delegation 을 통해 class 의 상속이 아닌 다른 클래스를 통해 기능을 확장하는 바 ---------------------------------------- package main type I interface { Get() int Put(int) } type S struct { i int } func (p *S) Get() int { return p.i } func (p *S) Put(v int) { p.i = v } func main() { var s S f(&s) } S 가 I 를 구현했는지 안했는지 run-time 시 알아내는 방법 2 가지 func f(p I) { switch t := p.( type ) { case *S: case *R: case S: case R: .4. default: } func f(p I) { if t, ok := p.(I) ; ok { println("ok", t, ok) } else { println("not", t, ok) } } * 왜 implements 를 사용하지 않느냐 ? duck typing. 관심사를 분리한다 . 이미 구현된 struct, method 형태 ( 클래스 형태 ) 에서 인터페이스만 나중에 뽑아낼 수도 있다 . 이렇게 하면 기존 코드를 고치지 않고 인터페이스가 정의되고 사용할 수 있게 되는 것이다 . Go 는 type hierarchy 가 없다 io.Writer 인터페이스에는 Write() 메서드가 있는데 이걸 구현하고 있는 애들에 따라 다양한 Write 가 가능하게 되는 것이다 .
defer 와 함께 panic, recover 빌트인 function 도 정리해야 할 것 http://blog.golang.org/2010/08/defer-panic-and-recover.html
There are many terms for "things that run concurrently" - process, thread, coroutine, POSIX thread, NPTL thread, lightweight process, ..., but these all mean slightly different things. None means exactly how Go does concurrency. So we introduce a new term: goroutine. 다른 goroutine 들과 same address space 에서 뱅행적으로 시
There are many terms for "things that run concurrently" - process, thread, coroutine, POSIX thread, NPTL thread, lightweight process, ..., but these all mean slightly different things. None means exactly how Go does concurrency. So we introduce a new term: goroutine. 다른 goroutine 들과 same address space 에서 뱅행적으로 시
select 라고 <-c 두번 안해줘도 되는 방법 이
왜 try-catch-finally 가 없는지에 대한 좋은 글 http://blog.golang.org/2010/08/defer-panic-and-recover.html
![Overview ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)