『忠犬もちしば』のAIを育てるとグッズが貰える!>>

こんにちわ。
いつも教えてgooにお世話になっているorange_pieです。
UNIX上のC++で作成した自作ライブラリをdllにして配布したいのですが、
Unixでの基本的な考え方を教えてください。

(1)Unix上ではDLLの標準的な名称は”libxxxx.so”とするのが普通ですか?
 ※この形式ならLD_LIBRARY_PATH環境変数が検索してくれる。。。
(2)通常、DLLにする場合、インポートライブラリ(.lib)と実際のライブラリ(.so)を作成して、使用する側はインポートライブラリのみをリンクするのでしょうか?
(3)配布されたdllを使う側では、Link時にインポートライブラリをリンクして、関連インクルードファイルをインクルードするだけで使えるのでしょうか?
(4)上記の(2)のように、インポートライブラリとライブラリの実態を作成する為のコンパイルオプションが見つかりません。(ldのmanを見たのですが、意味がわからないと言うか。。。。。)

この質問は、自作ライブラリからlibxxx.soという形のオブジェクトファイルを作り、別プログラムからこのlibxxxをコンパイルオプション(-l)でリンクしてみたら正しく動作したのですが、これでは結局ライブラリの本体が一緒にリンクされている様子で、出来上がった実行形式のファイルサイズが静的ライブラリとしてリンクした時と同じ大きさになっていることに疑問を抱いてしまったものです。
 この状態でも、ライブラリの方だけコンパイルしなおして実行すると
ちゃんとライブラリの変更点は反映されるので問題は無いのですが、
これでもダイナミックリンク・ライブラリと呼べるのでしょうか?

このQ&Aに関連する最新のQ&A

A 回答 (3件)

# すっごく暇ってわけではないんですが :-)



> -Wl,-B,dynamic -lclntsh -ldl -lm -lnsl -lsocket -lrt -lpthread
>
> この中の”-B, dynamic ”の辺りが「ライブラリをダイナミックにリンクするよ」ってことだったのでしょうか?

man ld の -l と -B のところを読めば分かると思いますが、大体、そういうことです。

-B dynamic の場合(普通は、こっちがデフォルト)には -lxxx の指定で libxxx.so
を探して、無ければ、libxxx.a を探します。-B static の場合には libxxx.so を
対象にしません。

参考URLには solaris の AnswerBook を紹介しておきます。


> ということも考慮に入れると、arコマンドで作ったアーカイブもDLLもリンクオプションで-B dynamic とすれば、実行時にリンクできる。(のかな?)

いやいや。静的なライブラリ、っつう位ですから、静的なリンクにしか使え
ません。

.a も .so も「ライブラリ」って名前がつきますけれど、.a はアーカイブファイル
なので、tar の出力ファイルの方に似ています。.so の方は、実行形式のヘッダを
持ち ELF というフォーマットのファイルで実行バイナリの方に似ています。


> で、他人に提供するのにアーカイブとDLLのどちらが適しているかというと、
> 関数などが増えた場合以外はどちらでも同じ(という感じ?なのかな?)

その「他人」の環境次第なんですが、相手の OS やバージョンが特定できないと
静的なアーカイブの方が、利用できる可能性が少し広いです(ソース提供には
遠く及ばないですが)。

> arコマンドは、複数のオブジェクト(.o)を追加することで作成しなおすことができるが、DLLはライブラリ構成プログラムをリコンパイルする必要がある。

リコンパイルではなく、再リンクです。


後、共有ライブラリの場合には、あまり小さく刻んでしまうとロードの時間が
気になり出すので、ひとつのファイルの単位をどうするかを悩むときがあり
ます。


最後に、No.2 の回答にあるように unix をひと括りにして、.so が普通、と
言うのは、ちょっと大雑把すぎました。他の質問のことが頭にあったもので
orange_pie さんが使っている環境を暗に想定してました。

十年くらいさかのぼっただけで共有ライブラリが扱えない unix なんてのは、
ごろごろしてましたし。

