C言語なら俺に聞け 144
■ このスレッドは過去ログ倉庫に格納されています
>>147
stat()とfstat()なんかどうだ？
まあでもopen(), fopen()の関係とは違うけどな。
open()はシステムコールだがfopen()はライブラリ関数だ。
(UNIX系OSの話ではあるが)。 俺の希望は、たいしたやりたくもないけど、
ちょっとやってみたら？とか丁寧に教えるからやってみなよ！
とかさ、そういう感じで優しく接してもらってだな、で、出来も悪いからなかなか覚えないけどそれでも教える側が知恵を絞ってどうにかうまく理解させる方法はないだろうかと創意工夫して育てる環境というのかな。とにかく頼むよまじ >>148
stdio.hにaccess()の偉いやつあるのかなー と思ったのだよ
無いならまあいいけど >>149
授業料ももらってないのに優しく教える理由なんかないわな
5chなんて煽り合いと罵り合いの場だよ >>149
日本語でおｋ
そして死ね
> 出来も悪いからなかなか覚えないけど
なら覚えるまで何度でも読み返せ
> 教える側が知恵を絞ってどうにかうまく理解させる方法はないだろうかと創意工夫して
教わる側が1mmも努力せず、教える側に全責任をなすりつけるのは典型的ゆとり。死ね。
というかな、はっきり言えば昔より格段に環境は良くなっている。
当然教える側のノウハウも蓄積されてるし、
本も大量に出版され、良書以外は淘汰されてるし、
Webにも情報があふれ、ここみたいな掲示板やフォーラムもあるし、
無料でIDEも使えるし。
だから昔の環境で手こずった奴も、今なら楽勝で学んでいける。
問題は、昔だったら(=IDE無しでは）お話にならない馬鹿にもプログラミングさせようとしていることであって、
俺はこれに関してはもう諦めた方がいい＝手取り足取り教えないと出来ない奴は死ねでいい、と思っている。
自分の為に他人に無償の努力を強いるその姿勢が根本的に間違っている。
つかマジで、ゆとりのノリでやりたいなら、C以外のゆとり用言語を使え。Javaとか。新しいのならGoとか。
そしてこれとは別に、俺は2chとは別の掲示板を立ち上げようとしているのだが、
君はこれについて興味あるか？
追える限りでの発言を確認したが、君は煽るだけの無能ではないらしい。
俺は今の2chのシステムでは行けるところまで行っている（既に飽和している）と見ているから、
これ以上の物を求めるのなら何かしら新しい機能が必要だと考えている。
今はそれのアイデア出し中だ。何かあれば是非。 漠然とした質問で失礼します。
私は最近ｃ言語の勉強を始めたところでギリギリポインタ等も理解できたところです。
そこで、アルゴリズムとデータ構造の勉強をしようと思い本を何冊か買ってきたのですが、
スタックなどのデータ構造の仕組みがよくわかりません。。
どの参考書でも、「スタックとは後入れ先出しで…」という説明の後、「それではc言語でスタックを
実装してみましょう」といって意味不明なコード（長い）が書かれているパターンが王道のようです。
このパターンは線形リストとかでも同じです（諸兄にはいうまでもないでしょうが…）。
どのような実益があってこのようなデータ構造を生成する必要があるのでしょうか。
python等でいうところのリストに相当するデータ構造をc言語で作成するためということ?
また、実際のプログラムにおいては、データ構造の定義だけでかなりコード長くなると思われるのですが、
よく利用される手法なのでしょうか。 >>153
std::stack相当の話？
なら大して使わないから、とりあえず読み飛ばしていい。
つか、最初から全部キッチリ理解しようとせず、
まずは分かる範囲で組み、その後、自分の出来る範囲を広げていくようにした方がいい。
(1度読んで全部理解して捨てる、ではなく、最初から5回読む前提で分かるところから読み進める）
そのうち、stackを使うべき用途に遭遇したら、なるほどと理解できるようになる。 >>153
直近のご要望としては、スタックの使い所を知りたいって事かな？
ほとんどの実行環境において、C言語の関数呼び出しなんかの実現に使われてるよ。
呼び出した側の状態を保存する場合にpush、呼び出され側から戻るときにpop的な。 >>153
どのような実益？そうだなあ。スタックといえば以前PerlでXMLの階層構造を
SAX使ってRDBに全て入れる時に使ったなあ。まあ、それだけでなく先入先出に
するとやりやすくなる処理はあるよ。再起処理でも使われるし(スタックに積まれて
いるとあまり意識する必要ないかもしれないが)。
リストは例えば長さが可変長のファイルからデータ取得してメモリ上に置いておく
時に使えるかな。
まあしかしライブラリにあるならそれ使った方が楽だよ。毎回書くのは阿保らしい。 >>156
とりあえずソートアルゴリズムのが理解したいと思い勉強をしていたのですが、複雑なものになってくると
各種データ構造の理解が必須！みたいになってきまして、データ構造の方にも手を出したみたわけです。
ヒープとかの方が簡単そうな気がしますし、とりあえずスタック関連は後回しにします。
>>157
はい、なんかそのようなことも本に書いてあったのです。
しかしこれが、「スタックとはプログラミング言語内においても既に設計されている基本構造なのだ。以上終わり。」
であれば、スッキリするのですが、
「それでは、これをc言語で実装してみましょう」といって、スタックをc言語のプログラムで作り出すことの意義
が今一つわからないというか。 >>150
filenoとfdopen覚えた方が楽だけどね >>159
難しすぎます！
おそらく当分使えるようにはならなさそうです！ >>160
> とりあえずソートアルゴリズムのが理解したいと思い勉強をしていたのですが
アルゴリズムとデータ構造をソートで学ぶのは昔流で、今はそれをこの段階でやる必要はない。
今はとりあえず次の章に行ってしまって、for/while/if等を使いこなせるようになった方がいい。
> 「それでは、これをc言語で実装してみましょう」といって、スタックをc言語のプログラムで作り出すことの意義
仕様を説明する必要がないからだよ。
「じゃんけんゲームを作ってみましょう」なら仕様は大体分かり、説明が省ける。
「オレオレゲームを作ってみましょう」なら、「オレオレゲームとか何か」から詳しく正確に説明しないといけない。
その本は「スタックとは何か」を当然知っているという前提で書かれているんだよ。
Cプログラマがスタック構造を知らないというのもあり得ないからね。
ただ、スタック知らなくてもプログラムなんて組めるし、実際Web系の連中は知らんと思う。
とはいえこれが一方的に悪い訳でもなくて、逆に言えば、
スタック構造を知っていることがプログラミングの本質ではない、ということなんだよ。
だから君みたいな初心者は、分からないところは飛ばして分かるところから読み進めればいいんだよ。
というか、今、君のレベルの初心者がCから始める意味は無いし、
無駄に遠回りになるだけだが、それ分かってやってるか？ >>160
ハノイの塔のパズルを解くプログラムを書いてみて。
スタックを使う場合と使わない場合の2パターン描いてみて。
で、どちらが少ない行数で書けるか、どちらが実行速度が速いか、
どちらが理解しやすい美しいコードか、さまざまな観点で比較してみて。 >>153
と思ったが、Pythonに言及しているところからすると、既にPythonを使いこなせるのか？
だとすると、「アルゴリズムとデータ構造」をガッツリやる意味はある。
スタックが何故使われるかと言えば、スタックで対応できる場合に最速だからだよ。
だからCは実行方式からしてスタックべったりだ。
逆に言えば、それくらいしかメリットないし、
通常の配列にメソッド生やしてスタックにするのも簡単だから、他言語では大体そうしてるでしょ。
以下見れば分かるが、
https://cpprefjp.github.io/reference.html
Pythonのリストに当たる物は
array, deque, forward_list, list, queue, stack, vector の７種類あり、
Cはこれらを使い分けて最速コードを得る為の言語なんだよ。
勿論それ以外の物が良ければ自作しろ、という文化だし。
逆に、Python等は、グダグダ考えずに全部リストでやれ、それの方が分かりやすいし、という文化だろ。 >>165
ほうほう。ありがとうございます。
かなり難しそうですがやってみます。
>>166
スプリクト言語の方が簡単、pythonやrubyでプログラミングというものをはじめましたが、そもそも詳しい人だけが
簡単に思えるだけで、基礎的知識なしでは相当にきついんでないの？と感じてcを始めました。
というわけでpythonが使いこなせるということはありません。
cに関しては教科書一通り一周して、とにかく制御をマスターしたかったので制御文を使いまくるであろうソートアルゴリズムに手を付けたんです。
制御文もアルゴリズムも理解できたら一石二鳥かなと思って。
「定本ｃプログラマのためのアルゴリズム〜」に「リスト」の説明があり、
・要素の挿入 ・要素の削除 ・要素の読み書き ・探索
・複数のリストをまとめる ・リストの分割 ・リストの複製 ・要素の数を求める
とあり、「あら、pythonのリストと全く同じ構造だ」とおどろいたわけです。
ｃはとりあえずarray, deque, forward_list, list, queue, stack, vectorといったものを「なんとかして」pythonのリストやまた
それ以外のデータ構造を自分で作成するということですか。 どうでもいいけどプログラミングなんて10年後オワコンじゃない？
コード共有サイト行けば書きたかったコード見つかるしコピペすればおk
世界で既に誰かが書いてるもの二回三回書く必要性はない
この流れが自動化されれば終わるだろうな >>168
1から1000 までを全部掛けた答えを出す共有サイトのコードを見せてください >>169
なに言ってんだこいつ
調べれば1000000億%出るから自分で調べろよ
まさかgithubも使ったことないのかい？ >>167
> ｃはとりあえずarray, deque, forward_list, list, queue, stack, vectorといったものを「なんとかして」pythonのリストやまた
> それ以外のデータ構造を自分で作成するということですか。
違う。
Pythonのリストというのは抽象データ型で、要するに「万能」に作ってある。
この方がソースコードは分かりやすいから。（知識が少なくても読める）
逆に、「万能」なら限界ぎりぎりの速度を追求できないから、
Cでは別々にして使い分けろ、必要なら自作しろ、ということ。
> スプリクト言語の方が簡単、
これは実際にそう。
pythonやrubyでプログラミングというものをはじめましたが、
これも正しい。
> そもそも詳しい人だけが簡単に思えるだけで、
> 基礎的知識なしでは相当にきついんでないの？と感じてcを始めました。
ここはちょっと違う。
要するに、「動けばいい」プログラムでCを使う意味なんて無いんだよ。
逆に、最速のコードが欲しいときにはC/C++以外に現実的な選択肢はない。
だからほとんどのOS/ブラウザ/処理系(PythonやRubyも）はCで出来ているし、
Cが基礎だっていうのも間違いではないんだが、
プログラミングにCの知識が必要かというと、そうでもないんだよ。
Python/Rubyで済むのなら、Python/Rubyで済ませるべきであってね。
そして初心者はまず、「動けばいい」からスタートすべきであって、
それ以外に色々知識が必要なCはズブの初心者向きではないんだよ。
ただまあ、話を聞く限り、君が「アルゴリズムとデータ構造」をやるのは悪くはない。
とはいえ、現実的にソートのアルゴリズム知ってても大して意味はないし、
直接目標に向かった方がいいと思うが。
例えば、ゲームを作りたいのなら、何でもいいからとりあえず動くゲームを作ってみろ、ということ。
どうせこの最中にいろいろな問題にぶち当たることになるから。 一応付け加えておくと、
Pythonのリストは、C++で言う array, deque, forward_list, list, queue, stack, vector のどの用途にも使える。
でもその分遅いし、メモリも食う。
Pythonを使うというのは、これを認めて、楽さを取る、ということ。
逆に、最高速度で動かしたい、メモリを無駄に食うのは嫌だ、となると、
リストの実際の使われ方を確認して、最も適切なものを選べ、
或いはさらにチューニングできるのなら自作しろ、となるのがC。
だから、組み合わせて作るのではなく、使い分ける。 例えて言った方がいいかな？
Pythonのリストは「車」という解像度しかないのに対し、
Cでは、「軽、軽トラ、普通車、バス、トラック」が指定できるようなもの。
「車」で済むのならPython使っとけ、だし、初心者はこれで問題ない。
細かくチューニングしたいからそれ以上の解像度が必要だ、というときにだけCが必要で、
逆に言えば、その気がないのならPython/Rubyで十分だと思うし、そうするべきだとも思う。
Cは実行速度は最速だが、開発速度は最速ではないので。 なお、人工知能にはPython使う模様
cさん...w Pythonでも速度求めるんならスタック・キューはlistじゃなくてcollections.deque使うやろ >>174
py なのはインタフェースだけでしょ。 >>160
えっ？
データ構造を学んでるんでしょ？
その実装例がでてきたことに対して、実装する意義がわからないっておかしくない？
学習するためじゃないんかい…
車輪の再発明は無駄だけど、学習として車輪の作り方をトレースするのは有益。
とちょっと斜め上の視点をとってみた。 今からお前らが書いてるコードが全て車輪だってことなんだよなぁ... 2chにいる時点で端くれプログラマーなんだし世界で既に書かれたコードしか書いてないでしょ...() >>179
おまえさんは何かコードを書く前に
それを誰が書いたのか調べてクレクレしに行くのか？
すげー嫌われ者だろうな >>180
これは無能確定
何回も同じコードを書くのかい？ 同じ仕様を満たすコードを何人もが独自に書くプロジェクトなんて、沢山あるだろw
誤ったオブジェクト指向の解釈が蔓延した弊害でなw 自分でコード書かないと npm left-pad みたいな問題が起きる
ブラックボックス的に使う部分と内製化する部分はきっちり区別して
内製部分はすべてのコードを完璧に把握しておくべきだ >>185
そりゃコードは把握すべきだよ
けど基本全部他かりゃ引っ張ってくりゃ解決するんだよなプログラムなんざ
プログラマーを神格化する風潮やめようぜ 知恵遅れでポインタすらも分からずギャーギャーわめいてるアホがコイツなんじゃねえの
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10184535725 >>189
確認したが、同意する。
質問/回答一覧できるのに、酷いな。 いやしかし、ひどい質問だなw
プログラムどころかアルゴリズムの時点で特許がどうの騒ぐ時代なのに、プログラムを全世界で共有とか頭悪すぎる。 部分的にはライブラリの配布みたいな感じで出来てはいるけどな。 正直車輪の再開発なんていってたら商売成り立たないよな
ほかの人に見せて第三者がそのコード使ったら普通に嫌だと思うんだけどコードの共有化とか利益と競争を考えてない綺麗事じゃないか？
コード使い回しなんて実際問題、会社内ぐらいでしかやらんだろ むしろ乖離問題で使わせてない。つか使わせたくないってのが本音。
資産だけど公開した途端にむしろ負の資産になる。 GNU汚染問題もあるし出所の怪しいコードをやたらとホイホイ取り込めないよな ライセンス絡みは面倒だから出来るだけ自分で書くのが一番いい 何も見ないで独自に作ってもある日サブマリン特許にやられたりする あれひでえよな
産みの苦しみを報うはずの制度が
産みの苦しみを突然否定しに来る
たった1人を報うために大勢が犠牲になる ソフト特許権絡みの問題なんて余程優れたアルゴリズムを実現でもしない限り発生しないだろ
少なくとも車輪の再発明レベルでは問題が起きようがない
ライセンス関係の問題の殆どは著作権絡みであって特許権の問題ではない 卑怯なことは一切せずに作ったオリジナルなものを
突然パクり呼ばわりされるんだぜ？
開発者としてこれ以上の侮辱があるかよ
いつそうなるかの予測もほぼ不可能だし
それで金よこせってまるで強盗かヤクザの集金だろうが >>202
そこまで言うなら自分で先に特許出願でも何でもして防衛しろよ
仮にパクリ呼ばわりされても先願が認められれば拒絶の申し立ても出来るだろ 自分で発明したものを後から特許とられて…って話でなければ
先に出願しとけってのは無茶、というか超時空理論だわな。
「サブマリン特許で攻められるのが嫌なら
何か作る前に全ての特許を調べておけ」という主張には、
「皆がそんな調査をする必要がある社会では何も生み出せないだろう」
という意見を出したいね。 いやいや製品開発では商品企画段階で先行技術調査はやってて当たり前のことだぞ
後で他社から特許侵害の訴えを受けると面倒くさいことになる
というか大手メーカの組み込みソフト技術者は、技術レポート作成や特許出願の年間ノルマが課せられることも多い
例え特許として特許庁に認められなくても出願したという実績さえあれば先行技術として認められる
サブマリン特許といえども既に世の中に公知されている先行技術のあるものに対して実施料を請求することは出来ない
米国はサブマリン特許に見られるように特許を攻撃戦略をとすることが多いが、日本企業の場合は防衛が特許戦略の中心とする傾向が強い 話が脱線気味だけど、特にソフトウェアに限って言えば余程のことがない限りコードの中身そのものが問題になることは少ない
ただし製品の制御方法についてはソフトが問題になることはある
例えば、炊飯器のご飯の炊き方や洗濯機の攪拌方法やエアコンの運転方法など、これらは特許(パテント)の出来損ないのペテントで
そのノウハウはがっちり固められてるし、下手すりゃ権利の侵害問題に発展することもある
ただし繰り返しになるけど、純粋なコードの権利については特許というよりは著作権の方が問題になることが多い そういえばMSもLinuxが特許侵害してるって言ってandroid使ってるスマホメーカーから金受け取ってんだよな。
技術的にはたいしたものではないらしいが。 プログラミングあんま知らんけどコードって著作権あるの？
俺普通に本とかの模写しまくってるんだけど...
もちろん勉学目的で商用してるわけじゃないけど大丈夫だよな...？ 特許に必要なのは、新規性と独創性と再現性
技術的に高度でも既に知られているものは特許にはならない
技術的にたいしたものでなくても今まで誰も考えつかなかったものは特許になる
ソフトウェアでも既に知られているアルゴリズムでは特許にならない
全く新しい理論に基づくアルゴリズムを実現すれば特許になる >>210
個人利用の範囲で商用利用しなければ問題ない >>204
そこまで言うならって
俺は何か間違ったことや行き過ぎたことを言っているか？ サブマリン特許は公開されてないから、「サブマリン」なんだが
それを誰が調べるの？ >>217
それ昔の話
今は出願から一定期間経過したら公開されるし特許の権利期間も出願からの期間となってるからサブマリン特許はほとんどないよ >>219
これはプログラミングの話じゃなくてお前の日本語読解能力の問題。
13-3 の問題文にモロにヒントが書かれてる。 既にある連結リストにはqsortは使えない（これは常人でも考えれば分かる）
後からどうしてもソートしたいならマージソートを使う（これは常人がすぐに思い付くモンじゃないので知らないと出来ない、つまりは考えても無駄） >>210,212
著作権は商用かどうかは無関係。
個人で楽しむなどの目的で例外的に複製が認められるだけ。
もちろん勉強用なら複製は構わない。
それ以上の利用は本に明示してあることもある。 >>221
「だよねぇ」じゃなくて「13-3の3行目ですかねぇ」だろ。 ここで言っているコピーって、書籍に掲載されているロジックをそのまま借用するって事だよね >>219
「以下のプログラムの (1) (2) の部分を作成し」の「(1) (2) の部分」が見つからない >>226
ヒント：exit(1) の「(1)」のところかな？
言いたいことは分かるけど、まぁ…ね。 >>219
というか、これ学校の宿題レポートで先生が作った問題じゃないの?
こんな場でまるまる公開して教えてくれ、って大丈夫なのか。 >>219見てちょっと考えてみたけど、
初回だけ(topが未設定の場合だけ)場合分けで例外的な処理がいるの？
あと、大小で判定して挿入するとき、先頭もしくは末尾だけは例外的な処理がいるの？
かっこよくスマートに書けるやりかた教えて！ 連結リストで検索すればお手本は大量に出てくる
この改まった場で今更説明するほどのものでもない >>234
なんも見ずに書いてみたけど（コンパイルもしてないけど）
片方向リストにしたらこんな感じかなあ
見た感じスマートじゃないからたぶん無駄なことしてるんだろうけど
// 打席数、安打数は省略
typedef struct PLAYER_tag PLAYER;
struct PLAYER_tag {
char name[20];
PLAYER *next;
};
int main() {
PLAYER *top; // 先頭の要素
PLAYER *p; // 追加する要素
PLAYER *q; // 現在の要素
PLAYER *z; // 一つ前の要素
(省略)
top = NULL;
while (EOFでない) {
// 1行読み込んで名前(name)、打席数、安打数を取得
(省略)
malloc(p, sizeof(struct PLAYER));
memset(p, 0, sizeof(struct PLAYER));
strcpy(p->name, name);
// topが未設定の場合だけは例外的な処理
if(top == NULL) {
// 先頭に挿入
top = p;
} else {
q = top;
z = NULL;
// リストの先頭から順に走査
while (q != NULL) {
// アルファベット順が大きい要素の直前に挿入
if (strcmp(p->name, q->name) < 0) {
if (z != NULL) z->next = p;
p->next = q;
break;
}
z = q;
q = q->next;
}
// 末尾に挿入するときだけは例外処理
if ((p->next == NULL) && (z != NULL)) z->next = p;
(省略) >>235
先頭に挿入した場合の例外的な処理も必要だった
if (z != NULL) z->next = p;
↓
if (z != NULL) {
z->next = p;
} else {
top = p;
} >>235
>struct PLAYER
PLAYER
の誤りだった とりあえず、実際にはリストとデータは分けた方がいいよね。
あと、リストのtopも実体にしたほうが、いい予感。 割とマジでvolatileって何に使うんだ。。。？ >>239
volatile は揮発性のものってことで、読んだ次の瞬間に値が変わっている可能性がある変数に付けとくやつだ。
その変数は実際にはハードウェアによって変化するものに結びついているかも知れないし、他のプロセスや
スレッドによって書き換えられるものかも知れない。とにかくそのプログラムのメインの流れとは無関係に
変化する可能性があるということ。だから読む場合は必ずその変数の内容が読まれるようにコンパイルされる
必要がある。最適化してさっきから変更してないからレジスタに入ってる内容で代用しようみたいなコードに
なってはいけないわけだ。volatile を付けておくとそういう最適化をしなくなる。 >>239
知らないほうが幸せだよ
本当に必要なプロジェクトなら、過去に誰かがよく分からん不具合に何日・何週間も悩まされた末にコーディングルールに追加されてるから >>239
UARTのFIFOレジスタとかに使う。
ハードウェアを直接叩かなければ普通は要らない。 >>235
やっぱアセンブララッパー言語はゴミコードだな setjmp(), longjmp() 使う時も volatile 使わねばならない時がある。
https://www.jpcert.or.jp/sc-rules/c-msc22-c.html
ま、longjmp() 使うこと自体が稀だろうとは思うが。 長いことやってるがsetjump,longjump見たことない。 ■ このスレッドは過去ログ倉庫に格納されています
