C言語なら俺に聞け 143
■ このスレッドは過去ログ倉庫に格納されています
変数の位置（アドレス）を示す変数 = ポインタ
そいつ自体も変数だからアドレスを持ってるしポインタも持てる 記録位置の入った素子の位置が入った記録素子。
これなら有りえるとすぐわかる。 物理的な描像にするな。
論理的な本質部分を説明しろ。 >>265
メモリー上の位置でいいんじゃね？
これがイメージできなきゃ無理 >>262
ある
３重でも４重でもいくらでも
一般的に使うのは２重までだが ○重ポインタという言葉はあまりオススメしない
いくら重ねようが「〜へのポインタ」だ
int a = 123;
int *pa = &a; /* 「int型」へのポインタpa */
int **ppa = &pa; /* 「int型へのポインタ」へのポインタppa */
int ***pppa = &ppa; /* 「int型へのポインタへのポインタ」へのポインタpppa */
参照のイメージ([アドレス][値])
[a][123]
[pa][&a] -> [a][123]
[ppa][&pa] -> [pa][&a] -> [a][123]
[pppa][&ppa] -> [ppa][&pa] -> [pa][&a] -> [a][123] 確かにポインタは2重以上はなるべく使いたくないな。混乱するし。 そうだなポインタを文字列の格納だけに使うならアドレスは関係ない
int型で変数を操作するとかなら話は別だけどな 二重以上には二重も入るのだが、本当にそれでいいのか？ 二重ポインタって言い方が紛らわしい
「ポインタが二重」って意味が通じない。
もともとは * が２つ付いてることを二重って言ってるんだろうけど ポインタは型ではないので、二重のポインタという言い方はあり得るのではないか。 ポインタの配列 配列のポインタ ポインタのポインタ >>279
「なるべく使いたくない」だからいいんじゃね int型へのポインタに対するchar型へのポインタとかあるのなら紛らわしいという主張も理解できるが。
そんなものは無いので。
***を三重のポインタというのは合理的に見える。
どうだい。 int型へのポインタ型へのポインタ
char型へのポインタ型へのポインタ >>284
１５年前大学で４重ポインタの地獄を目にした >>288
研究課題で先輩が作ったライブラリのプログラム
それを使って成果を出すのが自分の卒論… ３次元配列を生成して引数に書き戻すような構造なのか
４次元配列を生成して戻すようなのか
各次元で大きさが固定なら 1次元配列にして 添え字演算で4次元にしちゃうな リスト構造とかツリー構造とか、繋げたり外したりすんのに使うよな？ x,y,z座標表すのにint***を使ったことがある 2重以上になりそうなときは構造体にまとめちゃうからなぁ。 >>294
多分、階層の方がわかりやすいだろうね
int ***p; というポインタ変数ｐで p[x][y][z] とすると、
*(*(*(p + x) + y) + z)
を参照する。このあたりを分かりやすく言えるといいんだけど 同一ファイル内の関数を単体で自動化テスト出来る何かスマートな方法はないものか
他のテスト周りで小回りが効く言語と比べると単体テストがお辛い >>298
惜しい。C++だったら、コンストラクタでオートメーションできるのに。 >>295
三次元扱うと***pくらい何て事無いよね 構造体のメンバーの構造体のメンバーの構造体のメンバーのつもりで
ポインタのポインタのポインタとかいい気になって使ってたら、
エクセプションの嵐でワラタw 正しい指し先を格納してるかはコードの書いた奴の責任だからね
言語で保障してくれない 有名な言葉思い出した。
プログラムは意図した通りには動かない、
書いた通りに動く。 ハードがまともに動いている前提でな。
タイマーLSIにall0ぶち込むなんてのはどこのマニュアルにも
書いてないバッドノウハウだろうに >>298
google testとかcpp testとか使えば？ 三次元配列を扱うのに三重ポインタが出てくると思っている池沼がいるな まあ、Cは次元とかオフセット計算が掛け算になるだけだからな。
何次元にしようとリニアな配列のままさ。 俺はポインタを諦めて、構造体配列のインデックスでリンクするリスト構造を作ったわ。 誰かが書いてあって気になったんだけど
double a;
scanf("%if", &a);
ってf単体じゃないの？ long double は別物として実装していない？ scanfでは、floatが%fで、doubleが%lfだ。printfでは区別がない。 cでUTF-8のファイル読み書きとデータの取り扱い方が分からないです
もしかしてできないのかな？ 調べるとすぐにwikipediaが出てきたよ
https://ja.wikibooks.org/wiki/C%E8%A8%80%E8%AA%9E/%E6%96%87%E5%AD%97%E3%81%A8%E6%96%87%E5%AD%97%E5%88%97#Unicode.E6.96.87.E5.AD.97.E3.82.BB.E3.83.83.E3.83.88
文字を「L"」で囲むとその文字を表現するワイド文字型の数値となる
Unicode文字セットでは、標準ライブラリの関数を使う前にロケール（地域）を設定する必要があり、また、Unicode用の関数を使う必要もある
// wchar_t型
wchar_t wc = L'a'; // wchar_t型の変数wcに文字L'a'を格納
_wsetlocale(LC_ALL, L""); // ロケール（地域）を設定する
wprintf(L"変数wcに格納された文字は%c", wc); //wcを文字として表示
wprintf(L"変数wcに格納された数値は%4x", wc); //wcを数値として表示 だから、文字セットはライブラリの範疇だからC言語スレで聞くなよ。
おまえが使ってるコンパイラのスレにでも行け。 何したいかによるんじゃね
素でもそれなりには扱えるし、不十分ならライブラリ探してもいい
どうしても無理なら慣れた文字コードに変換すればいいけど、こっちは一部文字情報が欠落するかもね エンコーディングにかかわらず、ただのバイト列だからchar*でいい 次のC規格でそろそろ文字を扱う関数全てunsigned charに変更してくれないかな
utf8でもsjisでもだけど1バイト目の判定でいちいちキャストするのが不毛すぎる
賢明なプログラマならcharなどというプリミティブ型をそのままの名前で使わずちゃんと
typedef char str_t;
とかしてるはずだし、してない愚者はもうシステムもろとも切り捨てていいだろう
-1が欲しいために結局intに拡張されるんだからcharの時点では符号は不要なんだよ C#みたいにbyte型作れば？
それかマルチバイト型 >utf8でもsjisでもだけど1バイト目の判定でいちいちキャストするのが不毛すぎる
いまどきそういうencoding依存のコードをそんなに頻繁に書いているんだとしたら
それ自体が不毛な気も。 文句たれてる暇があるなら1バイト目判定関数でもつくれば ファイルサイズ測定
↓
そのファイルサイズ領域を動的確保
↓
そこにutf-8の文字列を順次格納
みたいなプログラム組んでるんだけど
ファイルサイズ/sizeof(wchar_t)と中身の文字の数って等しくないの？ UTF-8をそのまま扱うんなら、/sizeof(char)じゃね？
UTF-16やUTF-32に変換したならデータサイズが違うけど。 UTF-8 は データサイズから文字数を求めることはできない やっぱり１文字づつ読み込んでって文字数カウントするしかないか >>333
記憶するのに必要なメモリの量は読み込んだバイト数でいいけど
「１文字に要するバイト数が可変」なので
「文字数」をカウントするとなるとそうせざるを得ないね 暇つぶしで気になったんだけどC言語でもOSは作れるだよな、でも制御とかでコンピューターをちゃんと理解してないとやっぱ作れない？ FreeDOS、Linux、ReactOSなどのオープンソースなOSは、ソースが見られるから参考にするといい。
例えば、OSで並列処理をしたい場合は実際のCPUの知識が必要になるし、OSをCD-ROMからインストールしたい場合は、CD-ROMのファイルシステムの知識が必要になる。
OSを便利にしたいなら、それなりの知識が必要になるのさ。 モダンなOSは巨大化・複雑化しているから、一人ですべてを把握するのは難しい。
必要な機能を分割統治して、ライブラリなどによってブラックボックスとして実装するのが一般的。 >>336
OS自作入門とかいうそのものズバリな本があるよ
勉強目的なら割りとオススメ モダンでなくても、C単体ではシステムコールとCPUステータスに
関わる部分が書けないので、100%は不可能。
asm文とか使うなら別だけど。 なお、OSで商売したいなら、著作権のトラブルをクリアしないといけない。
マイクロソフトやグーグルのようにOSを売るのは至難の技だ。 パソコン向けじゃなければ、日本企業でもOSを開発しているところはある。
どんなOSを開発したい？ あとメモリ上に読み込んだバイナリデータをwchar_tの文字列に変換することは可能でしょうか？ ただC言語の本にアセンブリ言語またC言語でもOS作成可能ってあったから気になっただけ
他の言語もコンパイルして機械語にするからC言語も間接的な言語しかないのかなって疑問に思っただけ 嘘ついてるかもだけど、wchar_tのたぐいって、使うとはまる奴じゃなかった？
文字列はcharオンリーな今日この頃。
cpu限定すれば、変換はいけるんじゃない？ ワイド文字だと場合によってはエンディアンを気にする必要があるのと
結局>>334は避けられないあたりを忘れなければハマることはないかと OSのコードを書くのってC言語のインラインアセンブリが使われてるんじゃないの？ インラインなんかほとんど使わない
アセンブラが必要なところはガチのアセンブラを使う
量にして全体の数%ってとこ >>339
あれかなり良いけどフロッピー使うし作るOSもかなり独特だからモダンな感じでもう一冊くらい書いて欲しい >>330
UTF-8 とは何か？
そして wchar_t 型とはなにか？
まずはこの2つについて徹底的に調べると君の頭は少し良くなると思う。 >>336
OS作れるどころかOSを書くために作られたような言語がCだよ。UNIXな。 mallocとかcallocでNULLが帰ってくる原因が分からない
メモリも十分あいてるしfree忘れもないのに おれの昔使ってたシステムでは、free忘れじゃなくて、mallocしたアドレスを2度freeしたり、もしくはmallocとは全然関係無いアドレスをfreeすると、
その後のmallocでおかしな動作をすることがあった >>362
おそらく、そういう系だろうな
どこかで未定義の動作をやらかしてる ■ このスレッドは過去ログ倉庫に格納されています
