「C言語/記法」の版間の差分
削除された内容 追加された内容
M →定数: Fix タグ: 2017年版ソースエディター |
u及びUを前置した文字定数を追加。 タグ: 2017年版ソースエディター |
||
18 行
基本実行文字セット( ''basic execution character set'' )には、すべてのビットを0にしたバイト（ヌル文字）が存在し、文字列の終了に使用されます。
基本ソース文字セットと基本実行文字セットは、ともに次のものを有するものとします
メンバー：
;ラテンアルファベットの大文字26文字
<pre>
41 ⟶ 42行目:
;空白文字と、水平タブ、垂直タブ、フォームフィードを表す制御文字
ソース基本文字セット及び実行基本文字セットの各メンバの表現は、1バイトに収まるものとします
ソースファイルでは、テキストの各行の終わりを示す何らかの方法がなければならない。本国際規格では、そのような行末表示を1つの改行文字のように扱う。基本実行文字セットには、アラート、バックスペース、キャリッジリターン、改行を表す制御文字がなければならない。
52 ⟶ 53行目:
この国際規格では、この用語には他のアルファベットの文字である他の文字は含まれません。
国際文字名( ''universal character name'' )は、他のキャラクタに名前を付ける方法を提供します
前方参照：国際文字名（§6.4.3）、文字定数（§6.4.4.4）、前処理ディレクティブ（§6.10）、文字列リテラル（§6.4.5）、コメント（§6.4.9）、文字列（§7.1.1）。
</blockquote>
81 ⟶ 82行目:
3文字表記に一致する文字列を表記したい場合、「?」の代わりに逆斜線表記（エスケープシーケンス）の「\?」を用いるとよい。
現在、3文字表記はほとんど使われず、
この部分は、ISO/IEC 9899：1999（C99；JIS X 3010：2003の翻訳元）とISO/IEC 9899:2011(C11)で異なる部分で、JIS X 3010：2003『プログラム言語 C』では、
119 ⟶ 120行目:
== 字句 ==
JISCでは、<q>字句（token）は，翻訳フェーズ（7）及び（8）において言語の最小の字句的な単位とする。</q>となっていますが定義が循環していて意味不明です<ref>『JISX3010:2003』p.35「6.4 字句要素」</ref>。
原文では、<q>A token is the minimal lexical element of the language in translation phases 7 and 8.</q>とあり、「トークンとは、[[C言語/概念モデル#翻訳フェーズ7|翻訳フェーズ（7）]]および[[C言語/概念モデル#翻訳フェーズ8|（8）]]において、言語の最小の語彙要素のことです。」と訳すことが出来ます。
字句の種類は、キーワード、識別子、定数、文字列リテラルおよび区切り子です。
=== キーワード ===
キーワードとは特定の機能のために予約された字句であり、その他の機能のためには使用できない。キーワードとは次のいずれかです{{:C言語/Keywords}}
=== 識別子 ===
識別子とは、1つ又はそれ以上の実体を指し示すもので、<ref name="識別子">『JISX3010:2003』p.37「6.4.2 識別子」</ref>
オブジェクト、関数、構造体・共用体・列挙体のタグまたはメンバ、型定義名、ラベル名、マクロ名、マクロ仮引数のいずれか一つを表します<ref>『JISX3010:2003』p.21「6.2.1 識別子の有効範囲」</ref>。
識別子は、半角英数、「_(下線)」からなる文字列である。
ただし、先頭は非数字でなければな
識別子に多バイト文字を使用できるかは
==== __func__ ====
識別子 __func__ は、翻訳者(''translator'')によって以下のように暗黙的に宣言されなければな
各関数定義の開始波括弧の直後に、次のような宣言があるように振る舞います<ref name="jtc1-sc22-wg14-n1256-7.26.1">{{cite book
| url = http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
155 ⟶ 154行目:
int main(void)
{
printf("%s\n", __func__);//「main(改行)」と表示します
}
</syntaxhighlight>
202 ⟶ 201行目:
変数の値がプログラム実行中に変更される場合もあるのに対して、定数の値はプログラム実行中を通して一定です。
定数には整数定数、浮動小数点定数、列挙定数、文字定数があ
; 整数定数
: 整数を記述するための定数
225 ⟶ 224行目:
!定数の種類!!進数!!正規表現!!例
|-
|rowspan="4"|整数定数||2進数<ref>2進数整数定数はC23で追加予定で規格としては未成ですが、clang/gcc/MSVCなど多くの
| url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
| title= N2596 working draft — December 11, 2020 ISO/IEC 9899:202x (E)
253 ⟶ 252行目:
|-
|rowspan=2|文字定数|
|rowspan=
|/'.'/[[C言語/文字と文字列#バックスラッシュのエスケープについて|エスケープシーケンス]]可能（単純文字定数）|| 'a'
|-
|/L'.'/[[C言語/文字と文字列#バックスラッシュのエスケープについて|エスケープシーケンス]]可能（ワイド文字定数）
|-
|/u'.'/[[C言語/文字と文字列#バックスラッシュのエスケープについて|エスケープシーケンス]]可能（char16_t ）<sup>C11</sup>
| u'a'
|-
|/U'.'/[[C言語/文字と文字列#バックスラッシュのエスケープについて|エスケープシーケンス]]可能（char32_t ）<sup>C11</sup>
| U'a'
<!--
|/u8'.'/[[C言語/文字と文字列#バックスラッシュのエスケープについて|エスケープシーケンス]]可能（UTF-8）<sup>C++</sup>
| u8'a'
-->
|}
文字定数に前置する L, U, u については、規格の版ごとに定義がまちまちで、C23では（文字列リテラルと同じ様に）''encoding-prefix'' とされそうですが、2021年8月時点の最新の C17 では文字定数と文字列リテラルでは(文字定数だけu8が使えないなど)不統一です。<!--この辺は、プラットホーム/言語処理系決め打ちでないと現状参考になる情報を載せるのは困難な印象 -->
*整数定数の接尾辞( ''integer-suffix'' )
283 ⟶ 293行目:
</syntaxhighlight>
=== 文字列リテラル ===
文字列リテラル（ ''String literals'' ）<ref>『JISX3010:2003』p.45「6.4.5 文字列リテラル」</ref>には、単純文字列リテラルとワイド文字列リテラルがあ
; 単純文字列リテラル（character string literal）
: 1バイト文字または多バイト文字の文字列を記述するための定数である。
293 ⟶ 303行目:
{|class="wikitable"
|+ 文字列リテラルの種類と記法
!定数の種類!!進数!!記法!!例
|-
300 ⟶ 310行目:
|}
;文字型配列変数に文字列リテラルの内容をコピーします。:<syntaxhighlight lang=c>
#include <string.h>
int main(void) {
▲ char str[32];
▲ strcpy(str,"Hello, World!");//strに文字列リテラルHello, World!をコピーする。
}
</syntaxhighlight>
339 ⟶ 347行目:
<ref name="区切り子">『JISX3010:2003』p.46「6.4.6 区切り子」</ref>
次の6つの2文字の字句は、2文字表記( ''digraphs'' )と呼ばれる。
<pre>
<: :> <% %> %: %:%:
350 ⟶ 358行目:
=== ヘッダ名 ===
;形式
:<pre>
<文字列>
"文字列"
</pre>
ヘッダ名とは、#include前処理指令で読み込まれるファイル名を指します。
ヘッダ名には「'、\、"、//、/*」に表れた時、その動作は未定義です<ref>以前の編集で、<ins>ヘッダ名には「'、\、"、//、/*」は指定できない。</ins>としていましたが、例えば // はネットワークルートとしてPATH に現れる事があるので指定できる（出来ないと困る）環境があります。</ref>。
<ref>『JISX3010:2003』p.46「6.4.7 ヘッダ名」</ref>
362 ⟶ 370行目:
=== 前処理数 ===
前処理数（Preprocessing numbers; '''''Syntax'''''では ''pp-number''<ref>JIS Cでは、用語を構文規約中のシンボルに同じ語を使っているので、C99の原文を当たらないと構文について読み誤る恐れがあ
以下『JISX3010:2003』からの引用<ref>『JISX3010:2003』p.47「6.4.8 前処理数」</ref>。
387 ⟶ 396行目:
</blockquote>
上記のように前処理数の解析は、後にくる厳格な構文解析を行うわけではなくもっぱら字句解析による。
: <syntaxhighlight lang=c>
int i = 0xfe+0x2;
</syntaxhighlight>
の様なコードで前処理数が問題になります。一見すると <code>0xfe</code> に <code>0x2</code> を足す様に見えますが、 <code>0xfe+0x2</code> が前処理数の定義に合致してしまうので、［[[C言語/概念モデル#翻訳フェーズ7|翻訳フェーズ（7）]]に数（らしきもの）として渡されてしましますが、16進浮動小数点定数の構文には合致しないので
Main.c:4:17: error: invalid suffix '+0x2' on integer constant
int i = 0xfe+0x2;
^
の様なエラーになります。
この場合は、
: <syntaxhighlight lang=c>
int i = 0xfe + 0x2;
</syntaxhighlight>
とスペースを補うことで回避できます。
=== 注釈 ===
401 ⟶ 423行目:
</syntaxhighlight>
== 文 ==
| |||