D言語 Part34©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
互換性維持しない方向で成長するのは別に構わんけど
過去のリポジトリ消される(ライブラリ含めて)のはめっちゃ困る罠 こういうことがあるからあんまり流行らないんだろうなぁと思う うーん・・
dub buildで急にエラーが出て何もできなくなった。
ソースとかまるで関係なく、どんなプロジェクトでも同じ文言を吐き出す
ようになったのだが、、
dub build
Error executing command build: Failed to invoke the compiler dmd to determine the build platform: {
"compiler": "dmd",
"frontendVersion": 2066,
"compilerVendor": "Digital Mars D",
"platform": [
"linux",
"posix"
],
"architecture": [
"x86_64"
],
}
Error: Error writing file '/tmp/dub_platform_probe.o'
dub_platform_probe.d見ても原因がさっぱり分からない助けてくれ。 Dの破壊的変更はもっとマシになるべきだが対策することが出来る
だが半生ライブラリはダメだ 滅ぶべき
パッケージシステムは道を誤りし背教者どもの墓標 >>60
え、そっちもGitレポジトリでしょ? 過去の状態のを使えばいいのでは
(内容も変わってるかもしれないし) >>61
dubレポジトリは個人がボランティアで運営してるっぽいから仕方ない
あそこはGithubからミラーしてるだけだから、どうしても古いバージョンが入手できないということはないしね
2015年前半に、D言語の宣伝・普及のための団体を作るとかいう計画を立ててるらしいけど
それ以前にこういうボランティア任せの部分をちゃんとしたサービスとして運営できる組織を作って欲しいなぁ 永遠の17歳でいればずっと輝いていられる
そんなD言語 Swiftのポジジョンに収まっていれば安泰（？）だったかもなぁ 必要なのは D言語の入門・解説ではなく D言語とのつきあい方のガイドである >>70
たしかにそうかも
自称ですら「2番めに学ぶ言語としていいよ！」とか言ってるし 1番目に学ぶべきはCかJavaかC#
2番目に学ぶべきはCかJavaかC#のまだやってないの
3番目に学ぶべきはJavaScriptかPythonかRuby 実際の状況を考えると、CとJavaとC#が選択肢に並ぶ場面ってそうそう無いよな >>73
ありゃ相当古い記述なのであまり真に受けない方がいい
今は割と初心者向けのリソースがあるし(英語が読めない人間には無いも当然だけど) D言語はまだ英語無しで学べる言語じゃない
まあレファレンス読むよりソース読んだ方が手っ取り早いかもしれないけど
（でもソースがレファレンスの代わりになるってunittestのおかげだよね） お前らが「最近のD言語は安定しててつまらない」って言い始めたら本気出す 本当に安定しててつまらないよ、細々とした調整ばかり
今年はDIP69含めて大幅な変更に期待 RoRみたいなキラーフレームワークの登場が最優先だろ
変更ばっかじゃいつまでたっても出てこねえんだよお まさにRubyも仕様変更の多い言語なわけだし、あまり関係なさそう
キラーなんたらが出る以前に、それなりに人気が無いと始まらん RubyやPythonと違ってネイティブ吐けるところがメリットだけど
Pythonで間に合ってます PythonとDの両方が、同時に選択肢に入ってくる状況なんてあまり無さそうだがな >>81
ライブラリが充実して実用的に使えるバージョンがない
複数組み合わせて使うとたちまち破綻する
比べる土俵が間違ってる バージョンが変わって動かないなら自分で直せばいいじゃない 他の言語に比べて、D言語でしかできない or ものすごくやりやすい ことってなによ？ 自分がそうだけど継ぎはぎだらけのC++の汚さに絶望した人がやってるんだと思う
スマートなコーディングができるのにアセンブリコードが出力されるから
Javaやスクリプト系のように速度で妥協することもない C++で同じことできるって言われても意味ないんだよねえ。
単なる見せかけの機能だけに釣られてる奴はC++やってた方がいい。 ちょっと理解できてないのかな
C++よりスマートなコーディングができることに魅力を感じてるって話なんだけど >>87 >>89
たとえば？
C++ も 11, 14 で多少はマシになったと思うんだけど、
どの辺りが問題で、D言語ならどういうふうにスマートに書けるんだろう？ >ライブラリが充実して実用的に使えるバージョンがない
? テンプレート絡みだけでかなり差別化できてるんじゃね
あと今更イテレータとか触りたくないよね C++の偉い人もタイムマシン手に入れたら何したいって聞かれて
C++のテンプレート周りの構文をD言語風にしたいって言ってたな D言語は気持ちよくプログラミングできるんだ
俺にとってのD使う理由はそれで十分 C++は気持ち悪いからな
関数ポインタとデリゲードが別物であった時点で俺の中では終わった。 >>97
C++で統一できるなら、std::function<...> で統一すれば済む問題だろ？
DのデリゲードはCの関数ポインタに変換できるのか？ 既存のC製ライブラリを使うときはどうするんだ？ >DのデリゲートはCの関数ポインタに変換できるのか？
Dにも普通の関数ポインタがあるので、そちらを使う
まあデリゲートでも(cast(void function())dg.funcptr)とか出来る、もちろんキャプチャした変数は使えなくなるけど 訂正:dg.funcptrは既に関数ポインタなのでキャストは不要
当たり前だな、何を勘違いしてたんだろう キャプチャなんてもんがある辞典でC++は消滅すべき >>100
C++もキャプチャ変数が無ければC関数ポインタとして渡せるから、似たようなものだね。
つまり >>97 は単に無知だったということだな。
>>102 も言葉通りだとナンセンスだが、「キャプチャ変数を明示する必要がある」という意味なら一理ある。 キャプチャ自体はなるほど、と思ったけど
キャプチャ周りの書式はもうちょっとどうにかならんかったかなと思う
初見のときはあまりの違和感に頭がしばらくぐよんぐよんした https://issues.dlang.org/show_bug.cgi?id=14213
S氏のバグ報告、これってProxyにtoHash付いたのが原因か
getHash(cast(const void*)a)としてるけど、delegateをconst void*にキャストするのがdeprecatedになった constなdelegateとかにいまだに違和感がある 2.067ﾏﾀﾞｧ-? （･∀･ ）っ/凵⌒☆ﾁﾝﾁﾝ まだ RC も出てないよ
後1,2回ベータが出てからその後のはず vibe.dの問題が解決できるまで2.067のリリースを遅らせるようだ D言語わくわく
http://next 2ch.net/tech/1425486862
↑
ﾂﾒﾙ フォーラム見てるとWalterとAndreiに対してヘイトが溜まるなぁ
なんだこいつら 別に横暴って訳じゃないけど、なんか他人を見下してる風なんだよな
自分たちと違う意見を持つ人間ってだけで馬鹿にするような返答や皮肉を繰り返してた時はちょっと引いた
特にWalterは何かにつけて「30年間プログラマをやってきた経験」とやらで他人の意見を蹴ったり、一方で都合が悪くなると返事しないので腹立つ >自分たちと違う意見を持つ人間ってだけで馬鹿にするような返答や皮肉を繰り返してた時はちょっと引いた
あるある
こういう態度からは何も生まれない FacebookがD言語を開発してるみたいな誤解を与えられたの、AAの目論見通りなのかな
実際はちょいと金貰っただけだし、業務ではほぼ使われてないとAAも言ってたし 以前ここで見た気がするけど
dmd2.067(win32)でも、windows8.1 64bitで
以下が落ちる
---
size_t count;
scope(failure) count.writeln;
foreach (_; 0 .. 100) {
count++;
new byte[100_000_000];
}
---
13
core.exception.OutOfMemoryError@(0) GC「それはな…ちゃうねん」
なんかGC作動オプションつけられるようになったっぽいから色々試してみたけど
どうやっても落ちるのな PreciseGC にならないとダメ
非アドレスをはじけないから
デカいブロックを使用中と誤認したり無駄なスキャンも防げない
自前で malloc/free するか Win64使うか でかいJPEGファイルをロードしたくらいで引っかかる上に
外部ライブラリを使ってるから回避できなくてとても困る
やはり時代は@nogcか… いい加減、64bit環境を構築するかー
さんくす！
一応 delete で、不要と教えてあげれば落ちないけど
GCの意味ないなあとか思っていじってました
GC「要らないならいうてやー」 10-20MB以上のデカいブロックだけmalloc/freeするのがいい
GCに預けたやつを中途半端に手出しするのもあんまり GCの方がトータルで速いと主張してたのはなんだったんや・・・
つか、GC無しが有り環境に移行するのはまだしも、有りだったのが無しに移行するのって辛いよな D言語からC言語のヘッダファイルを読み込むにはどうしたらよいですか？
具体的にはwindows.hとかを読み込みたいです。
DirectXとかも使いたいのでC++用のCOMのヘッダも読み込みたいです。
D言語はライブラリが少ないし、
マイナー言語なので、ライブラリ提供者から公式なサポートが無いです。
そのため、C/C++用のライブラリをそのまま流用して使いたいです。
ヘッダファイルには、C/C++用のマクロなども定義してあるので、
D言語はC/C++の全機能をサポートする必要があります。
このために、DとC/C++を切り替えるスイッチが必要で、( 例えば extern C++{ } )
私が知りたいのはこの機能です。 原則：
・C/C++のヘッダを直接読むことはできず変換が必要
・DMDでWin32アプリを作る場合に限り、C/C++ののライブラリの変換も必要
大抵のライブラリはすでに変換済みのが用意されてるのでそれを使うだけ
Win32API -> http://www.dsource.org/projects/bindings/wiki/WindowsApi/
ゲーム用とかなら github/DerelictOrg が充実してる いちおう公式のバインディング集 使ったことないからどのくらいあてになるかは知らない
https://github.com/D-Programming-Deimos wxDを使えている人に質問です。windows上でmingwからwxDをコンパイルしようとすると、wxWidgetsのコンパイルまでは成功したのですが
、wxDのコンパイルで以下のようなエラーがでます。
export PATH=/e/D/dmd2/windows/bin:/e/D/dm/bin:$PATH
export WXDIR=/e/D/wxWidgets-2.8.12
make
dmc -D__DMD__ -mn -g -o+none -D____ -D__WXDEBUG__ -Ie:/D/wxWidgets-2.8.12\inclu de -Ie:/D/wxWidgets-2.8.12\lib\dmc_lib\mswd -w- -I. -WA -DNOPCH -HP90 -Ar -Ae -HP99 -c -oaccel.obj accel.cpp
virtual ~name() \
^
local_events.h(49) : Error: storage class is illegal in this context
{ \
^
local_events.h(50) : Error: illegal constructor or destructor or invariant decla ration
ProcessEvent(e); \
^
local_events.h(52) : Error: undefined identifier 'ProcessEvent'
}
^
local_events.h(53) : Warning 18: implied return of name at closing '}' does not return value
void RegisterDispose(Virtual_Dispose onDispose) { m_onDispose = onDispose; } \
^
local_events.h(67) : Error: undefined identifier 'm_onDispose', did you mean 'on Dispose'?
virtual ~name() { m_onDispose(this); } \
^
local_events.h(68) : Error: storage class is illegal in this context
Fatal error: too many errors
--- errorlevel 1
--- errorlevel 1
--- errorlevel 1 dmd 2.067.0, dmd 2.054
wxWidgets-2.8.12
wxd 0.16
dmd 2.067.0, 2.054どちらでもエラー内容は同じでした。何が問題なのでしょうか? 久しぶりにさわったらUFCSとかrangeとかイケてるやん、書いてて気持ちえ〜わ〜 replaceはstringとregexで被ってるのか http://www.kmonos.net/alang/d/overview.html
>非仮想メンバ関数。C++では、関数がvirtualになるかどうかは クラスの設計者が前もって決定します。
>メンバ関数をオーバーライドすることにしたのに、基底クラスの方で改造を忘れる… というのは、
>よくある（けれども非常に見つけにくい）コーディングミスです。
>全てのメンバはvirtualにしておき、 オーバーライドが存在しないことをコンパイラが検知して非 virtual に変える、
>というアプローチの方が信頼性があります。
と書いてありますが、実際にどこまでそんな最適化が機能しますかね。
ローカルスコープでnewされたオブジェクトなら簡単に検地できますが、
メソッドの引数で渡されたオブジェクトや、
メンバ変数で保持しているオブジェクトに対して、
オーバーライドが存在しないことを、どこまで検地できるものなのでしょうか。
D言語はモジュール単位でコンパイルするので、
自分のモジュール以外で何が行われるかわからないのでは？ 詳しくないのでさっぱりなのだがこっちにも
http://www.kmonos.net/alang/d/function.html#virtual-functions
>コード生成時にDはクラス階層を全て把握していますので、
>オーバーライドされていない関数への呼び出しは全て最適化されて non-virtual になります。
って自信満々に書いてあるね。
で、なんかそんな話題どっかでみたなあと思って探してみたが
http://hibari.2ch.net/test/read.cgi/tech/1293500945/300-303
別に結論出てなかった。
まあ「finalつけると速くなる」なら（今でも同じかは確認してないが）
可能であろうと、少なくとも真面目に実装はしてないんだろうね。 virtual がキーワードとして追加された後しばらくして撤回されたのが最近の出来事 dmdしか使ってない俺にもdmdが最善ではなさそうなことはわかる コンパイルが最速でプロファイルもカバレッジもちゃんと動くdmdが最善でないとな？
win32/simd とか win64/seh とか足りないのはあるけど dmdのsimdってまだSSE2までしか対応してないのけ？ ポストC++を目指してるんだけど
C++自体が使われてないから 俺が思うに、Cとソースレベルの互換を切ったのが不味かったな。
Cのヘッダが読み込めないんじゃ、生産性悪すぎ。
Cのライブラリを使おうと思っても、誰かがこっそりDに移植したのを使うしかない。
そんな怪しげなものは企業じゃ使いにくいわな。 でもプリプロセッサみたいなXXXXXXなもの積んだら元の木阿弥だしなあ C言語にはマクロがあるから難しいだろうね。
マクロとインライン関数とじゃ微妙に動作が違うし。
それを再現するのは難しいし、再現したらしたでDの人たちが怒る 他の言語に比べりゃマシ。
普通はC側からもグルーコードを書かないといけない。 ライブラリ側の改造なしで普通にリンクできるってのは大きいなあ でも、CのライブラリはC++からだと何の改造もなく普通に読み込めるし、
殆どのライブラリはC++から使われること「も」想定して書いてあるし。
ライブラリの公式なサポートがあるってのも大きいかと。
Dの宿敵は完全にC++なわけで、ここからシェア奪うの厳しくね？
しかも最近のC++はやたら高性能になってて、Dが圧倒的に優位といえるのは、
GCが有ることぐらいか。しかしDのGCは完全じゃないので、実際には開放できる領域を
見逃すことがあるらしい。>>125-127
しかもメモリを使えば使うほど、切迫していればいるほど、誤認の確率が高くなる。
本当にGCが必要な時ほど、GCが上手く動かなくなるという・・・。これはなんかおかしい。
まー一生C++使ってろって言われそうだが。 京大院卒の元日立社員ですらrust,go,nimとやってきたがDは目次で投げ出すほど難しいらしい 仕様書であるTDPLを入門書と間違えて買ったんだろうな ■ このスレッドは過去ログ倉庫に格納されています