参考URL:http://docs.sun.com:80/ab2/coll.153.4/REFMAN1/@A …
    • good
    • 0
この回答へのお礼

本当にお忙しいのに、ありがとうございます。いつもいつも。。。 (。・_・。)
>a も .so も「ライブラリ」って名前がつきますけれど、.a はアーカイブファイル
>なので、tar の出力ファイルの方に似ています。.so の方は、実行形式のヘッダを
持ち ELF というフォーマットのファイルで実行バイナリの方に似ています。
すばらしいです!!すっきり解決。すんなり納得。もう混乱しません。
どうしたら、こんなに正しい知識を幅広くお持ちになれるんでしょう。。。
もしかして、教授さん?
これからは、ぷろくまさんと呼ばせていただきます。(私だけ。)
参考URLは、Solaris上でmanコマンドを叩いたのと同じ情報のようですね。
これなら、いちいちターミナルからSolarisに接続しなくても良いので早速「お気に入り」に入れちゃいました。
本当にありがとうございました。

お礼日時:2001/10/10 09:15

a-kumaさんの回答でだいたい良いのですが、


> (1)Unix上ではDLLの標準的な名称は”libxxxx.so”とするのが普通ですか?
これはUNIXの種類によります。SolarisやLINUXではその通りですが、HP-UXなどでは
libxxx.shになったりします。
あとlibxxx.aは静的ライブラリです。-B dynamic というリンクオプションが無ければ
こちらがリンクされます。-B static と明示的に指定することもできます。
    • good
    • 0
この回答へのお礼

は~。なるほど~。です。
”.a”と言ったら一般的に静的だと思えばよいのですね。
それならばやはり”.so”です。
ちなみにSolarisでの開発なので、libxxxx.soと言う形にしました。
このようなルールって、厳密に決められている訳ではなくて
”通常、こうだよね”というような、経験者の方に聞かなければ分からないことが多いような気がします。

無事にdllを作成して、配布できるまでに至りました。
みなさんのおかげです。
本当にありがとうございました。

お礼日時:2001/10/09 17:27

> (1)Unix上ではDLLの標準的な名称は”libxxxx.so”とするのが普通ですか?



そうです。

OS によっては、libxxx.so は、libxxx.so.バージョン番号 というファイルへの
シンボリックリンクになってたりしますが、ローダが *.so というファイルを
探しに行くことが基本なのは一緒です。


> (2)通常、DLLにする場合、インポートライブラリ(.lib)と実際のライブラリ(.so)を作成して、使用する側はインポートライブラリのみをリンクするのでしょうか?

unix では、インポートライブラリなんて不細工なものは気にしなくても良いです。
直接、共有ライブラリがリンクできることは経験した通り。


> (3)配布されたdllを使う側では、Link時にインポートライブラリをリンクして、関連インクルードファイルをインクルードするだけで使えるのでしょうか?

インポートライブラリなんてものが要らないのは (2) の回答で書いた通り。

インクルードファイルが必要なのは、C/C++ で共通の定数やプロトタイプが
記述してあるから、という理由なだけで、「DLLを使う」ための必須の条件では
ありません。


> (4)上記の(2)のように、インポートライブラリとライブラリの実態を作成する為のコンパイルオプションが見つかりません。(ldのmanを見たのですが、意味がわからないと言うか。。。。。)

というわけで、unix のマニュアルを見ても永遠に分かることはないでしょう。


> これでは結局ライブラリの本体が一緒にリンクされている様子で、出来上がった実行形式のファイルサイズが静的ライブラリとしてリンクした時と同じ大きさになっている

ちょっと信じられません。

> ライブラリの方だけコンパイルしなおして実行するとちゃんとライブラリの変更点は反映される

ということから、共有ライブラリとしてはきちんと作成されているようです。

多分、静的なライブラリをリンクしたつもりになっているだけで、動的な
ライブラリがリンクされているはずです。

ld の man などに、libxxx.a と libxxx.so の両方が存在しているときの
動作について説明があるはずです。libxxx.so を削除してしまってから
もう一度、リンクをしてみてください。

