ライブラリとモジュールの違い ライブラリとモジュールは、両方ともコードの再利用を促進するために使用される概念ですが、意味や使用方法においていくつかの違いがあります。 ライブラリ: ライブラリは、特定の機能や機能セットを提供する再利用可能なコードの集まりです。 一般的に、ライブラリは独立して使用され、他のプログラムやプロジェクトで利用されることを目的としています。 ライブラリは、一般的な問題を解決するための関数、クラス、ユーティリティ、データ構造、アルゴリズムなどの要素を含むことがあります。 ライブラリは、プログラム全体に影響を与えることなく、必要な機能を選択的に使用できるようにするため、モジュールやコンポーネントとして提供されることがあります。 モジュール: モジュールは、コードの構造化と組織化を目的とした小さな単位です。 モジュールは、関連するコードのグループ化とカプセル化を容易にします
JavaScript のプログラムはとても小さいものから始まりました。初期の用途は、必要に応じてウェブページにちょっとした対話的な機能を追加する独立したスクリプト処理がほとんどであったため、大きなスクリプトは通常必要ありませんでした。そして何年かが過ぎ、今や大量の JavaScript を持つ完全なアプリケーションをブラウザーで実行することはもちろん、JavaScript を他のコンテキスト(例えば Node.js)で使うこともあります。 それゆえ近年は、JavaScript プログラムをモジュールに分割して必要な時にインポートできるような仕組みの提供が検討されるようになってきました。Node.js は長年この機能を提供しており、モジュールの利用を可能にする JavaScript ライブラリーやフレームワークも数多くあります(例えば、他の CommonJS や、AMD ベースのモジュールシ
JavaScriptにおける「モジュール」の定義 モジュール(module)とは「変数や関数をまとめたもの」で, JavaScriptにおいては1つのモジュールは1つのjsファイルに対応します. 一つの大きなjsファイルにあらゆる機能を書くのではなく, モジュール化を行なって小規模なjsファイルの組み合わせとして表現することにより, コードの可読性が増したり変数や関数名の衝突を防ぐことができたりなどの様々な恩恵が受けられます. importとrequireの違い importとrequireはどちらもモジュールの読み込み方法を表しています. importはブラウザ上で動作するES6のモジュールシステムであり, requireはNode.jsの環境で動作するCommonJSのモジュールシステムという違いがあります. importについて モジュール側では関数やクラスを定義する際に先頭にexp
みなさんこんにちは、現役エンジニアのサメハックです アパレル企業でトップ販売員を経て 未経験からWebエンジニアに転職し、 現在正社員として5年働いています! JavaScriptの解説シリーズです。 今回はexportとimportを使ったモジュール化について学んでいきましょう! 駆け出しエンジニアや未経験の方、 また新入社員を指導する先輩社員にとっても わかりやすいように解説していきます!
改めて(?)か昔からあるのか不明ですが、10進小数を言語のデフォルトにすべきかどうかという議論が一部で行われています。私自身、特にプログラミング教育を最近やっている立ち場もあって、10進小数を言語のデフォルトにすることに賛成の立ち場です。ただ、正直言ってこれに大して「反対する」側は何が焦点になっているかについて「ずれている」と思わざるをえないです。まずは、直近で見かけたWindyMeltさんのブログ記事より。 blog.3qe.us ちなみにこれはCOBOLかそうではないか、という軸が問題になっているのではなく、浮動小数点型を利用するか、それともBigDecimalのような十進演算のために用意された型を利用するか、という軸の問題であって、しかもそれも正確な軸の取りかたではない。 というのも、BigDecimalでカバーされない問題があるのだ。例えば、BigDecimal型を利用しても(1
C言語(C++を含む)を習得したい人,ポインタを勉強したい人はgcc-14を使いましょう.難しいところは gcc-14 が丁寧に解説してくれます C言語の難しいところ 例を示します.C言語で記述された,たった6行のソースコードです int main() { int buf[10]; buf[10] = 0; return 0; } このソースコードには問題があります.初見でわかるでしょうか? : : : 問題があるのは buf[10]=0 の部分です.C言語でやりがちなミスですが,これがバグやセキュリティホールの原因になります. C言語が難しい理由は二つあります.この手の問題を見逃しやすい点と,この手の問題を理解することが難しい点の二つです gcc 14 に解説してもらいましょう 上記の6行のソースコードをgcc14を使ってコンパイルしてみます ソースコードのファイル名は test.c と
3.9 Static 解析を制御するオプション ¶ -fanalyzer ¶ このオプションを使用すると、プログラム フローの static 分析が有効になり、コード内の「興味深い」プロシージャ間パスを検索し、そこで見つかった問題に対して警告を発行します。 この分析は、他の GCC 警告よりもはるかに高価です。 技術的に言えば、コンパイル中のコードのカバレッジに基づいたシンボリック実行を実行します。それは健全でも完全でもありません。 false ポジティブと false ネガティブが存在する可能性があります。これはプログラムの正しさを証明するツールではなく、バグを発見するツールです。 このリリースでは、アナライザーは C コードでの使用にのみ適しています。 このオプションを有効にすると、次の警告が有効になります。 -Wanalyzer-allocation-size -Wanalyzer-
mutex のロックは、コストが高い、ということでしたが、アトミックを使ったほうが、今回の単純なケースでは、速い、ということが解りました。 また、_Atomicを利用した場合のほうが、ソースコードも簡単になります。 pthread_mutex_lockを使うと pthread_mutex_unlock の呼び出しも必要になり、コードが汚くなってしまいます。 ヘッダファイル サンプルコードの意味 2つのスレッドを同時に実行します。 片方の1つのスレッドは、グローバル変数 shared_data をインクリメントし続けます。 もう1つのスレッドは、グローバル変数 shared_data をデクリメントし続けます。 最終的に 0 になることを期待します。 ロックなしのコードは、アトミックに処理できないので、結果は不定です(0かもしれないし、0以外かもしれない)。 pthread_test1_no
お断り: この記事の内容は、所属先の見解ではありません。 わりと何でもありのPHP界隈ですが、長年その状態を放置してきたため様々なスタイルのコードが存在することになり、PEARのようにまともにメンテナンスされてないコードを生み出してしましました。 さすがに何かしらの標準が必要では? ということで、PHP-FIGという組織がPHPに関するコーディングスタイル、autoload仕様、インターフェイス仕様を決めており、事実上の標準になっています。 PHP-FIG発足とほぼ同時に制定されたPSR-1, PSR-2はコーディングスタイルに関する標準で、PSR-1が基本的な内容、PSR-2がそれに追加してカッコの位置、スペースの入れ方、インデントのとりかたなど細かい内容になっています。 PSR-1は誰でも割りと受け入れられやすい内容だとは思いますが、PSR-2はコーディングスタイルに深く踏み込んでるの
Dai MIKURUBE @dmikurube むかし実際、プログラミングを始めた人に「"文字列" の 42 と "整数" の 42 ってなにが違うんですか? そのまま足し算とかしようとするとエラーになるんですけど、でも 42 って書いてあるんだから足せればよくないですか」と聞かれてわりと回答に詰まった記憶がある。それできる言語も実在するしな… 2024-05-19 01:01:26
三行でまとめると シグナルハンドラ内でprintf()してはいけない というより、余計な処理を書いてはいけない もう一度言う、シグナルハンドラで余計なことをするな、非常に大事なことだ はじめに シグナルハンドラでやってよい処理は非常に限られるのに、全くルールを守らないサンプルコードが世の中に大量に出回っている。printf()するなんてもってのほかなのだが、カジュアルにそこらじゅうで見かけて非常に悲しい。 この記事では、そんな状況を少しでも改善したいと思い初心者向きに書いたものだ。そのため、下記では、回避するにはどう実装すればよいのか、ルールを破るとどうなるのか、といった点を先に簡潔に記述する。 なぜしてはいけないのか、POSIXだとかリエントラントだとか、は下の方に追いやっている。玄人は読んでてウズウズするだろうが、細かい話はできるだけ目につかないような構成としたため了解いただきたい。
libevのドキュメントでしたら 本家のREADME を参照するのが良いと思います。 ev_async は、マルチスレッド環境でイペントループに対して安全にイベントを通知する仕組みです。例えば、あるスレッドが ev_run() しているイベントループに対して、別のスレッドからループの終了を通知したいといった目的で利用されます。 以下に ev_async を用いて、別スレッドからイベントループを終了させるサンプルのコードを載せておきます。(※ エラー処理など省略しています) #include <stdio.h> #include <unistd.h> #include <pthread.h> #include <ev.h> struct ev_loop *loop; struct ev_async shutdown_w; static void * thread_main (void *ar
software.schmorp.de #include <stdio.h> #include <stdlib.h> #include <netinet/in.h> #include <ev.h> #include <strings.h> #define PORT_NO 3033 #define BUFFER_SIZE 1024 void accept_cb(struct ev_loop *loop, struct ev_io *watcher, int revents); void read_cb(struct ev_loop *loop, struct ev_io *watcher, int revents); int main() { struct ev_loop *loop = ev_default_loop(0); int sd; struct sockaddr_in addr;
PHP8などへ移行する際の互換性チェック 「PHP5からPHP8への移行は何が面倒なのか」の記事などに"PHP8移行ツール"とか"互換性チェックツール"というキーワードでたどり着いている人がいるようなので補足しておきます。 いきなりとどめを刺すようで悪いのですが、PHP5とかPHP7からPHP8へ自動移行をするようなツールはおそらくありません(*1)。ただ、互換性のチェックを"ある程度"助けるものとして、静的解析ツールというジャンルのツールを使うことはできます。 開発者でない人向けにざっくり説明すると、静的解析ツールとは、ソースコードをチェックして、エラーやバグの可能性がある怪しい箇所を指摘してくれるツールです。対象のスクリプトを実際には動作させずに内容をチェックすることから"静的"解析と呼ばれます。 PHP8に移行したいスクリプトを静的解析ツールにかければ、"ある程度"は修正箇所の洗い出
新しいプログラミング言語やライブラリ、フレームワークを学ぶには、実際にそれらを試して挙動などを見てみることが大事ですが、実行環境を用意するのは手間がかかります。 そこで役立つのが、いわゆる「プレイグラウンド」と呼ばれる、Webブラウザでプログラミング言語やライブラリ、フレームワークをすぐに試すことができるサービスです。 主要なプログラミング言語の公式サイトには、実際にその言語をすぐに試せるプレイグラウンドが用意されていることも多く、また公式サイト以外にもネット上にはさまざまなプレイグラウンドがあります。 プレイグラウンドを使えば、気軽にいろんなプログラミング言語やライブラリ、フレームワークを試せます。 この記事ではそうしたプレイグラウンドをまとめてみました。ここで紹介したプレイグラウンドの他にも、あなたのお気に入りのプレイグラウンドがあればX/Twitterやブックマークのコメント、メール
なぜ令和にもなって動的型付け言語を使うのか シフトレフトという概念が生まれたのは二十年以上も前のはずだ。 それにもかかわらず動かしてみるまで答え合わせもできない言語で開発をするという発想自体がどうかしている。 同じ動的型付けといってもJavaScriptはブラウザという事情があるし、型の表現力に優れたTypeScriptがあるからまだよい。 しかし、Pythonはどうだ。他にいくらでも選択肢があるなかで、サーバーサイドにわざわざ選定する言語ではなかろう。 貧弱な型ヒント、しかも書いたところで大した効用もない。 使っている外部ライブラリにひとつでも型ヒントがクソなものがあれば即座に破綻する。 型というガードレールもシートベルトもなしで糞を撒き散らしながらする開発にはうんざりだ。 シンタックスもキモい 動的型付けもさることながら、シンタックスもキモい。とにかく思考を妨げる語順になっている。 m
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く