回答編集履歴
4
C++20
test
CHANGED
|
@@ -108,6 +108,14 @@
|
|
|
108
108
|
|
|
109
109
|
|
|
110
110
|
|
|
111
|
+
さて、C++20に向けて再び`char8_t`型が[提案されています](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r1.html)。
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
**もし`char8_t`型が標準入りしたならば、もはや`char`は使うべきではないと言えるでしょう。**
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
111
119
|
---
|
|
112
120
|
|
|
113
121
|
|
3
m
test
CHANGED
|
@@ -58,26 +58,26 @@
|
|
|
58
58
|
|
|
59
59
|
|
|
60
60
|
|
|
61
|
+
|文字列リテラル|型|格納される物|
|
|
62
|
+
|
|
63
|
+
|--|--|--|
|
|
64
|
+
|
|
65
|
+
|`u8""`|`const char[]`|UTF-8|
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
が追加されています。
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
またC++17では
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
61
77
|
|文字リテラル|型|格納される物|
|
|
62
78
|
|
|
63
79
|
|--|--|--|
|
|
64
80
|
|
|
65
|
-
|`u8""`|`const char[]`|UTF-8|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
が追加されています。
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
またC++17では
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|文字リテラル|型|格納される物|
|
|
78
|
-
|
|
79
|
-
|--|--|--|
|
|
80
|
-
|
|
81
81
|
|`u8''`|`char`|UTF-8|
|
|
82
82
|
|
|
83
83
|
|
2
m
test
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
とは **整数を格納する型として** と捉えるべきです。
|
|
13
|
+
とは **整数を格納する型として** と捉えるべきです。文字列、ただし一単位が1byteな文字エンコードを格納する型としては、これまで通り`char`型を用いるべきです。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
@@ -146,13 +146,13 @@
|
|
|
146
146
|
|
|
147
147
|
と書かれているじゃないですか。プログラマーは怠惰であるべきなので、STLを使うほうが楽できます。STLの関数群/クラス群の使い方を調べるには
|
|
148
148
|
|
|
149
|
-
[https://cpprefjp.github.io/(https://cpprefjp.github.io/)
|
|
149
|
+
[https://cpprefjp.github.io/](https://cpprefjp.github.io/)
|
|
150
150
|
|
|
151
151
|
が便利です(宣伝)
|
|
152
152
|
|
|
153
153
|
|
|
154
154
|
|
|
155
|
-
ただしiostream系はC++の`std::cout`のようなスタイルやCの`printf`のようなスタイルともに
|
|
155
|
+
ただしiostream系はC++の`std::cout`のようなスタイルやCの`printf`のようなスタイルともに明らかな問題が存在し、[fmtlib/fmt](https://github.com/fmtlib/fmt)とかを使うべきだということができます。またlocaleはだいたいC/C++問わずぶっ壊れていて使い物になりません
|
|
156
156
|
|
|
157
157
|
|
|
158
158
|
|
1
C APIと文字列
test
CHANGED
|
@@ -175,3 +175,59 @@
|
|
|
175
175
|
|
|
176
176
|
|
|
177
177
|
C/C++にはUnicodeどうしの文字コード変換を行う方法が存在しないという状態が生じています(C++11で入ったが致命的な欠陥が見つかってC++17でdeprecated)
|
|
178
|
+
|
|
179
|
+
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
|
|
184
|
+
|
|
185
|
+
C APIで文字列を受け取る場合のAPI設計について留意するべきことがあります。
|
|
186
|
+
|
|
187
|
+
|
|
188
|
+
|
|
189
|
+
Cだけやっていると
|
|
190
|
+
|
|
191
|
+
|
|
192
|
+
|
|
193
|
+
```c
|
|
194
|
+
|
|
195
|
+
void foo(char* str);
|
|
196
|
+
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
|
|
200
|
+
|
|
201
|
+
のようなAPIを作りがちですが、2つの点からこれをするべきではありません。
|
|
202
|
+
|
|
203
|
+
|
|
204
|
+
|
|
205
|
+
1. 文字列の長さがNULL終端文字に依存している
|
|
206
|
+
|
|
207
|
+
Cでは文字列とはNULL終端するbyte列のことでしたが、これはプログラミングをする上で余計なメモリ確保を強いる事があり、非効率的です。
|
|
208
|
+
|
|
209
|
+
C++ですらC++17で`string_view`なるものが追加され、文字列の先頭へのポインタと長さの構造体のようなクラスを`std::string`と同じインターフェースで扱えるようになったことでNULL終端しない文字列を扱う機会が増えます。
|
|
210
|
+
|
|
211
|
+
|
|
212
|
+
|
|
213
|
+
2. const修飾されていない
|
|
214
|
+
|
|
215
|
+
const修飾されていないとC++ではこのAPIに文字列リテラルを渡すことができません。
|
|
216
|
+
|
|
217
|
+
また文字列が書き換えられる可能性があるため安全のために一度動的メモリ確保を行いコピーするコストが発生し、著しく実行速度に影響を与えます。
|
|
218
|
+
|
|
219
|
+
|
|
220
|
+
|
|
221
|
+
したがって
|
|
222
|
+
|
|
223
|
+
|
|
224
|
+
|
|
225
|
+
```c
|
|
226
|
+
|
|
227
|
+
void foo(const char* str, size_t len);
|
|
228
|
+
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
|
|
232
|
+
|
|
233
|
+
のようにしましょう。
|