タグ

C言語とプログラミングに関するtechman999のブックマーク (25)

  • 初心者のC言語

    since:2002.06.02 更新に手が回らずすみません。 ANSI規格でもいいよという方は 御覧ください。m(_ _)m

  • 大学での初心者に対するプログラミング講義ではC言語を使うべきでない - Qiita

    今日、大学に入って最初のプログラミングの授業があった。それについて少しばかり思うことがあったのでここに記す。以下の文章は、工学部情報系学科一回生の、最初のプログラミング授業について述べたものである。タイトルにもある通り、この文章は「初心者に対する」講義について言ったものであり、機械制御を専攻する学生に対する講義などを言うわけではない。 最初の言語がC 結論から述べよう。最初のプログラミング言語にC言語は向いていない。できないとは言わないが(私が最初に触れた言語もCだが)、より有力な候補がいくらでもある。私の所属する学科には機械分野に進む人も多いので、それに使われるCを、という思惑もあるのだろう。しかし、初心者が「プログラミングを」学ぶ言語としてはお世辞にも良いとは言えない。私が思うプログラミング初心者に向いた言語とは、次の条件を満たすものである。 現在普及している 環境構築が容易(私の大学

    大学での初心者に対するプログラミング講義ではC言語を使うべきでない - Qiita
  • The C Programming Language First Edition : Dennis Ritchie, Brian Kernighan : Free Download, Borrow, and Streaming : Internet Archive

    Dear Patron: Please don't scroll past this. The Internet Archive is a nonprofit fighting for universal access to quality information, powered by online donations averaging about $17. Join the one in a thousand users that support us financially—if our library is useful to you, please pitch in.

    The C Programming Language First Edition : Dennis Ritchie, Brian Kernighan : Free Download, Borrow, and Streaming : Internet Archive
  • 2016年、C言語はどう書くべきか (後編) | POSTD

    (前編はこちら: 2016年、C言語はどう書くべきか (前編) ) (編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int

    2016年、C言語はどう書くべきか (後編) | POSTD
  • 2016年、C言語はどう書くべきか (前編) | POSTD

    (訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

    2016年、C言語はどう書くべきか (前編) | POSTD
  • C言語で苦しむロックフリー入門(仮

    Please select the category that most closely reflects your concern about the presentation, so that we can review it and determine whether it violates our Terms of Use or isn't appropriate for all viewers.

    C言語で苦しむロックフリー入門(仮
  • やり直しC言語:複雑な宣言の読み方

    C言語は宣言文が非常に読みにくいことで有名で、後発のGo言語はこれを批判して宣言の構文を変えています。私もずっと読むのが苦手だったのですが、私の頭が悪いのではなく、C言語の仕様がヘン、ということらしい。 今まで飽きるほどこの手の解説は書かれてきてるわけですが、自分なりにまとめないと覚えた気がしないので、あえてまとめておきます。ここに書いてある内容は、「C言語ポインタ完全制覇」に詳しく書いてあります。 型の派生 C言語では、int, char, floatなどの基型から、配列やポインタを派生していくことができます。対象を並べたものが配列で、対象を指し示すのがポインタです。 配列やポインタからも配列やポインタを派生できるので、派生パターンは無限に存在します。 int int の配列 int の配列 の配列 ... int へのポインタ int へのポインタ へのポインタ ... int への

    やり直しC言語:複雑な宣言の読み方
  • C言語パズル集:Cにまつわる興味深い問題あれこれ | POSTD

    ビジターの皆さんへ C言語に関心を寄せていただきありがとうございます。このページは、C言語の面白い問題、パズルのリストです。これまでに友人たちからeメールで送ってもらったり、で読んだり、インターネットで見つけたり、あるいは自分でC言語でコーディングしていて気づいたりしたプログラムを集めました。 多くのプログラムは、コンパイル、実行され、その振る舞いを示すものです。問題は大まかに次のカテゴリに分けられます。 一般的なタイポエラー。C言語プログラマが頻繁に犯すミスであり、かつ追跡が困難。 初見では非常に理解しがたい小さなプログラム。これらの問題は、他人が書いた優れたコードを読み解く良い訓練になります。 また、全てにGnu/Linux/gccを使っています。掲載順は、それぞれの難易度とは関係ありません。問題解決の助けが必要な場合は、気軽に私に問い合わせてください。連絡先は こちら です。また、

    C言語パズル集:Cにまつわる興味深い問題あれこれ | POSTD
  • 初心者でもC言語に入門できる学習サイトと書籍9選 - paiza times

    Photo by Bill Bradford こんにちは。谷口がお送りします。 プログラミングをこれから学ぼうとしている方や、これから研修や実務に入る新人エンジニアの皆さんの中には「C言語を学習したい」という方もいらっしゃるかと思います。 純粋なC言語のみを利用する案件は近年減少していますが、組み込み系、制御系では依然C言語の案件が多く存在します。 また、Linuxのカーネルをカスタマイズしたり、nginxの拡張モジュールを置き換えて高速化するような場合や、ゲーム等で高速な処理が求められる場面での高度なチューニングにおけるニーズもあります。 C言語は、各実行環境のネイティブの機械語にコンパイルされて、CPUが直接コードを実行するため、処理速度が非常に高速であるという特徴があります。 RubyPHP等の開発言語も、C言語で実装されているんですよ。 そこで今回は、プログラミング未経験~初心者

    初心者でもC言語に入門できる学習サイトと書籍9選 - paiza times
  • C言語分かってなかった (I Do Not Know C) - Qiita

    Dmitri Gribenko氏によるBlog記事 "I Do Not Know C" より訳出。原文および訳文のライセンスは CC BY-SA 3.0 に従う。 この記事の目的は、皆に(とくにCプログラマに)「C言語分かってなかった」と言わせることです。 C言語の死角は思っているよりも身近にあり、よくある単純なコードですら 未定義動作(undefined behavior) を含む可能性があると示したいと思います。 記事は質問に対する回答の形をとります。全ての例示コードは別々のファイルに分かれていると考えてください。 (訳注:Qiita/Markdown表現の制約から、読中ネタバレ防止のため文章順序を変更しています。前半には質問のみを、後半には質問と回答の対を訳出しました。) 質問編 1.

    C言語分かってなかった (I Do Not Know C) - Qiita
  • C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」 | スラド デベロッパー

    Edsger Dijkstra氏がgoto文の危険性を主張したのは1968年。それから50年近く経過した現在もgoto文は使われ続けているが、Dijkstra氏が懸念したようなgoto文の無制限な使用が行われているのかどうかという点や、それがバグの原因となるような有害なものなのかどうかといった点については、よくわかっていなかったという。こういった点に関する実証研究が家/.で紹介されている。 家/.「Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"」より 200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行わ

  • Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱

    二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ! 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる. それはそうと例外設計において"無視"は大罪である. だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ. ということで、例えば以下のように逐一戻り値をチェックする. if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ. 一体コードのどの部分が正常系の処理なのか? ほとんどエラーハンドリング*1で埋め尽くされるじゃないか. そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい. エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った. in

    Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
  • 「C言語でプログラミングする際の覚書」の誤訳箇所 - アスペ日記

    ここでは、C言語でプログラミングする際の覚書の誤訳を列挙します。 参考として、私の翻訳はC言語プログラミングの覚え書き(改訳)にあります。 What follows is ... ×従うべきは ○これから述べるのは "What follows" で「続くもの」という意味です。ここでの「続く」というのは、現在の文章に続く、つまり「以下に述べること」です。 But they've been accumulating in my head, if not on paper until now, for a long time, ... ×しかし、私の意見は頭のなかにしばらくあったものをまとめたものであり、長らく文章として公開してきませんでした。 ○しかし、これらのことは、文書として書いたことはありませんでしたが、私の頭の中に長い時間をかけて蓄積してきたもので、… "if not on paper

    「C言語でプログラミングする際の覚書」の誤訳箇所 - アスペ日記
  • C言語プログラミングの覚え書き(改訳) - アスペ日記

    原文: Notes on Programming in C Rob Pike 1989年2月21日 Copyright (C) 2003, Lucent Technologies Inc. and others. All Rights Reserved. Lucent Public License Version 1.02 前書き KernighanとPlaugerによる“The Elements of Programming Style” (「プログラム書法」木村泉訳)は重要で影響力のあるです。このにはそれだけの価値があります。しかし、その中の簡潔なルールが、来意図されたような哲学の簡潔な表現としてではなく、よいスタイルのレシピとして受け取られているように私は時々感じます。このが変数名は意味を持つようにつけられるべきだと言うなら、名前が使い方を説明するちょっとしたエッセイのような

    C言語プログラミングの覚え書き(改訳) - アスペ日記
  • 学習用C言語開発環境 Ver 0.1.13 - 苦しんで覚えるC言語

    「ブラウザで動く C言語実行環境」 のご紹介 ・もっと手軽にC言語を始めたい ・スマートフォン、タブレット、Macでも、手軽にC言語を始めたい という声にお答えして、C言語開発環境のブラウザ版を用意しました! ブラウザから今すぐC言語のプログラミングが開始できます。 一発インストール ファイルサイズはわずか3MB。たったそれだけで、エディタ、コンパイラ、実行環境、プログラミング学習に必要なものがすべて揃います。 長時間のダウンロードも、面倒な設定も、プラグインのインストールも、何もいりません。 あなたは今すぐにプログラミングを始めることができます! 自動プロジェクト あなたがやるべきことはプログラムの入力だけ! 起動すれば、プロジェクトが自動的に作成され、自動的に複数のソースファイルを認識します。 ビルドにまつわる面倒な設定はエディタが自動管理。プログラミングに集中できます。

    学習用C言語開発環境 Ver 0.1.13 - 苦しんで覚えるC言語
  • C vs Python vs Ruby vs Haskell(無意味な処理deベンチマーク) - しんちゃんの日記

    「Haskell入門以前」のネタバレになってしまいますが、[ [1,2,3],[4,5,6],[7,8,9] ]を受け取って、各要素を反転させた[ [3,2,1],[6,5,4],[9,8,7] ]を受け取り、その最後尾の要素の最後尾(このデータでは7)を表示する処理を作り、なるべく大きなデータを渡して実行時間を計測してみました。 (自分のPCでは4000x4000のデータを渡してます) Haskellのコードは他の言語のコードとは全く違う発想で書かれています。どうして同じ結果になるかを考えてみたりすると関数型言語と手続き型言語の違いに気付くかも知れません。 (この辺が「Haskell入門以前」のネタバレ。気付けなかったら、「Haskell入門以前」と言う電子書籍がブクログのパブーより出てますので、読んでみて下さい) まずは、各言語のコードを書きます。 C言語 #include #incl

    C vs Python vs Ruby vs Haskell(無意味な処理deベンチマーク) - しんちゃんの日記
  • あなたもできる!C言語でテトリスを40分で作る方法 · DQNEO日記

    デモ ニコニコ動画の伝説の動画 「テトリスを1時間強で作ってみた【実況解説】」という動画をご存知でしょうか? 2009年にニコニコ動画で公開されて話題になった動画です。 インタビュー記事:「テトリスを1時間強で作ってみた」動画の投稿者にインタビュー──「プログラミングの楽しさ伝えたい」 この動画ではテトリスをいちから作ってわずか62分で完成させています。 しかし実はスタート直後はMinGWのインストール、EmEditorのインストールに続いてブロック画像の作成などをしており、プログラミングが始まるのは開始13分のところからです。 さらに次の10分は「空のウィンドウ」を作るために時間を使っており、実質的にテトリスのプログラミングが始まるのは動画23分のところからです。 つまり、実質的に40分のプログラミングでテトリスを完成させています。 で、動画を見ながら同じようにやれば誰でもテトリスを作れ

    あなたもできる!C言語でテトリスを40分で作る方法 · DQNEO日記
  • C言語における文字列連結 — KaoriYa

    C言語で文字列連結を行う。とても簡単に思えるけれど、実はパフォーマンスについて考えることもあるんだよ、というお話。 C言語で2つ文字列の連結して、1つの文字列にするプログラム(関数)を書けるでしょうか? ちょっとC言語でプログラミングを学んだことがあれば簡単ですよね。要求仕様としては2つの引数aとbをとり、どちらもNULターミネートな文字列で、その文字列をヒープから確保した領域で連結して戻り値として返す、という感じの動作です。ヨユーですね。ちょっと書いてみてください。 char* str_join(const char* a, const char* b) { char* p = malloc(strlen(a) + strlen(b) + 1); strcpy(p, a); strcat(p, b); return p; } こんな風に書いてしまったあなたは及第点です。個人的には失格です

  • 世界で2番目にわかりやすいポインタの話

    これ以上に解りやすく説明できるという人は、@super_rti までURLを教えて下さい。世界一わかりやすいの看板を差し上げます。

    世界で2番目にわかりやすいポインタの話
  • プログラム初心者にC言語のポインタを不本意ながら教える羽目になったなら、こう教えると良いよ - 偏見プログラマの語り!

    僕がプログラミングに触れた当時は、プログラミングといえば「まず C 言語」でした。それから 10 年以上が経ちました。学校の授業や企業の研修では未だに C 言語を教えているところがあるようです。関数型プログラミング言語という波が来ている 2012 年にもなって未だに C 言語をやっているというのはまるで進歩が無く残念な気もしますが、比較的多くのプログラマに浸透している共通言語を最初に教えるというのは、一方では喜ばしい事だと解釈する事もできるのかもしれません*1。まぁとにかく、意にせよ不意にせよ現場で プログラム初心者に C 言語を教える羽目になった 人がたくさんいて、プログラム初心者なのに C 言語を学ばざるを得なくなった 若者がたくさんいるということです。 C 言語を教えるときに避けて通れないのがポインタで、プログラム初心者が C 言語を学ぶときにやたらとつまずく人が多いのがポインタ

    プログラム初心者にC言語のポインタを不本意ながら教える羽目になったなら、こう教えると良いよ - 偏見プログラマの語り!