-
Notifications
You must be signed in to change notification settings - Fork 10
/
0324.txt
464 lines (464 loc) · 17.3 KB
/
0324.txt
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
예 안녕하세요 포프입니다
제가 예전에 한창 C++ 11이 나올 때
C++ 11 비디오를 꽤 많이 만들었어요
한 서넛 다섯 여섯 개?
왜냐면
C++은..
굉장히 오랫동안 정체돼 있다가
드디어 좀 쓸 만한 게 C++ 11부터
나오기 시작을 했거든요
근데 이제, C++ 커뮤니티가
그 다음에 무슨 약을 빨았는진 모르겠지만
3년마다 새로운 표준을 내겠다고 이제 막, 뭐..
뭐랄까..
열심히 하고 있죠
제가 "C++ 표준에 대한 불만"
이라는 비디오에서도 말했듯이
그게 좀..
뭐라 그럴까
음..
효율적이라고 그러긴 좀 어렵고
방향이 하나 맞는 거 있잖아요
그 뭐라 그러지?
그니까 모순되지 않고 이렇게,
좀 이렇게 한 방향으로 이제
누구 하나가 비전 딱 잡고
끌고가는 그 방향이 아니기 때문에
이제 요즘 나오는 새로운 언어들에 비해
너무 중구난방적으로
이상한 스탠다드가 나오고
그 스탠다드가 정말 C++에..
그니까 여전히 C++을 쓰는 이유가 있어요
그리고 C++은 절대 자바(Java)한테
밀리지 않는 이유도 있고
그 이유는 이제 전혀 둘이
사용할 곳이 다르기 때문이죠
그렇다고 C#이 C++을 밀지도 못 할 거고
C++이 아직도 쓰이는 이유가 있고
그거를 많이 쓰는 업계가 있는데
그거를 무시한 채 너무 학문적으로
계속 이상하게 끌고가다 보니까
C++의 장점,
우리가 아직도 쓰고 있는 이유가 되는
장점을 무시하는 표준이
너무 많이 나오거든요
그게 실제 C++ 표준이 나올 때마다
이제 업계에서는
아 여기서 쓰지 말아야 될 게 뭐냐
그 쓰지 말아야 할 80, 90%의 것을 정리하는 데
굉장히 많은 시간을 소비를 해요
그래서 코딩 스탠다드에서
이거 쓰지 마라
저거 쓰지 마라
저거 쓰지 마라가
매번 늘어나고 있어요
그럼에도 불구하고
몇 가지 좋은 게 있죠
그래서
그 이후에 솔직히 C++
관련 비디오를 만들 일이
그렇게 많지가 않았던 게
C++ 11에서 14는 굉장히
작은 업데이트였어요
그냥 좀 잘못된 거 고치는 정도였고
17이 큰 업데이트긴 한데
C++ 11보다 C++ 17의 업데이트가
그렇게 크지도 않아요 사실은
그리고 들어온 것 중에
제가 가끔 트위터로 막
"아 이거 절대 쓰지 말라고
무슨 짓이냐고"
이런 정도까지 나오는 게 C++인데 현재
그럼에도 불구하고
제가 C++ 17에서 나왔던 거,
11부터 나왔던 거긴 하지만
17에서 좀 더..
뭐랄까
용이한 거?
정말 괜찮은게 나왔던 게
Attribute 쪽이에요
Attribute가 뭐냐
뭐 C# 프로그래머 하신 분들은
그런 거 많이 했을 거에요
뭐 이제
자바(Java), 스프링(Spring) 쪽 하신 분들도 그렇고
클래스 명이나 함수 명 위에
이렇게 네모난 곽 괄호 있잖아요
그거 넣고 막 이렇게 써 놓는 거 있잖아요
이게 무슨 컨트롤러니
뭐 라우트가 어떻게 되니
그런 것들을 이제 Attribute라고 해요
뭐 JSON, .NET 써 보신 분들은
이게 뭐, JSON property라든가
property name이 뭐라든가
실제 코드는 아니지만
Attribute를 다룸으로 인해서
다른 코드가 이거를
처리하는 데 도움이 되는 거
뭐 XML 시리얼라이저(Serializer)라면
이거 이름을 뭘로 해야 되는지 정해 주고
그런
코드 로직이 아닌
디스크립터 (Descriptor)같은 게 Attribute거든요?
그래서 이런 Attribute가 사실은,
C++에도 있긴 있었어요
그런데 표준이 아니라
각 컴파일러(compiler)마다 있었죠
뭐, restrict 이런 것도 있었고
근데 이제 그게 드디어 표준으로
넘어오기 시작하는 거에요 그러면서
표준으로 넘어올 때 Attribute가 괜찮은 게 있고
아까도 말했지만,
'이거 쓰면 뭐 하라는 거지?'
'오히려 더 큰 문제가 생길 수도
있는 게 아닌가?'라는 것도 있고요
그리고 이제 마이크로소프트(Microsoft) 쪽
코드를 옛날부터 좀 많이 보셨던 분들,
예제가 아니라 실제 거기 마이크로소프트(Microsoft)
회사 안에서 돌리는 코드를 보신 분들은 이제,
이름이 정확히 기억이 안 나는데
아마 Secure Attribute Language
라는 게 있었을 거에요, SAL이라고
그것도 되게 비슷한 개념이었어요
예를 들어서, 매개 변수 하나가 들어올 때
이 매개변수가 const냐
이 매개변수가 output으로 바뀌는 값이냐
이 매개변수가 뭐냐
뭐 이 매개변수의, 이제 뭐 아까 restrict처럼,
메모리(memory)가 서로 겹치냐 안 겹치냐 이런 것들을
되게 Attribute를 열심히 박아 두고
컴파일(compile)할 때 그거를
이제 판단을 해 주는 거죠
니 코드를 함수에서 짠 걸 봤는데,
이 Attribute에서 말한 거에 부합하지 않으니까
워닝(warning)을 준다거나
이런 식으로 많이 썼고
아, 뭐 이제
그 Attribute 하나에 이제..
제가 Attribute의 목적을 두 개로 보는데,
그 하나가 컴파일러 워닝(compiler warning)이에요
실제 C++을 코드를 잘못 짜면은
온갖 이상한 일이 일어날 수 있는 게,
되게 위험한 언어기도 하거든요
그만큼 되게 주의해야 되는 언어고
그래서 그런
잡다한 Attribute를 닮으로 인해서
컴파일러(compiler)가 체크를 해줘서
"야 이거 너 문제가 있어
봐라"라고 해줄 수 있는 거
그게 한 가지의 목적이고
두 번째 목적은 실제 컴파일러
(compiler)가 최적화를 할 때
Attribute를 봐서, 아 이거는 이렇게 최적화를
해도 된다고 프로그래머가 말을 했어
이 함수는 절대 메모리(memory)가 서로
오버랩(overlap)되는 경우가 없다고 했으니까
이걸 이렇게 최적화를 해도 상관이 없다라고
가정을 하고 최적화를 해서 코드를 만드는데
문제는 이 함수를 호출할 때
라이브러리 외부나 이럴 때
메모리(memory)가 겹치게 호출하거나 그러면
실제 코드가 어떻게 돌 지는..
몰라요
뻑이 날 수도 있고
굉장히 이상하게 뻑이 날 수도 있어요
그런 문제가 있죠
그래서
Attribute의 목적의 목적이 두 개가 있지만
저는 기본적으로
최적화를 위한 Attribute는
최대한 피하자주의에요
잘못 짰을 경우에..
아무 생각 없이 짰다가 그게 막 터져요
코드에서 아무 문제가 없는데 터져
그러다 이제 점점 고민하다가
디버깅(Debugging)하기가
되게 어려워지는 경우거든요
거의 어셈블리(Assembly) 수준의 코드를 보고
디버깅(Debugging)하지 않는 이상
되게 어려워지는 코드 중의 하나기도 해요
그래서 그런 부분에 있어서는 좀..
그니까..
Premature Optimization 애기 하잖아요
너무 섣부른 최적화
그런 개념 위에서 하는 건 되게 문제가 있고
정말 이거를 어떻게 만들어서 마지막 1%의
성능을 뽑아내야 될 때라면은 가능한 얘기지만
그런 경우는 생각보다
아주 많지는 않기 때문에
Attribute는 그냥 프로그래머가 쓰는 그런
실수를 막는 용으로 쓰는 게 좋다라는
개념으로 잡고 얘기를 시작해야 될 것 같아요
우와!
문장이 되고 길고 서문이 엄청 길었어요
근데
결과적으로 제가 말하고 싶은 Attribute는
한 다섯 개 정도가 있어요 사실은
그 중의 하나는 "절대 쓰지 마세요"라고
하고 싶은 Attribute 중의 하나고
하나는 이제, 제일 간단하게 볼 수 있는 게
디프리케이트(deprecated)에요
디프리케이트(deprecated)하면은
"이 함수는 더 이상 사용하지 마세요"
"그 대신 다른 함수를 사용하세요
이런 버전이 있습니다"라는 메세지가
컴파일 도중에 나오는 거죠
자바(Java)에도 있고
C#에도 있는 거죠
그게 생겼어요
그래서 이제
C에서
Attribute를 달 때는
이 곽 괄호가 두 쌍이 들어가요
곽 괄호 두 쌍을 넣고
거기다 디프리케이티드(deprecated) 넣고
둥그런 괄호 열고 거기다 그 이유를 적어두면은
컴파일(compile) 도중에
워닝(warning)을 보여 줘요
뭐 예를 들어서
뭐, GetMatrix란 함수가 있다 그러면
거기다 데프리케이트(deprecated)를 달아두면은
"아 매트릭스란 함수는 이제 더 이상.."
이제 뭐, "은퇴할 함수니까"
"이거 대신에 GetMatrix2를 쓰세요"라든가
이런 식으로
뭐 에러 메세지(error message), 워닝 메세지
(warning message)를 넣어 줄 수 있다는 거죠
그래서 그게 있고
두번째는
제가 이게 솔직히 제일 좋아하는 거에요
fall-through라는 게 나왔어요
그러니까
fall-through라면 f.a.l.l
through라면은 이제,
통과해서 흘러내리다
의미거든요?
이게 왜 중요하냐면
C++도 그렇고 C#도 그렇고
굉장히 예전 언어들이
switch-case문을 쓸 때 case 0, 1, 2, 3이 있으면,
case 0이 끝나고 break를 하지 않으면
그 다음에 있는 case 1코드까지
실행이 됐거든요
근데 이게
어떤 사람이 실수로 break를 안 넣어 버리면은
코드가 확 실행이 되는데
잡지를 못해요 생각보다
생각보다 그렇게 쉽게
찾을 수 있는 버그가 아니에요
그래서 이제 러스트(Rust) 류의 새로운 언어들은
그런 경우에 아예 컴파일러 에러(compiler error)를 주고
니가 정말 case 0에서 case 1으로
같이 실행이 되게 하고 싶으면
fall-through라는 명령어를 넣게 돼 있어요
그래서 이제
그런 이제
비슷한 게 여러가지 언어에서 나오고 있고
그래서 제가 C++에서 제가 썼던
코딩 스탠다드(coding standard)에도 언제나 그랬어요
니가 case 0에서 case 1으로 넘어갈 때는,
그 당시 Attribute가 지원이 안 됐으니까,
커멘트(comment)를 달고
fall-through라고 써라
왜냐면 그러면 코드를 읽다가
아, 내가 일부러 case 0하고 case 1을
실행되게 하는 거란 걸 보여 주는 거니까
가독성을 위해 그랬죠
근데 이제는 그게
Attribute로 나온 거에요
그래서 그렇게, fall-through를 할 때
Attribute를 직접적으로 넣어 줘야 되고
안 넣어 줘도 크게 문제는
현재는 없을 것 같아요
backward compatibility가 있으니까
근데 분명히 그걸 나중에
워닝(warning)으로 키거나
에러(error)로 만드는 법이
있을 것 같다고 생각을 해요
그래서 fall-through를 반드시 안 넣어 주면은
이제 워닝(warning)이 나게
에러(error)가 나게
그래서 이제
그게 이제 전 되게 좋다고 보는 거고
그게 두 번째 거였고
이제 세 번째가
maybe_unused
maybe_unused가 뭐냐면
그 어떤 변수를 선언할 때
선언해 놓고 함수에서 안 쓸 때가 있어요
그러면은 이제
컴파일러 워닝(compiler warning)을 켜놓으면
사용하지 않는 변수야라고 워닝(warning)을 주거든요
근데 당연히 이런 변수는 지워야 되는데
디버그(Debug)나 릴리즈(Release)나
디버그(Debug)냐 릴리스(Release)냐
이 둘 중에 어떤 걸 가는 거에 따라
어서트(assert)를 쓰고 안 쓰는 경우가 있잖아요
그래서 어서트(assert)에 박아 놓은 변수는
디버그(Debug)에서는 사용되지만
릴리스(Release)에는 사라지기 때문에
그게 워닝(warning)이 돼요 릴리스(Release)에서
그래서 그런 경우에 그 변수를
maybe_unused로 선언을 해 주면은
컴파일러 워닝(compiler
warning)이 사라진다는 거죠
그래서
제가 옛날부터 했던 얘기 있잖아요
컴파일러 워닝(compiler warning)
하나 만들 때마다 세 대씩 맞는다고
아직도 그 마음은 변하지 않았어요
그래서
이제 이런..
근데 이제 언제나 헷갈리는 건
어서트(assert) 같은 거 쓸 때
이제 안 쓰는 변수를 어떻게 할까
이 고민이었죠
그래서 이제는
옛날에는 매크로(macro)로 만들어서
해결하는 법이 있었지만
이제는 이거를
할 수 있다는 거죠
왜냐하면은 이제
maybe_unused만 선언해 주면
문제가 없으니까
그래서 이거는
유용하게 쓸 수 있을 것 같은데
단지 이거를 디버그(Debug)버전에서도 막
워닝(warning)이 나는데
그걸 없애기 위해 쓴다고 그러면
그거는
맞아야죠
왜냐하면은
워닝(warning)이 나서 안 보고
넘어가는 건 세 대 맞지만
워닝(warning)이 나는 걸,
어 워닝(warning) 나는 거 알고 문제도 알어
근데 아이 대충 고쳐야지 그러고
그거를
꼽아서 고친다는 것 자체가
내가 알고도 더 나쁜 짓을 한 거잖아요
그거는 다섯 대씩 맞아야 될 것 같아요
그래서
그게 있고
제가 원래 다섯 개를 말하려고 했는데
하나는 얘기 안 하는 게 좋을 것 같아요
굳이 말할 이유가 없을 것 같고
마지막 거
이제 제가
이거 절대 쓰면 안 될 것 같다고 얘기한 거
이게 재밌는 게 뭐냐면
노리턴(noreturn)이라는 Attribute가 있어요
이게 뭐냐면
뭐 함수를 예로 들게요
이 함수에서
어떤 반환값도 반환하지 않는다
이런 의미의 노리턴(noreturn)이에요
그러니까 뭐 void형 함수 이런 비슷한 개념이죠
근데
지금 하는 얘긴 또 뭐냐면
노리턴(noreturn)인데..
이걸 노리턴(noreturn)으로 달아 놨어요
아 그래 좋아
뭐 이럴 때 리턴(return)하면 뭐
워닝(warning)이 나올 수도 있겠지
뭐 이런 생각을 하잖아요?
근데 스펙에 보면은
노리턴(noreturn)으로 달려 있는 함수가
리턴 값(return value)을 반환을 하면은
어떤 일이 일어나야 되는지
스펙에서 정해 놓고 있지가 않아요
그래서 아까 제가 앞에서 말했던,
메모리(memory)가 겹치지
않는다고 선언을 해 놨는데
메모리(memory)가 겹치는
순간 어떤 일이 발생하냐
이상한
뭐 이렇게
뭐라 그럴까
되게 이상한 에러(error)가
버그(bug)가 발생할 수 있다 그랬잖아요
그런 개념인 것 같아요
리턴(return)이 없다고 명시를 해
놨는데 불구하고 리턴(return)을 해
그리고 그 리턴 값(return value)을
받아 갖고 쓰고 있어 어디선가
그리고 이게 컴파일(compile)이 되긴 되잖아요
컴파일(compile)이 됐는데
실행 도중에 어떤 일이 일어날지는
스펙에서 정해 놓지 않기 때문에
이 컴파일러(compiler)에서는 뻑이 날 수도 있고
저 컴파일러(compiler)에서는 안 날 수도 있고
아니면 어떤 이상한 조건에서는
날 수도 있다는 얘기에요
그러면 이거는 노리턴(noreturn)을
박음으로 해서 얻는 이득보다
그니까 어쩌다 한 번 실수를 하면은
잃는 그,
손해가 더 큰 것 같아요
그래서
이거는 왜 이렇게 해놨을까가 되게 의심이 되고
차라리 컴파일러 에러
(compiler error)로 만들게 하든가
뭐 이상한 짓을 하지 않는 이상은
실수를 오히려 만들 수 있는
그런 여지를 열어 두는 거기 때문에
안 좋은 것 같아요
그래서 제가 처음에 말했듯이,
아까 Attribute를 얘기할 때도 그랬잖아요
프로그래머의 실수를 막을 수
있는 Attribute면은 찬성이다
제가 지금 말 했던 것 네 개 중에서
fall-through라는 게 특히
그 부분에 굉장히 잘 걸맞는 거였고
디프리케이트(deprecated)도 그런 거죠
이제 오래된 함수 점점 없애고 싶은데
쓰지 말라고 이렇게
알려주는 것도 그렇고
maybe_unused도 그냥 뭐,
어서트(assert)에서 계속
워닝(warning) 나오고 이러는 것들
효과적으로 없앨 수 있는 방법이죠
왜냐면 그걸 또 어떻게 바꾸겠다고 막
#ifdef 하고 막 이러면 더 귀찮아지니까
그래서
그런 것 같아요
제가 오늘 말했던 Attribute가 네 개 거든요
지금 말했죠?
그 네 개 중에 세 개는 이제
쓰시면 될 것 같아요
이제 컴파일러(compiler)가 지원한다는 가정 하에
아직 지원을 안 한다면 더 기다려야겠죠
아 그리고
뭐
비주얼 스튜디오(Visual Studio) 같은
경우에는 지원을 안 함에도 불구하고
그거를 이제
지원하라고 켜는 법도 있는 것 같더라고요
그래서 그렇게 해야 되고
그리고
제일 마지막에 말씀드린 노리턴(noreturn)은
'어 이걸 왜 써야 되지?'라는
생각이 정말 많이 들어요
undefined behavior가 정말 참..
맘에 걸려요
그 undefined라는 말을 도대체
어떻게 받아들여야 될지
현재 컴파일러(compiler)가
어떻게 만들고 있을지 그런 것들
그래서
오늘은 오랜만에 C++ 얘기를 했고
C++ 17에서 그리고 11에서 나온 그런
Attribute들을 쓰면은 좀 더
실수를 막을 수 있다
이제 저도..
제가 전에 공개해 놓은
C++ 코딩 스탠다드가 있거든요
거기 가서 이제
비주얼 스튜디오(Visual Studio)가
제대로 지원한다면 이제 고쳐야죠
"아 이제 fall-through를 커멘트
(comment)가 아니라 이걸로 달아라"
이런 식으로
그렇네요
예 그 정도면 될 것 같아요
예 포프였습니다