Linuxは、開発環境が40年前と同レベル

Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次 1-新

1(12): 2018/03/10(土) 12:14:37.34 ID:F9RE316x(1/3)調 AAS
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか？しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに（いつの時代（苦笑））。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か１点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。

2(1): 1 [saga] 2018/03/10(土) 12:15:01.91 ID:F9RE316x(2/3)調 AAS
>>1
01. (Makefile.amの作成) # 手作業
02. $ autoscan
03. [configure.scan生成] # 自動
04. $ cp configure.scan configure.ac
05. (configure.acの修正） # 手作業
06. $ aclocal
07. $ automake -a
08. [Makefile.in生成] # 自動
09. $ autoheader
10. [config.h.in生成] # 自動
11. $ autoconf
12. [configure生成] # 自動
13. $ ./configure実行
14. [Makefile生成] # 自動

3: 2018/03/10(土) 12:21:01.63 ID:F9RE316x(3/3)調 AAS
馬鹿だから簡単に各方法を見出せず、ただただ、大量のツールを開発し、
時間をかけ苦労して使っている。そして大量の時間と膨大なHDD容量と、
ネット容量を使いまくって、それしかやる事が無い無能連中がOSS開発で
よってたかって、なんとか表面的には動くバグだらけの使えないツール類を
作りまくって出来上がった集大成が Linuxだ。

4(1): 2018/03/10(土) 12:34:52.53 ID:GhVyQtCz(1)調 AAS
いまだにビルドが遅いんだよな
しかもカーネルをビルドできるだけでドヤ顔できるほどの難易度

コーディング中にリアルタイムでエラーが指摘される時代に何やってんだとは思う

5: 2018/03/10(土) 12:38:23.34 ID:D1qSb8RL(1)調 AAS
ちゃんと動くんならいいじゃないか。
他のOSでは macOS High Sierra はちょい品質が…なのだし。

6: 2018/03/10(土) 14:11:12.74 ID:eQWNUFiP(1)調 AAS
WindowsやiOSやmacOSのビルドは違うとでも思っているのだろうか…

7: 2018/03/10(土) 14:31:03.97 ID:lzdUB3GL(1)調 AAS
LinuxだとVimとそれぞれの言語に応じたデバッガーだな
macOsだと糞Xcode

8: 2018/03/10(土) 17:36:12.21 ID:zCz6mMg3(1)調 AAS
40年前の技術に後れをとる大企業マイクロソフトはどんだけ機能不全なんだよｗ

9: 2018/03/10(土) 19:31:57.68 ID:kO7HFFeK(1)調 AAS
補助ツールのやってることが場当たりの対応でしかないから、
新しく作るものも場当たりの対応に合うように作ることになる切なさがある
そして今は逆に、みんな好き勝手にビルドツールを作る時代になって、それはそれで面倒くさいことに

10(1): 2018/03/10(土) 21:14:20.31 ID:Iz6oQn3Q(1)調 AAS
>>1
> ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
できないんだっけ？

11(1): 2018/03/10(土) 23:08:08.54 ID:Trf+5FyR(1)調 AAS
DOSはコマンドラインの長さ制限が厳しすぎて*のファイル名展開したら
Linuxでcp *.c /xxx/aaaするより限界低そうだけどどうなんだろうな

12: 2018/03/11(日) 01:56:09.27 ID:ceorHAxI(1)調 AAS
久しぶりに同意できる>>1

13(1): 2018/03/11(日) 02:44:26.18 ID:W7wkl3nL(1)調 AAS
CUI で開発できるので、うれしい。
よく知らないGUIのOSだと、モヤモヤする。

14: 2018/03/11(日) 07:43:32.76 ID:7srcRXE1(1/2)調 AAS
>>10
copyじゃなく、xcopyかな。

15: 2018/03/11(日) 08:13:57.73 ID:7srcRXE1(2/2)調 AAS
>>11
DOSのcommand.comはワイルドカードを展開しない仕様だったからコマンドラインの
文字数制限の壁にかからなかった。一方、Linuxは、普段は cp *.c /xxx/aaa で行け
ても全てのファイル名の合計文字数が長くなればその制限に引っかかる。だから
結局、findを使わざるを得なくなることがある。そしてファイル数が多いときにもエラーを
絶対に起こさないためには最初からfindを使わざるを得ないと思う。じゃあなんのために、
bashのワイルドカード展開はあるかって話になるかも。

16: 2018/03/11(日) 10:02:48.60 ID:FS0P3X2Y(1)調 AAS
>>13
知識がついてきてないだけやんｗｗｗｗ

17: 2018/03/11(日) 11:16:41.03 ID:wZ7PAPAy(1)調 AAS
CUIはどこいっても似たようなもんだからな
GUIは文化の壁が厚すぎる
OS違ったら当然のこと、業界によっても常識が変わるからな

18: 2018/03/11(日) 11:31:33.53 ID:1WQdp6Y+(1)調 AAS
ワイルドカードの展開は余計なお世話だと言いたいのかな。それなら抑止するオプションもあるのだが。
「この仕様はどんなメリットがあるの?」とか「DOS のこれは Linux ではどうやるの?」とかなら助けてやれるかもしれないのだが。

19(1): 2018/03/11(日) 12:48:03.51 ID:YsLyPzcd(1)調 AAS
面倒でもあるが細かい所まで手を入れる事できるからまし。vsでビルドで謎エラーとか

20: 2018/03/12(月) 03:16:00.77 ID:ZVV/4ff9(1)調 AAS
cmakeが主流になりつつあるだろ
誰も知らんのか

21(4): 2018/03/13(火) 07:39:51.39 ID:bSKvTeow(1)調 AAS
autotoolsとCMake、正直どっちもつらみがある
CMakeなら.slnファイルも作れるという強みはあるが…

しかし>>1はいろいろと誤認や知識不足がみられるな
PATHに.入れればconfigureで実行できるようになるがセキュアでないので
推奨されない
今時のGUI環境ならPnPでディスクは勝手にマウントされる
wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
一長一短あるだろう

Visual Studioがいい環境なのは認めるよ。VSCodeはその域に達してないし

22(1): 2018/03/13(火) 10:22:06.61 ID:5bGA/MLX(1/6)調 AAS
>>21
>PATHに.入れればconfigureで実行できるようになるがセキュアでないので
>推奨されない

それでバランスしてしまったのがUnix文化の困ったところなんだ。
DOSだと、暗黙のうちに「.」が検索パスに入っていることが前提だからそれを
前提にした文化が形成されたので、その状態でも十分に「セキュア」になった。

その結果、./を付けなくてもカレント・ディレクトリのEXEやBATファイルを実行できる
という超便利な環境となった。ところが、Unixだと古い文化を引きずったまま
直ることが無かったので不便なままとなった。その結果、今後Wineが究極まで
達してもLinuxがWindowsの代わりにはなりえないかも知れない。

23(1): 2018/03/13(火) 10:33:37.76 ID:5bGA/MLX(2/6)調 AAS
>>21
>今時のGUI環境ならPnPでディスクは勝手にマウントされる

Ubuntuだけど、

1. /etc/fstab に光学ドライブを書いておくと、Login前に待機状態になってしまう。
2. Login後、メディアを入れてからNautilusでドライブをクリックすると認識はできる。
3. しかし、メディアを交換したときにトラブルが生じやすい。例えば、Wineだ。
4. HDDですら、Nautilusでドライブをクリックせずに、いきなり端末を使った場合には
　マウントされてない。
5. おまけをいうと、FAT32のような単純なドライブですら、Linuxではext3とはpermissionなど
　で非互換がおきまくって、正しく動作出来ない。たとえば、そのドライブでは、ソースからは
　上手くmakeが出来ず、どこかで不具合が生じてしまう。だから、ext3ドライブにソースを
　全コピーしないといけなくなる。

24(1): 2018/03/13(火) 10:35:32.21 ID:5bGA/MLX(3/6)調 AAS
>>21
>wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
>一長一短あるだろう

現実に良く使うコマンドがとても長くなってしまっているのだから、結果的にはLinuxの
方が使いにくい。

25: 2018/03/13(火) 10:52:01.11 ID:5bGA/MLX(4/6)調 AAS
>>21
>Visual Studioがいい環境なのは認めるよ。

この書き方だと、プログラムの経験が浅い人にはVisual Studio だけが例外的に
「いい環境」なだけだと思われてしまう。

ところが、実際にはそうではなく、TurboC++, WatcomC++なども、十分に便利だった。
コマンドラインでも、gccやgnu make などとくらべて、だいぶ便利だったんだ。

はっきりいえば、gccやmakeやLinux文化は洗練されておらず、頭が悪いんだ。

26(1): 2018/03/13(火) 11:51:15.98 ID:wIVMmkuq(1)調 AAS
Emacsだけ有ればいいさ！

27(1): 2018/03/13(火) 12:29:55.64 ID:9i5woyma(1)調 AAS
makeは特別に良いとは言わないけど別に悪くもない
それより最近は言語に特化したビルドツールが多いから色々覚えなきゃいけないのが面倒

28: 2018/03/13(火) 12:45:35.08 ID:5bGA/MLX(5/6)調 AAS
>>27
基本的には、make自身の問題よりも書き方やそれ以外の変なツールが標準になっていることの問題
が大きい。しかし、gnu toolsは、余計なメッセージだけを消す事が出来ないことが多いのが
クソなんだ。消そうと思うと全てのメッセージが消えたりして、使い物にならない。turbo c++
や watcom c++ , msc++, vc++のツール類は、どれもそんな初歩的な不具合は無かった。

29: 2018/03/13(火) 12:55:37.69 ID:IE+orhWI(1)調 AAS
すごいな。いろんな意味で。現状に不満があるのは理解できたけど、不満を解消するために何をしたの?

30: 2018/03/13(火) 13:08:58.30 ID:5bGA/MLX(6/6)調 AAS
それが責任者不在の問題点。こっちは部外者なのに責任を負わそうとする。

31: 2018/03/13(火) 23:35:22.57 ID:WPjn7ohc(1)調 AAS
昔は、好きでやってる開発者に世界中のユーザーが支援して品質を高めていくオープンソースやフリーソフトに、
仕事で嫌々やってる商用ソフトがかなうわけないと思ってたけど、そうでもなかったな。
やっぱり仕事で真剣にやってる人たちにはかなわないんだな。

32: 2018/03/14(水) 05:31:25.15 ID:4nEasH7v(1)調 AAS
jetbrainsのIDE使っとけば

33: 2018/03/14(水) 07:17:28.33 ID:HRaHWJ8k(1/2)調 AAS
TURBO Cのコマンドラインは使ったことないな。IDEは便利だったけど。
ただ当時のレベルだったらemacsのmake+ctags環境も十分匹敵する
レベルだったと思うが。あの頃にリファクタリング機能とかなかっただろう。

jetbeansの名前も出てるけど、Eclipse, Anjuta, KDevelopみたいな
IDEもある中でそういうのを出して比較しないのはちょっとフェアじゃ
ないんじゃないか。
まあそれらと比較してもIntelliSenseに及ばないんだけど。

34(2): 2018/03/14(水) 07:43:43.32 ID:HRaHWJ8k(2/2)調 AAS
>>22 出自が1マシンを複数ユーザーで使うことが前提の環境だったので
悪意あるユーザーの想定が必要だった。というかWindosが今の状態で
十分セキュアとは思えないんだけど。悪意あるユーザに勝手にファイル
置かれて実行されるリスクは下がっちゃいないのでは。

>>23 fstabを書いた例と書かない例を混ぜて文句いうのはちょっと感心しない。
FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
にマッチしないのでそりゃしょうがないよとしかいえない。
全コピーしなくてもloopback filesystem置く手段はある。Windowsでも
似たようなこと(vhdファイル作ってマウント)しないとFAT32領域に
まともにアプリがインストールできない事態起きるし。

>>24 そこはもう慣れの問題で自分は「クソ、勝手に処理しやがって」と
思うことの方が多いし味方の別れるところだと思う。個人的にはそんなに
頻繁に使うならエイリアスかスクリプトにでもしたら、と思う。

35: 2018/03/14(水) 08:42:41.08 ID:4J3TJdzv(1/9)調 AAS
>>34
>全コピーしなくてもloopback filesystem置く手段はある。

こういうのを聞いて、イザやってみても別のところで不具合が起きて時間の無駄になった
経験が沢山ある。

36(1): 2018/03/14(水) 09:11:53.42 ID:4J3TJdzv(2/9)調 AAS
>>34
>FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
>にマッチしないのでそりゃしょうがないよとしかいえない。

数学的にはFAT32であってもext3の模倣もする事が出来る。
あなたは数学は苦手ですか？　苦手なら、数学とプログラムと
UnixとWindowsとExt3とFAT32の全てに詳しい者に聞いてみるといい。

自分にはそれをするための方法が頭の中で分かる。そういうツールや
ドライバが既にあるという意味ではない。作ろうと思えば作れるという
意味。そして、自分にはその義務はない。

37(1): 2018/03/14(水) 16:11:19.24 ID:B9yzXWAU(1/2)調 AAS
なんでコンパイラと統合環境比べてるの？
統合環境でVSが良いのは認めるけどLinuxだってEclipseやJetbrainはあるし

38: 2018/03/14(水) 16:13:41.16 ID:B9yzXWAU(2/2)調 AAS
WindowsってただVSが良いというだけじゃん
未だにまともなパッケージ管理もないしシェルは使えないし開発する環境としては最悪だよ

39: 2018/03/14(水) 16:32:54.53 ID:q4XJOHSe(1)調 AAS
VisualStudioが便利な言語って限られるし
開発環境全般で言えばWindowsだけじゃ不足なのでWSLが持て囃されたりしてるし
万能なものはないからいいとこ取りで使っていればいいだけだ

40(1): 2018/03/14(水) 16:48:10.54 ID:80z85C3j(1)調 AAS
MS-DOS を使っていた時代は、UNIX を使っている人たちが羨ましくて仕方なかったな。本当に何から何まで羨ましかった。
だから、Linux よりも DOS がいいというのはなかなか興味深い見解だと思ったのだが……どうやらお呼びじゃなさそうだ。

41: 2018/03/14(水) 16:55:34.82 ID:4J3TJdzv(3/9)調 AAS
>>40
そりゃ、DOSはLinuxのサブセットみたいに普通思い勝ち。でも実際はむしろMSが
進化させたんじゃないかと、今では思ってる。実際MS製Unixは売れずにDOS
だけが売れたし。

42: 2018/03/14(水) 17:03:07.07 ID:4J3TJdzv(4/9)調 AAS
>>37
コマンドライン・コンパイラを比較してもやはり、TurboC++, WatcomC++などとくらべて
gnu tools は使いにくいと思ってるし、上でもそう書いてる。

43(1): 2018/03/14(水) 17:22:38.91 ID:Ot1p/P4U(1/2)調 AAS
使いこなせないだけだろｗ

44(1): 2018/03/14(水) 17:22:39.04 ID:KnbtLvIZ(1)調 AAS
autotoolsはマルチプラットフォームを前提としたものだからTurboとかとは目的が違う
別のOSでも同様の手順でいいという使い勝手はTurboCとかじゃ実現できないわけで結局使い易いとかは主観でしかないしどれだけ自分に都合が良いかというだけのこと

45: 2018/03/14(水) 17:26:17.11 ID:4J3TJdzv(5/9)調 AAS
>>43
色々な嘘によって、ミュンヘン市は損害を追ったのに、Linuxサイドは「技術的な問題じゃない」
という一点張り。スラドではこの態度に対し、「なんと言う言い訳」と言われてた。

46(1): 2018/03/14(水) 17:26:44.28 ID:Ot1p/P4U(2/2)調 AAS
使いやすいとか使いにくいは慣れの問題だし
最初に手をそめた環境がその人の一生の好みを決めるところがある
自分の好みを言っても主観以外のなにものでもない

47: 2018/03/14(水) 17:30:09.61 ID:4J3TJdzv(6/9)調 AAS
>>46
LibreOfficeの開発者もそんな事言ってた・・・。

48: 2018/03/14(水) 17:58:02.77 ID:4J3TJdzv(7/9)調 AAS
欧米流は、言い訳が多いな。

49: 2018/03/14(水) 18:31:54.74 ID:4J3TJdzv(8/9)調 AAS
>>44
ただ、そんなことしなくても(30年前に比べれば)言語やOSで色々と統一化や
標準化もあったりしたせいか、それらのツールのやり方が本末転倒で意味不明
な存在になってり。

今は、そもそも出来ない場合にはそんなツール使っても出来ないし、出来る
場合には使わなくても出来る。存在意義がどれくらい果たしてあるのか。

50(1): 2018/03/14(水) 18:51:47.32 ID:rvms1pqi(1/2)調 AAS
出来るかどうかってのは使う人間の能力によるところが大きいから出来なかったとしても仕方がない

51: 2018/03/14(水) 18:57:43.24 ID:4J3TJdzv(9/9)調 AAS
>>50
今は、「マルチプラットフォーム」での非互換部分を自動的に修正してくれるかどうかの話
やで。

52: 2018/03/14(水) 19:32:56.84 ID:rvms1pqi(2/2)調 AAS
そのソフトウェアがそのOSに対応してるのなら自動的に追従するようになってるだろ
想定されたOSでそれが出来ないということなら問題は人間側に(以下略

53(1): 2018/03/14(水) 23:56:01.59 ID:qC2L6BuB(1)調 AAS
スレタイだけでの反応なんだけれど、
16年前に書いたソース群を、今日makeする事ができた。

これ、本当に凄い事だと思う。1回覚えた事や環境がずっと使えるって幸せ。

54: 2018/03/15(木) 00:25:00.60 ID:cRQ+JQN/(1)調 AAS
>>1 読むと、autoconfは確かに面倒なの同意。
良書がなかったしね。訳本も酷かった。本当に酷かった。

そもそもポータビリティに気を付けてソースを書きなさい。
後は、色んな環境でもmakeできるようにしてあげるよって思想だった記憶。

お陰でvine2.1.5時代に作った物が今でもmakeできた。
ただ、思い出して修正できるまでに10日かかった。
当時も日本人開発のソフトには導入が不完全で、バグレポート送ったりしてたわ。

55: 2018/03/15(木) 10:44:40.56 ID:lnWZyj3L(1/14)調 AAS
えっ!?

外部ﾘﾝｸ[html]:www.jaist.ac.jp

>autoconf/automakeのバージョンを少し上げただけで、それまでに作成した
>configure.inに対してautoconf/automakeを実行するとエラーや警告を生じる
>ようになる場合が多々あります。むやみに最新バージョンをインストールし
>ないほうがよいようです。

>以降の記述でも、autoconf/automakeのバージョンによってはエラーや警告
>が発生する場合があります。

56(1): 2018/03/15(木) 10:52:04.96 ID:lnWZyj3L(2/14)調 AAS
どっちの関数があるかないかによって、自分のコードにこんなの書かされる。
片方の環境しかなければ、もう片方のテストはしないってことだよね。

#ifdef HAVE_GETCWD
　　getcwd(pathname, sizeof(pathname));
#else
#　 ifdef HAVE_GETWD
　　getwd(pathname);
#　 endif
#endif

このようなコードを何回も書くのは駄目コードだ。なぜなら、1文字でも間違って
いればバグるのに、テストも出来ないから。

57(3): 2018/03/15(木) 11:03:36.94 ID:lnWZyj3L(3/14)調 AAS
例えば、マクロ名を間違って、

#ifdef HAVE_GETCVD
#ifdef _HAVE_GETCWD
#ifdef HAVE_GET_CWD
#ifdef HAVE_GTECWD
#ifdef HAVE_GETCW

などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、
頭の良さや経験や能力に関わらず、誰にでも起こりうる（なのに、エラーになら
ない。）。

また、それとは別に、例えば、その環境では
getcwd(pathname, sizeof(pathname));
の部分をコンパイラがパースすらしない場合、

getcwd(pathname. sizeof(pathname));
getcwd(pathname, sizeof(pathname)):
getcwd(pathname, sizoef(pathname)):
getcwd(pathname, sizeof(pathnmae));

などの書き間違いがあったらどうなるか。
, . ; : の間違いがあるが良く見ないと分からない。
これならまだコンパイル・エラーになるだけなので
まだ良くて、一度もテストしないなら、コンパイルは通るのに、
実行段階で結果だけがおかしくなることもありうる。その場合は
もっとたちが悪い。

58(1): 2018/03/15(木) 14:29:04.87 ID:LTp8xgxY(1/9)調 AAS
それはCプリプロセッサの問題だろ

59(1): 2018/03/15(木) 14:49:32.28 ID:lnWZyj3L(4/14)調 AAS
>>58
頭の言いプログラマなら、別の方法を探す。
馬鹿だからその「解」が見つからない。

60(1): 2018/03/15(木) 14:57:50.65 ID:LTp8xgxY(2/9)調 AAS
>>59
プリプロセッサに代わる頭の良いやり方を是非開発して

61: 2018/03/15(木) 15:07:39.22 ID:lnWZyj3L(5/14)調 AAS
>>60
1つの方法としては、新規に共通(互換)ライブラリを作れば良い。

上の例だと最も単純には、

1. getcwd(pathname, sizeof(pathname));
2. getwd(pathname);

の「1」の方はアプリ・プログラムでは使わずに、必ず2を使うようにする。
そして2が存在しない環境向けには、

xxx getwd(zzz *pathname) // zzz は恐らく char
{
　・・
　aaa = getcwd(pathname, 最大パス文字数);
　・・・
}

のような感じのライブラリ関数を提供してしまう。こうしてしまえば、
autotool なんてアプリをビルドする際には全く使わなくて良くなる。
長いパス名が使える環境向けには、「最大パス文字数」を動的に可変に
する方法も有り得る。そうするには工夫が必要だが不可能なことではない。

62(1): 2018/03/15(木) 15:18:54.99 ID:LTp8xgxY(3/9)調 AAS
そのやり方は無造作にやるとシンボル名が衝突してコンパイルやリンクエラーになりますが
動作の切り分けはどうやってするのですか？

63(1): 2018/03/15(木) 15:25:01.52 ID:lnWZyj3L(6/14)調 AAS
>>62
シンボル名の「衝突」と言っても色々な場合があり、一概には言えないが、
新しい共通ライブラリ関数は、例えば
cmn_getwd()
のように先頭に「cmn_」を付けてしまって、アプリは、「cmn_xxx」の
方だけを使うようにすれば、衝突の心配が１つ消える。

64(1): 2018/03/15(木) 15:36:11.68 ID:LTp8xgxY(4/9)調 AAS
>>63
名前変更した共通ライブラリをビルドするときはどう回避するの？

65(3): 2018/03/15(木) 16:15:21.72 ID:lnWZyj3L(7/14)調 AAS
>>64

それは色々なやり方があるが、2つだけ書いておく:
1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。
2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを
　マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。

どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
>>56-57 のような危険が生じる可能性を限りなく0に近づけられる。

66(1): 2018/03/15(木) 16:34:03.34 ID:LTp8xgxY(5/9)調 AAS
>>65
本質的にプリプロセッサの問題を解決しておらず
欠陥品を頑張ってなんとかするというのは頭の良い解決策とは
余り言わないと思いますが。

67(1): 2018/03/15(木) 16:37:22.78 ID:lnWZyj3L(8/14)調 AAS
>>66
だったら、プリプロセッサを改良すれば良いよ。

68(2): 2018/03/15(木) 16:53:31.36 ID:LTp8xgxY(6/9)調 AAS
>>67
具体的に改良点も挙げずに言われても無意味ですし
プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？

69: 2018/03/15(木) 17:00:13.27 ID:lnWZyj3L(9/14)調 AAS
>>68
>プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？

いや、それだけだと「>>57」の前半の問題は解決するが、後半の問題は残る。

>>65の方法を使えば、両方の問題を解決できる。モジュール別テストは強力だから。

70: 2018/03/15(木) 17:04:19.91 ID:lnWZyj3L(10/14)調 AAS
>>68
>具体的に改良点も挙げずに言われても無意味ですし

>>57の前半の問題を根本的に解決したければ、gccの前処理(プリプロセス)部分
に独自の前処理指令を追加すれば良い。

ただ、そこまでしなくても、>>65の方法のようにすれば、モジュール別テストの効果で
非常に安定なプログラムを作り得る。

71(1): 2018/03/15(木) 17:11:21.49 ID:LTp8xgxY(7/9)調 AAS
共通ライブラリのビルド時にシンボル名の衝突回避をプラットフォーム毎に判別する
方法が具体的に何も提示されてないのですが。

72(1): 2018/03/15(木) 17:20:34.61 ID:lnWZyj3L(11/14)調 AAS
>>71
一応、何度も「衝突回避」と書いてあるけど、「関数が定義されているか
どうかによる場合分け」みたいなことだよね。

その部分だけは、何らかのツールを使えばよい。最も単純な物でよければ、シェル
スクリプトでもいける。コンパイラ処理系によって違ってくるが、使うライブラリ
全てについて、ライブラリアンやリンカなどでexport symbolの一覧を出して、
関数名(シンボル名)が出力されるかを調べれば良い。それは、
librarian -list_exports xxx.lib | grep シンボル名
が1文字以上の何かを出力すれば真、何も出力しなければ偽、という
様な論理で良い。それをシェルスクリプトに書けば良い。

73: 2018/03/15(木) 17:23:35.45 ID:lnWZyj3L(12/14)調 AAS
スマンが、用事があるのでしばらく抜ける。

74(1): 2018/03/15(木) 17:34:21.87 ID:LTp8xgxY(8/9)調 AAS
>>72
判定結果をどうやってソースコードに反映させるのですか？

あなたが今提案したようなことをautoconfがやっているということは
目をつむっておきますが。

75: 2018/03/15(木) 17:36:26.04 ID:LTp8xgxY(9/9)調 AAS
というか既存のビルドシステムや共通ライブラリの実装に精通してないどころか
Cでまともにプログラム書いた経験があるように見えないのですがね。

76: 2018/03/15(木) 17:37:50.07 ID:lnWZyj3L(13/14)調 AAS
いや、実際に上司などからも、滅多にいない最高レベルのプログラマだと評されていたの
でそれはない。

77: 2018/03/15(木) 17:38:50.81 ID:lnWZyj3L(14/14)調 AAS
さらにいえば、昔から神童だと言われてきた。

78: 2018/03/15(木) 20:09:28.05 ID:ewca0ZvD(1/2)調 AAS
っていうか、ビル・ゲイツが今時のできるプログラマは間違いなくMacを使ってるとか
言ってたけど、俺はMac使ってないからよく知らないけど、Ubuntuなら何でもパッケージ揃ってるじゃん・・ｗ

Macもネットとか見て大体想像つくけど、Ubuntuの方が上だろ・・？

Windowsの時の糞めんどくせえ環境変数の設定とか全然しなくていいからUbuntu大好き

79: 2018/03/15(木) 20:12:16.29 ID:ewca0ZvD(2/2)調 AAS
Windows９８の頃なんて、VC買ってやってみたけど、インテリセンスの出てくるのが糞遅くて
ﾜﾛﾀよｗ　Javaも最初のAutoexec.batにパス記載するのも、順番違うとコンパイルや実行できねえし・・ｗ

今のWindowsは良くしらんけども。

80: 2018/03/15(木) 20:49:16.98 ID:9s2u5/Ot(1)調 AAS
ゲイツそんなこと言ったの？

81: 2018/03/15(木) 21:50:42.20 ID:7HZLjuXm(1)調 AAS
>>36
その昔umsdosってのがあってだな…実際ext2っぽいメタデータをVFAみたいに
VOLに詰め込む実装もあったんだよ。もうメンテされてないけど。
むしろ現代では逆にf2fsなんていうものでFATを模倣するような挙動を
androidでやってる。

82: 2018/03/23(金) 00:19:12.64 ID:uVffKzsn(1)調 AAS
1がアホなのはわかったｗ
昔は文字数制限がシビアでそれに引っかかった時に対処するのに四苦八苦してfindだとかいろいろ組み合わせただけだぞ

83: 2018/03/23(金) 14:04:49.90 ID:UeEv/zvW(1)調 AAS
便利さと安全さは交換条件

84: 2018/04/01(日) 19:08:05.21 ID:yxrC+deI(1/3)調 AAS
WebAssembly を試そうと、Ubuntu に emscription をインストールしようとしたら、
64bit OS用にしか precompiled 版がない。

どこが開発者に使いやすいものか。

85: 2018/04/01(日) 19:13:15.86 ID:yxrC+deI(2/3)調 AAS
ソースからインストールしようとすると、clangまでソースからビルドさせようとしやがる。
500MB位DLを強要されそうになった。

もっとも、バイト数も表示されないので、推定だが。このバイト数も表示されない、というのも
LinuxのCLIパッケージ・マネージャーによくある問題点だ。Windowsだと、zipファイルのDL
サイズは速い段階で分かるが、Linuxだとスクリプトによっては最後まで分からないことが
ある。今回も「その分からないタイプの」スクリプトだった。

アメリカは高速回線でどうでも良いのかも知れんが、こっちはたまったもんじゃない。

86: 2018/04/01(日) 19:17:23.33 ID:yxrC+deI(3/3)調 AAS
単に zip ファイルにまとめてしまえばいいだけなのに、何のために
apt-get や apt があるのかも分からない。

アホですか。

87: 2018/04/02(月) 05:24:14.30 ID:06ieJ5Hu(1)調 AAS
開発者なら普通は64bitOS使ってるからな

88: 2018/04/02(月) 08:51:24.65 ID:6FMJWj1c(1/4)調 AAS
そういうのがウザイ

89: 2018/04/02(月) 13:36:16.49 ID:6FMJWj1c(2/4)調 AAS
しょうがないのでWin7でやったら、上手くいった。
せっかくLinuxでやろうと思ったのに。
いつもこんな感じになっちまう。残念。。。

90(1): 2018/04/02(月) 17:35:08.84 ID:O58OwMyS(1)調 AAS
自称神童のアホですかおじさんは Linux では幸せになれないと思うよ。Linux のことなど忘れなさい。

91: 2018/04/02(月) 18:03:24.62 ID:6FMJWj1c(3/4)調 AAS
ちゅうか、この調子だと数十年たってもLinuxへの移行は進まなさそう。
GoogleのChromeOSや、デスクトップ用のなんとかOSがなんとかしてくる
かも知れんが。

92: 2018/04/02(月) 18:05:51.44 ID:6FMJWj1c(4/4)調 AAS
>>90
そうやって、色々な人が離れて行くんだろうよ、今までも、これからも。
というか、もはやボランティアの力だけではどうにもならん気もする、
DesktopでのLinuxは。やはりGoogleか。

93: 2018/04/02(月) 23:56:25.09 ID:6vflFCoS(1)調 AAS
いつまで32bitなんて使ってんだ

94: 2018/04/03(火) 00:45:33.28 ID:ulFIPWeY(1/2)調 AAS
Linuxまで最新OSの真似するなんてなんと生意気な。
自分たちの立ち位置が認識できてない。何一つマトモニなものが
ないというのに。

95: 2018/04/03(火) 07:45:59.33 ID:OGhwyKh3(1)調 AAS
初心者がLinuxとストレスフリーで生きる為の6か条

1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。

96(1): 2018/04/03(火) 12:04:03.80 ID:udUPvT8n(1)調 AAS
Emacsが死んでVimが生き残るとは訳のわからん世界だな
どっちも死んで環境刷新すりゃいいのに

97: 2018/04/03(火) 12:25:04.63 ID:ulFIPWeY(2/2)調 AAS
どっかの教育機関が、学生に紹介して洗脳したんじゃない。
初めて触ったエディタがvimになっちゃって。Macとかも東大が洗脳してる。
酷いもんだ。

98: 2018/04/07(土) 14:29:26.83 ID:qYZmw88H(1)調 AAS
いまどきコマンド形式のエディタなんて効率の悪いものにしがみつかなきゃならんのはLinuxぐらいだからなぁ。

99: 2018/04/07(土) 14:58:29.55 ID:dbBuTpv8(1)調 AAS
最近はエディタはnanoが推奨されてねか？

100: 2018/04/07(土) 15:05:52.91 ID:AohAt9rK(1)調 AAS
これめっちゃ使いやすいよ

Download Visual Studio Code - Mac, Linux, Windows
外部ﾘﾝｸ:code.visualstudio.com

犬厨が棍棒持って恐竜追い回している間に
MSはロケット打ち上げて火星までいっちゃった感じ

101(1): 2018/04/07(土) 15:19:08.77 ID:XvhqN9Xa(1)調 AAS
Eclipse使えばいいんじゃね？

102(1): 2018/04/07(土) 16:21:57.33 ID:cZQNkxoC(1)調 AAS
>>101
前、使ってみたら、拡張のための機能ばかり豊富だけど、それも非常に複雑で
「簡単なことを複雑にする」タイプの設計だと思った。IDEとしても使いやすくも
なかった印象がある。

103: 2018/04/07(土) 19:47:59.97 ID:VBVicRXH(1)調 AAS
>>102
それな

Eclipseを改造して○○専用Eclispeみたいなのが量産されていて、
プラグインを入れることでいろんなことに対応できるEclipseじゃなくて
いろんなEclipseを作ることができる、Eclipseツクールみたいになってて
一体いくつのEclispeをインストールするのか？って思った

104: 2018/04/07(土) 22:29:50.63 ID:PDWsMgYq(1)調 AAS
Eclipseはintelijの登場で不要になったわ

105: 2018/04/08(日) 09:37:14.48 ID:NSGlAg2d(1)調 AAS
Eclipseも出てきたころは、絶賛されまくっていたが、自分で確認した人が少
なかった。それで各自で試してみたところ、言われている評価とは違っていた。
intelij も同じ道をたどるのではないか。

106: 2018/04/08(日) 13:05:41.51 ID:C9rknhmI(1)調 AAS
intelijはAndroid stidioとしても使われまくってるけどな

107(3): 2018/04/08(日) 23:52:00.34 ID:sClxzhQ7(1)調 AAS
人間も生殖の仕方が何千年前からたいして変わっていないのは問題ではないのか？

108: 2018/04/09(月) 02:13:52.08 ID:gFHj50SU(1)調 AAS
>>107
オナニーの仕方なら相当進化したで？
A10ピストンSA、4万高いなぁ、どうしようかなぁ

109: 2018/04/09(月) 12:23:51.28 ID:lQNORnVU(1)調 AAS
俺はネコビーン派。
テキストエディタの代わりにも使うぐらい。

起動おそくて立ち上げっぱなしだからってのもあるけど

110: 2018/04/10(火) 07:09:40.75 ID:1wqTAI+L(1)調 AAS
今のLinuxのメインユーザーは開発どころか何も作り出さずしょーもないSNS眺めてるスマホ層だからな
開発環境なんていらんだろ

111: 2018/04/11(水) 03:07:04.95 ID:3QuUYrNO(1)調 AAS
AGK無料試用版の配布開始(リンク先にWindows､Mac､Linux版のファイルが直接置いてある)

AppGameKit - Free Trial Version
外部ﾘﾝｸ:www.appgamekit.com

無料試用版

AppGameKit無料トライアル版は､AppGameKitの主要な領域すべてにアクセスできるため､
完全に評価することができます｡完全版の有料版には､次の主要機能が含まれています｡

･ Android､iOS､HTML5にプロジェクトをエクスポートする
･アプリをデバイスに直接ブロードキャストする
･コンパイルされたプロジェクトからウォーターマークを削除する

112: 2018/04/11(水) 13:04:19.44 ID:HpqZ8pY3(1)調 AAS
>>96
洗脳したわけじゃなくて、作業性を追求したら自ずとvimになるんじゃないの？

113: 2018/04/11(水) 14:23:25.06 ID:aOnEqqDb(1)調 AAS
viが使える環境が多い ⇔ viは使えるようにした方がいいという奴が多い
この相乗効果でemacsと差が付いた

114: 2018/04/11(水) 20:40:59.23 ID:xsCFqumz(1)調 AAS
Linuxはたいていviコマンドがあるから最低限の使い方は知ってた方が良いのは確か。
でもvi(vim)はメインで使うべきものじゃ無い。
文字を書き捨てるだけなら良いけど、所詮はラインエディタだ。

115: 2018/04/11(水) 23:26:48.52 ID:RrerSgT4(1)調 AAS
Windows でも GVIM 使ってる。
もちろん、IDE があればそのエディタ使ってるけど。

116(1): 2018/04/12(木) 15:09:59.47 ID:65pf/D0+(1)調 AAS
エディタは、多くの人は、本格的なプログラミングのために使ってるわけではなく、
設定ファイルやスクリプトファイルの簡単な修正程度に使っているのかもしれない。
だから、使用者の数で言えばvimが多くても、ちゃんとしたプログラムに使ってい
るとは限らない。

上下前次 1-新書関写板覧索設栞歴

あと 703 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.053s