実際にモジュールの参照が静的に解決されているかどうかは、nm という
コマンドで確認することが出来ます。
    • good
    • 0
この回答へのお礼

なるほど~。
インポートライブラリって、確かOS/2だかWindowsだかでDLLを作った時に「作れ!!」と言われたような気がして、Unixでも「そうなのかな~」と漠然と思ってしまいました。気にしなくてよかったのですね。

それから、
>多分、静的なライブラリをリンクしたつもりになっているだけで、
>動的なライブラリがリンクされているはずです。
についてですが、静的なライブラリをリンクしていたつもりのMakefileを見直して見たところ、Linkオプションに以下のように指定してありました。

-Wl,-B,dynamic -lclntsh -ldl -lm -lnsl -lsocket -lrt -lpthread

この中の”-B, dynamic ”の辺りが「ライブラリをダイナミックにリンクするよ」ってことだったのでしょうか?
そうだとすると、「静的にリンクしていたつもりで、実はもともと動的にリンクしていた」ということになり、サイズが同じという疑問が解けてすっきりします。

ん?
それでは、".a”と”.so”の違いってなんでしょう?

以前、くまさんが教えてくださった、
>ar コマンドで作成されるアーカイブとは違って、DLL は「リンクされたもの」 ですから、必要なオブジェクトファイルが増減したときには、追加・削除では
なく、常に再リンクをすることに注意してください。

ということも考慮に入れると、arコマンドで作ったアーカイブもDLLもリンクオプションで-B dynamic とすれば、実行時にリンクできる。(のかな?)

で、他人に提供するのにアーカイブとDLLのどちらが適しているかというと、
関数などが増えた場合以外はどちらでも同じ(という感じ?なのかな?)

arコマンドは、複数のオブジェクト(.o)を追加することで作成しなおすことができるが、DLLはライブラリ構成プログラムをリコンパイルする必要がある。

ということになるのでしょうか? 
Unix的に美しいのは、.soですよね。きっと。

あ~。長々とすみません。
いろいろありがとうございます。
くまさんもお忙しいでしょうから、お返事はすっごく暇なときがあったらで
良いです。お返事がなくても自分でアーカイブとDLLの違いくらいは理解できるように探求します。
本当にありがとうございました。

お礼日時:2001/10/09 15:37

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QUNIX上のプログラムで使うライブラリの中身を知る方法

過去にUNIX上で動作するプログラムを作成していて、その中で多数の.aや.so(標準では無く、オリジナルのもの。)を使っているのですが、.aや.so内にどのような関数があるのか、もしくはそのライブラリに関係するソース名は何か知る手段ってありませんか?
かなり前のものなので、関数仕様書もmakefileも無いため、何をライブラリとしているのか分からず困っています。
駄目もとで、バイナリエディタで中身を確認してみたのですが、何処の情報がそれを示しているかいまいち分かりませんでした。

Aベストアンサー

No.2 の方がご回答されているように、nm コマンドを使えばシンボルの一覧を表示できます。

(ex.1)
$ nm /usr/local/lib/libssl.so
U ASN1_INTEGER_get
U ASN1_INTEGER_set
U ASN1_check_infinite_end
U ASN1_dup
U ASN1_get_object
U ASN1_object_size
U ASN1_put_object
U BIO_callback_ctrl
U BIO_copy_next_retry
U BIO_ctrl
U BIO_f_buffer
00027db0 T BIO_f_ssl

ただし、U となっているものはライブラリ内で未定義のシンボル (変数や関数) であり、他のライブラリによって解決されなければならないものだったと思います。

また、ライブラリが strip コマンドによって strip されてしまっている場合はシンボルテーブルが削除されてしまうため確認できません。

(ex.2)
$ nm /usr/lib/libstdc++.so.5
nm: /usr/lib/libstdc++.so.5: シンボルがありません

No.2 の方がご回答されているように、nm コマンドを使えばシンボルの一覧を表示できます。

(ex.1)
$ nm /usr/local/lib/libssl.so
U ASN1_INTEGER_get
U ASN1_INTEGER_set
U ASN1_check_infinite_end
U ASN1_dup
U ASN1_get_object
U ASN1_object_size
U ASN1_put_object
U BIO_callback_ctrl
U BIO_copy_next_retry
U BIO_ctrl
U BIO_f_buffer
00027db0 T BIO_f_ssl

ただし、U となって...続きを読む

Qインポートライブラリ(.lib)ファイルについて

インポートライブラリファイル(.lib)とは
何を行うファイルなのでしょうか。
外部DLLを使用可能にするためのファイルでしょうか。
libファイルの意味、使用方法を教えてください。

Aベストアンサー

そのとおりです。間接的にリンクできる関数はDLLにあって、実行時にリンクすることがあります。DLLの関数群を直接コールすることもできるはずですが、それらの関数をコールするための手続きをインポートライブラリとして用意しておくことが多いようです。

どうも、間違ってはいないんだけど、いまいちつかめないといった感じですね。

実行ファイルの中に入っているのが直接リンクした関数で、実行時にリンクされるのが間接的にリンクする関数と言うことになるでしょう。

C++ Builder5のことはよくわかりません。ごめんなさい。

Qwindows.hがincludeされない

http://www.microsoft.com/japan/msdn/vstudio/express/visualc/usingpsdk/を見ながら何度も試したのですがどうしてもwindows.hがインクルードされません。上記のページに書いてあること以外に必要な作業があるのでしょうか?

Aベストアンサー

回答見る限り、パスが設定されてないっぽいですね。

具体的には
http://www.microsoft.com/japan/msdn/vstudio/express/visualc/usingpsdk/
の手順3です。

VC++ 2005のメニューから、
ツール → オプション → プロジェクトおよびソリューション → VC++ ディレクトリ
で、
ディレクトリを表示するプロジェクト→
・実行可能ファイル
・インクルードファイル
・ライブラリファイル
の3つの場所にそれぞれ手順3に書かれたパスを追加します。

インクルードファイルの項に追加したパスが、windows.hのある場所なので、これで大丈夫だと思います。
自分もここでつまずいたので…

QWindowsからLinuxへの移植

Microsoft Visual Studio .NET 2003で書かれたプログラムをLinux移植しようとしているのですがどこがどう違ってくるのでしょうか?
使用言語はC++です。あまりプログラムに詳しくないものでGoogleなどで調べてもよくわかりませんでした。
参考になるURLでもいいのでどなたか御教授お願いします。

Aベストアンサー

私も手っ取り早くコンパイルしてみることをお勧めします。
詳しくない人が下調べしまくっても移植を始めてから問題が出てくるだけだろうと思いますので、コンパイルしてみて出てくるエラーをここで聞いたほうが早いと思います。
今Linuxの環境があるのであれば、#include <windows.h> をコメントアウトして、makefileなんて書かなくてよいですから、gcc -c file.cで試しにコンパイルしてみましょう。

QLNK2019: 未解決の外部シンボルのエラーが出る

Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5 SP1
----------------------------------------------------------------
新しいプリジェクト→Win32 コンソール アプリケーション(ソリューションのディレクトリを作成 チェック外す)→Windows アプリケーション(空のプロジェクト チェック外す)
----------------------------------------------------------------
 プログラム

 mymain.cpp
#include "myhelper.h"
#include "mymain.h"

//自キャラのデータ
Point2D g_jikipos = {40, 400};//自キャラの座標

//画像ハンドル
int g_jikiimage[11];

//色々なファイルの読み込み
int LoadFiles(){
//画像ファイル読み込み
if(LoadDivGraph("media\\player01.bmp",
11,11,1,64,64,g_jikiimage) == -1) return -1;

return 1;
}


 mymain.h
//他から呼び出させるMyMainの関数
void MyMain();
int LoadFiles();


 myhelper.h(サンプルなので打ちミスはない)
#include "DxLib.h"
#include <limits.h>
#include <math.h>

//構造体宣言
//座標またはベクトルを記録する構造体
struct Vector{
float x,y;
};
typedef Vector Point2D;
//線を記録する構造体
struct Line2D{
Point2D startpos, endpos;
float katamuki;//傾きをラジアン値で記録
Vector speed;//移動している場合は速度をセット
};
//球体を記録する構造体
struct Ball2D{
Point2D position;
float hankei;//半径
};
//四角形を記録する構造体
struct Rect2D{
Point2D lefttop;
Point2D rightbottom;
float width;
float height;
};


//ライブラリ関数
Point2D PosInView(Point2D in);
int XInView(float inx);
int YInView(float iny);
void ScrollToLeft(float jikiposx);
void ScrollToRight(float jikiposx);
void ScrollToUp(float jikiposy);
void ScrollToDown(float jikiposy);
void DrawLineInView(float x1, float y1, float x2, float y2, int Color, int Thickness);
void DrawCircleInView(float x, float y, float r, int Color, int FillFlag);
void DrawAnimation(float x, float y, double ExtRate, double Angle,int TurnFlag,
int *imgarray, int allframe, float fps);
//ベクトル関数
Vector CreateVector(Vector in, float veclen);
Vector AddVector(Vector v1, Vector v2);
Vector SubVector(Vector v1, Vector v2);
Vector AddVectorInFrameTime(Vector pos, Vector speed);
Vector AddVectorInFrameTime2(Vector pos, Vector speed, Vector accel);
Vector Normalize(Vector in);
Vector RotateVector(Vector in, float radian);
float VectorLengthSquare(Vector in);
float DotProduct(Vector v1, Vector v2);
float CrossProduct(Vector v1, Vector v2);
void SetLine2DKatamuki(Line2D *in);
void DrawLine2D(Line2D in, int Color, int Thickness);
void DrawBall2D(Ball2D in, int Color, int Fill);
//当たり判定関数
bool HitTestLineAndBall(Line2D linein, Ball2D ballin);
bool IsPointAtLineFace(Line2D linein, Point2D ptin);
bool HitTestLineAndLine(Line2D line1, Line2D line2);
bool HitTestBallAndBall(Ball2D a, Ball2D b);
bool HitTestPointAndBox(Rect2D rect, Point2D pt);
//タイマー関数
void SetSimpleTimer(int idx, int time);
int GetPassedTime(int idx);


//グローバル変数
extern float g_frametime;
extern Rect2D g_framerect;//画面領域(当たり判定)
extern Point2D g_current_field_pos;//現在の左上座標
extern Rect2D g_stagesize;//ステージサイズ

//定数宣言
const float ZEROVALUE = 1e-10f;
const float PIE = 3.1415926f;
const int SCROLL_LIMIT = 200;
----------------------------------------------------------------
 エラー内容
1>myhelper.obj : error LNK2019: 未解決の外部シンボル "void __cdecl MyMain(void)" (?MyMain@@YAXXZ) が関数 _WinMain@16 で参照されました
1>C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\my\Debug\my.exe : fatal error LNK1120: 外部参照 1 が未解決です
1>my - エラー 2、警告 0
ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ
----------------------------------------------------------------
画像を貼り付けときます
(見えにくい場合→http://www.dotup.org/uploda/www.dotup.org154142.jpg.html)
初心者なのでわかりやすくお願いします

Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5 SP1
----------------------------------------------------------------
新しいプリジェクト→Win32 コンソール アプリケーション(ソリューションのディレクトリを作成 チェック外す)→Windows アプリケーション(空のプロジェクト チェック外す)
----------------------------------------------------------------
 プログラム

 mymain.cpp
#include "myhelper.h"
#include "mymain.h"

//自...続きを読む

Aベストアンサー

ファイル構成から推測するに
mymain.cpp というファイルに
void MyMain(void) {
// ここに処理を書く
}
という関数が必要なようです。

Qcout と cerrの違い

こんにちわ。
どうも初歩的な質問だと思うのですが、教えてください。

C++で、cerrとcoutの違いは何なのでしょうか?
どちらも同じように出力できますし。
自分でエラー表示を出力させたいような時にcerrを使えばよいのでしょうか?

使い分ける必要がいまいち分かりません。
お暇なときにでもお願いします。

Aベストアンサー

cerr:標準エラー出力 =C言語では stderr
cout:標準出力 =C言語では stdout

どちらもコンソールへの出力ですが、違いはハンドルが違うことです。
このため、リダイレクトやパイプのやり方が変わります。
http://www-or.amp.i.kyoto-u.ac.jp/algo-eng/db/stdinout.html

この違いを利用すると、通常の出力を標準出力に出力しエラーのみエラー出力に
しておくことで、リダイレクトやパイプを利用しているときでも、エラーは
コンソールに出力されるので便利になります。

尚、Windows系では、標準エラー出力へのリダイレクトは
abc 2> route.txt
のような書式になります。(#2さんの書式はWindows系では使えません)
http://www.monyo.com/technical/windows/04.html

参考URL:http://www-or.amp.i.kyoto-u.ac.jp/algo-eng/db/stdinout.html,http://www.monyo.com/technical/windows/04.html

cerr:標準エラー出力 =C言語では stderr
cout:標準出力 =C言語では stdout

どちらもコンソールへの出力ですが、違いはハンドルが違うことです。
このため、リダイレクトやパイプのやり方が変わります。
http://www-or.amp.i.kyoto-u.ac.jp/algo-eng/db/stdinout.html

この違いを利用すると、通常の出力を標準出力に出力しエラーのみエラー出力に
しておくことで、リダイレクトやパイプを利用しているときでも、エラーは
コンソールに出力されるので便利になります。

尚、Windows系では、標...続きを読む

QwindowsでLinuxで作成したソースをコンパイル

Linuxで作成、
$gcc -Wall file.c
で、通ったファイルをWindowsでも同様に通したいので、MinGWを使って、コンパイルしたのですが、
#include <sys/socket.h>
の構文で引っかかってしまいました。どうやらインクルードファイルが無いようでしたので、
C:\MinGW\include
C:\MinGW\lib
以下に、Linuxの
/usr/include/
/usr/lib/
以下のファイルをそのまま入れて、再度実行しました。

ヘッダーファイルは見つけて読んでくれたのですが、そのヘッダーファイルに書いてある関数(例:htons(), socket(), inet_addr(), connect())が参照できないとの事で、怒られてしまいます。

Linuxのライブラリファイルをそのまま入れたのがまずかったのかもしれないのですが、こいつのエラーを解消する有効手段が見つかりません。

問題解決のヒント、又は答えを教えていただけませんでしょうか。
どうか、お願い致します。

Aベストアンサー

Unix と Windows ネイティブな環境では基本的にヘッダファイルやライブラリの構造が、基本骨格 (いわゆる、stdio.h や stdlib.h などに含まれている関数) を除いては大きく異なっているので、Unix でコンパイルできたプログラムが必ずしも Windows でコンパイルし、実行できるわけではありません。(もちろん、その逆も当てはまります)

MinGW は Windows ネイティブな実行プログラムを作成するものなので、MinGW でコンパイルする場合はちゃんと Windows 用のプログラムとして書かなければなりません (#2の方が書かれているように、socket.h ではなく、winsock2.h を使用するなど)。もし、Unix にのみ対応したプログラムを Windows 上で動かしたいと言うことであれば、Cygwin (要するに Unix 関数の処理を Windows ネイティブな処理に変換するエミュレータ) を利用する必要があります。

Q64bit対応

32bitマシンで使っていたソースを、64bit化する際に
気をつけたこと、困った経験などがありましたら、教えて下さい。

どういったことが問題になるのか、勘所がわからないので、
勉強の為に質問させていただきました。
具体例なんかあると嬉しいです。
よろしくお願いします。

Aベストアンサー

#3です。
>tatsu99さんは、64bit対応の際に、まずそれぞれの型のバイト長を
>調べて、2.long型を使用しないとされたんでしょうか。
その通りです。プログラマたるもの、そのぐらいは常識です。
マニュアルで調べ、かつ全ての型を、
printf("charのサイズ=%d",sizeof(char));
printf("char*のサイズ=%d",sizeof(char*));
printf("intのサイズ=%d",sizeof(int));
のようにして調べて下さい。
その結果、long型が32ビットと64ビットで異なるため通常は使用しないようにしました。

>私はintを使わないようにと言われたことがあります。
>なぜなのかよくわかってないので、
int型は、かつての古きよき時代(MS-DOSの時代)には2バイトでした。そのため、int型は、OSによりサイズが異なると思っている人が多いです。そのために、上記のことをいわれたのかと思います。この認識は、正しい場合もあり、そうでない場合もあります。(HP-UX,solarisでは正しくありません)
どのOS(又はコンパイラ)で、64ビットにするかは、わかりませんが、それが、明確になったとき、全ての型のサイズを自分で調べることが、大切です。

#3です。
>tatsu99さんは、64bit対応の際に、まずそれぞれの型のバイト長を
>調べて、2.long型を使用しないとされたんでしょうか。
その通りです。プログラマたるもの、そのぐらいは常識です。
マニュアルで調べ、かつ全ての型を、
printf("charのサイズ=%d",sizeof(char));
printf("char*のサイズ=%d",sizeof(char*));
printf("intのサイズ=%d",sizeof(int));
のようにして調べて下さい。
その結果、long型が32ビットと64ビットで異なるため通常は使用しないようにしました。

>私はintを使わ...続きを読む

QVisual Studio でmakefileを使う方法

これまで、makefileを使って開発をしていたのですが、このmakefileをVisual Studioで使うことは可能でしょうか?
つまり、既存のmakefileを用いてVisual Studio上で開発できるかということです。
宜しくお願い致します。

Aベストアンサー

Visual StudioでMakefileを使うにはnmakeを使います。
既存のmakefileというのが何者か分かりませんが、GNU makeやBorland makeなど、Microsoft以外のmakeを対象として書かれたものであれば、当然修正が必要になります。

あるいは、makeツール自体も既存のものを使用し、コンパイラ等を変更することもできます。
いずれにせよ、CC=gccだったところをCC=clのようにツールを変更する必要がありますし、Makefileの書き方次第ではもう少し修正が必要になります。
objcopyやnmなど、コンパイラやリンカ以外のツールに依存したMakefileを使っていた場合には、さらに修正が必要になることでしょう。

Qsed で \ を含む文字列に置換

現在、非常に多数のドキュメントの整形を LaTeXを使って自動的に行っています。
問題となっている処理のエッセンスを抜き出すと次のようなもので、テンプレートファイル中の __PATTERN__ という文字列を、その都度指定する文字列($string)に置換した後にplatexでコンパイルする、という流れです。

----------
#!/bin/bash
sed "s/__PATTERN__/$string/" < template.tex > document.tex
platex document.tex
----------

問題は、$string に '_'(アンダーバー)が含まれるケースで、platexのコンパイルでエラーが発生します。
これを回避するには、'_' を '\_' に置換する必要がありますが、上記処理の前に、$string 中の '_' を '\_' に置換する処理を加えても、上記処理の段階で '\' が消えてしまいます。

肝は sed でのエスケープのやり方だと思うのですが、どうにもうまく行きませんので、お知恵を拝借できればと思います。

なお、tex ファイル中、__PATTERN__ は、他のコマンドの引数内で使用されているため、\verb+ + で囲むという手段も使えません。

現在、非常に多数のドキュメントの整形を LaTeXを使って自動的に行っています。
問題となっている処理のエッセンスを抜き出すと次のようなもので、テンプレートファイル中の __PATTERN__ という文字列を、その都度指定する文字列($string)に置換した後にplatexでコンパイルする、という流れです。

----------
#!/bin/bash
sed "s/__PATTERN__/$string/" < template.tex > document.tex
platex document.tex
----------

問題は、$string に '_'(アンダーバー)が含まれるケースで、platexのコンパイル...続きを読む

Aベストアンサー

""中なら \ は \\ とクォートしないとダメですね.
ちなみに「$string 中の '_' を '\_' に置換する」のはどんな処理ですか?


人気Q&Aランキング