次世代が造った言語 blawn

**デフォルトの名無しさん** · 2019/10/22(火) 13:17:06.14

次世代が造った言語 blawn について語るスレ
https://www.bcnretail.com/market/detail/20191021_142131.html
https://github.com/Naotonosato/Blawn

**デフォルトの名無しさん** · 2019/10/28(月) 23:32:03.01

メモリが安全だから！
お前らの言語は、危険！！

**デフォルトの名無しさん** · 2019/10/29(火) 03:10:40.02

>>252
真っ赤な他人を助けるような”ボランティア”というのがこの世に存在するんだから
見ず知らずのガキを擁護する変態がいてもおかしくはない

**デフォルトの名無しさん** · 2019/10/29(火) 07:05:05.33

ママ活

**デフォルトの名無しさん** · 2019/10/29(火) 13:11:56.25

ここに書いてる人って実際に動かしてみた人いるのかな

**デフォルトの名無しさん** · 2019/10/29(火) 13:23:59.63

いるわけないやろｗ
バイナリ配布されてないし、

compile from source
やめたほうがいいです。どうしてもやりたければLLVM6.0,bison,flexをインストールしてから
buildディレクトリで"make"してください。"make -j8"とかにするとコンパイルが早くなります。

とか書いてあるんだし

**デフォルトの名無しさん** · 2019/10/29(火) 13:57:33.71

リポジトリにバイナリも含まれてるで

**デフォルトの名無しさん** · 2019/10/29(火) 14:17:23.97

変なパス固定埋め込みされてるから
ちょっと触ってめんどくさくなった

**デフォルトの名無しさん** · 2019/10/29(火) 15:29:12.05

Blawnのフレームワーク作ろうと思ってるんだけど
すげぇワクワクしてる。俺たちが時代を作っていくんだなって感じる

**デフォルトの名無しさん** · 2019/10/29(火) 16:00:32.05

>>260
本気ですか？

**デフォルトの名無しさん** · 2019/10/29(火) 16:16:55.57

この言語は、「書き方が独自に変えてある」というだけで、それがメリットに
感じるかは個人差が大きい。少なくとも、return文が関数の最後の識別子になっ
ているのはデメリットに感じる人も多いだろう。return文を複数書くのは
良く無いという説を唱える人も要るが、一方で、それこそが一番便利な機能と
考える人も要る。校舎の意見では、一箇所でしか戻れないというのは不便
極まりないし、goto文も使わないとなれば、フラグを用意してそれ以後の
行でif 文で一々はじいていかなければならない。それは分かり易くも無いし、
処理効率的にも悪い。

**デフォルトの名無しさん** · 2019/10/29(火) 16:20:58.96

校舎「私はこう思う！」

**デフォルトの名無しさん** · 2019/10/29(火) 16:33:53.69

プログラミング歴が浅い人がプログラミング言語にどんな不満を持ってわざわざ新しいプログラミング言語を作ろうと思うのかまるで謎

**デフォルトの名無しさん** · 2019/10/29(火) 16:39:09.67

Pythonでプログラミング始めたみたいだし、
C++がPythonのように書けないのが不満なんだろう
Pythonしか知らないからPythonが基準

**デフォルトの名無しさん** · 2019/10/29(火) 16:57:42.56

Blawnのパフォーマンスやべえな
今自社の開発チーム全員が「やられた……」って顔してる
基幹システムにこっそりBlawn入れた早とちりさんも出てくるほどすげぇ言語だよこれ

**デフォルトの名無しさん** · 2019/10/29(火) 17:06:39.54

ポインタが無い時点で、C++よりパフォーマンスが高いことはありえない。
最適化はLLVMに任せているわけだから、clangと同じだし。

**デフォルトの名無しさん** · 2019/10/29(火) 18:23:54.26

今日俺が一目置いてる新人がまたやりやがったw

PHPでずっと作っていたプロダクトにちょくちょくBlawn入れてきやがったwwwwwwwww

最初はブチギレそうだったがソースの美しさとパフォーマンスの良さにメンバーは感動

結局流れで1からBlawnで作り直すハメにwあの馬鹿！w今度何かおごれや！w

**デフォルトの名無しさん** · 2019/10/29(火) 19:08:59.54

変なのが棲み着いたなぁ

**デフォルトの名無しさん** · 2019/10/29(火) 19:24:00.62

そういうネタスレでしょ

**デフォルトの名無しさん** · 2019/10/29(火) 19:30:06.46

2ちゃん、5ちゃんねるは伝統として面白いことを書く所だからネタスレでもいいんだが
住み着いてる奴はつまらないから全然駄目

**デフォルトの名無しさん** · 2019/10/29(火) 19:41:43.97

書き手の知識レベルが低すぎて夢見られない

**デフォルトの名無しさん** · 2019/10/29(火) 19:50:58.23

D言語というものがあってな

**デフォルトの名無しさん** · 2019/10/29(火) 20:20:11.20

【悲報】ついに職場でもスレ民みたいなエンジニアが現れる

俺「Blawn導入プロジェクトの進捗はどうなってる？」

敵「……ってません…」

俺「……ん？」

敵「やってませんッ！！！！こんな言語！！！！！！！」ﾊﾞﾝｯ!!!!

これさぁ、ヤバくね？
Blawnアンチってこんなのしかいないの？

**デフォルトの名無しさん** · 2019/10/29(火) 20:39:06.74

"俺の作った最強言語"って中二病の範疇だろ
中学生ならよくあること

**デフォルトの名無しさん** · 2019/10/29(火) 20:49:36.16

なんだろうbotなんかな？

**デフォルトの名無しさん** · 2019/10/29(火) 22:11:14.66

>>268
PHPはHTMLの中に組み込む言語で、blawnは今のところnative向け専用言語な
わけだから、その書き込みは全くの嘘だと断言できよう。

**デフォルトの名無しさん** · 2019/10/30(水) 00:51:45.11

これどうやったら試せるの？
sudo apt-get install blawn
みたいな感じでいいのか？

**デフォルトの名無しさん** · 2019/10/30(水) 01:38:07.79

$ git clone https://github.com/Naotonosato/Blawn/
$ cd Blawn/sample
$ chmod 0755 Blawn/blawn
$ chmod 0755 Blawn/data/llc
$ ./Blawn/blawn test1.blawn
Hello! I'm John
Hello! I'm renamed Bob

**デフォルトの名無しさん** · 2019/10/30(水) 16:06:14.72

>>262
result を予約語にしてる言語もあるんやで

**デフォルトの名無しさん** · 2019/10/30(水) 16:07:53.16

>>265
Python の様に描ける C++ はある

**デフォルトの名無しさん** · 2019/10/30(水) 16:17:18.18

1. return文を複数書くのは良く無い
2. goto使って最後のreturnの直前にジャンプすればいいんじゃね！
3. gotoも禁止！例外も禁止！

**デフォルトの名無しさん** · 2019/10/30(水) 20:14:18.39

kuinに比べたらマシ

**デフォルトの名無しさん** · 2019/10/30(水) 20:18:54.40

関数型言語Spinozaの方が5倍速いよ

**デフォルトの名無しさん** · 2019/10/30(水) 20:20:49.22

Spinoza、完成したのか

**デフォルトの名無しさん** · 2019/10/31(木) 00:43:21.12

おじさんはllvmがどういうものかすら理解できてなかったら、この子のコード見てただのライブラリなんだということがわかったよ

**デフォルトの名無しさん** · 2019/10/31(木) 01:11:46.69

>>286 何を言ってるんだ？　日本の言語を勉強した方が良いぞ。
お前にはプログラムは早すぎる。

**デフォルトの名無しさん** · 2019/10/31(木) 09:43:29.97

typoの推察つかないやつも相当向いてないと思うわ

**デフォルトの名無しさん** · 2019/11/01(金) 05:32:14.45

しかしライブラリ使えば中学生でも言語作れる時代になっちゃったんだな
言語作れるって言ったらひと昔はすげー！って言われたのに最近はそうでもないってことか
Twitter見ると高校生でOS作ってる子もいるし、技術の進歩ってこういうことなんだろうな

**デフォルトの名無しさん** · 2019/11/01(金) 07:40:33.23

Blawnは、Rubyに比べて、使いにくい。
returnのとこも、少しわかりにくい。

Web系で働くなら、Blawnより、断然Ruby。

次世代言語として、通用するのはやっぱりRuby！！！！！！！！！！！！

**デフォルトの名無しさん** · 2019/11/01(金) 08:27:14.45

>>290 相変わらずの?uby厨はみっともないな。幾ら落ち目になったからと言って中学生に嫉妬するなんて。

**デフォルトの名無しさん** · 2019/11/01(金) 12:40:32.51

>>289
構文解析器などは結構昔からあったけど
LLVMが使えるようになったのが大きいのだろう
gccは機能単位で使いづらかったし

**デフォルトの名無しさん** · 2019/11/01(金) 14:33:20.16

コンパイル速度が速いと本人が言っていると小耳に挟んだが、実は：
1. WindowsとC++の組み合わせの場合、必須となる windows.h ヘッダだけで、コメントを除いた状態で数えても
　 1万8,000行程度あり、*.cpp ファイルで書いたプログラム本体より、windows.h ヘッダ
　の解析に時間ががかっている。そのために pre-compiled heaeder 技術を VC++ は使っている。
　だから、windows.h やその相当品を読み込まない状態で Blawn をテストした場合、
　 WindowsとC++の組み合わせとは解析している行数が全く異なるためコンパイラの速度比較
　としては公平とは言えない可能性が高い。

2. 例えば、VC++のコンパイラは、pre-compiled header を使った場合、現在のエントリモデルのCPUでも、
　 1ソース当り 30(ms)程度でコンパイルを終える。pre-compiled header
　を使わない場合は、100(ms)程度。

3. Blawnが字句解析に用いているflexは正規表現で字句解析をするので根本的に遅くなる。
　例えば、windows.h はバイト数が 1MB程度もあるので、字句解析で 1文字当たり1クロック使うと、
　 0.3(ms)程度時間がかかる。もし、字句解析部分が1文字当り100クロック使ってしまうと、
　それだけでVC++のトータルコンパイル時間に達してしまうことになる。
　それだけに、字句解析は未だに1クロックで泣き笑いをする分野である。そこに、
　手書きコードより効率の悪い flex を使っている時点でコンパイル速度は望めない。
　ちなみに、new, delete を組み合わせて使うだけで、300クロックかかってしまうので、
　ヒープメモリの使用も控えるのに越したことは無い。

4. C++ には、#define マクロや、#if, #else, #elif, #endif などでの前処理もできる。
　これは見落とされがちだが実は重要。ここも字句解析ほどではないが、1クロックに
　泣き笑いをする分野である。Blawnには前処理層が無いから、VC++などと速度の単純比較は出来ない。

5. BlawnはバックエンドにLLVM処理用にclang系を使っている。これは、VC++に比べると
　遅い。なので、トータルで見たとき、flexを使わずに手書きしたとしても、LLVM
　を使っている段階で、VC++のコンパイル速度に勝つことは最初からほぼ不可能。

**デフォルトの名無しさん** · 2019/11/01(金) 15:35:24.71

>>293 blawn コンパイラがC++ で描かれてるだけで、blawn をコンパイルするのはblawnコンパイラ=LLVMだろ。
c のヘッダなんて関係ないんじゃないの？

**デフォルトの名無しさん** · 2019/11/01(金) 15:41:39.84

blawnで同等のものを作った場合だろ
Cにはプリコンパイルヘッダで高速化する技術があるが、blawnでwindows.hと同等の機能を持ったものを作った場合果たしてどうなるか

**デフォルトの名無しさん** · 2019/11/01(金) 15:44:10.45

blawnはlinux版しかないからWindowsが～とかVC++との比較は見当外れにも程がある

**デフォルトの名無しさん** · 2019/11/01(金) 15:55:17.18

言語の開発を続けるなら当然Windowsコンパイラも作られるしOSのAPIも叩けなきゃ困る

**デフォルトの名無しさん** · 2019/11/01(金) 16:09:07.69

Blawnはnative出力する言語なのだから、Linuxであれ、OSのAPIヘッダ相当の
ものを読み込む必要がある。そのヘッダの行数の目安としてwindows.hが
参考になる。

**デフォルトの名無しさん** · 2019/11/01(金) 16:30:08.76

この板の人間なら推測するな計測せよという言葉を聞いたことがあるだろう
Windowsでの速度はWindows版が出来てからする話だ

**デフォルトの名無しさん** · 2019/11/01(金) 16:32:21.68

>>299
flexとLLVMの組み合わせでVC++の速度を超えるのは測定しなくても無理と分かる。

**デフォルトの名無しさん** · 2019/11/01(金) 18:24:59.25

>>293
なんでもそうだが、

初期版は「他のソフトに比べて軽量で速い」という謳い文句だが
改良されて、他のソフトと同じぐらいになると重くなる。

単に実装されてる機能が少ないから速いだけのこと

**デフォルトの名無しさん** · 2019/11/01(金) 18:34:49.16

ほんそれ

**デフォルトの名無しさん** · 2019/11/01(金) 18:35:58.21

そもそもコンパイル時間が有意に問題になるほどの規模のプログラムをこれでコンパイルしたことが一度でもあるのかと
何をもってコンパイルが早いと言えるのか謎すぎる

**デフォルトの名無しさん** · 2019/11/01(金) 18:51:19.53

中学生だからそのへん適当なのはまぁしゃない
選ぶ方が鵜呑みにして賞与えるのがアホ
Matz聞いてるか？

**デフォルトの名無しさん** · 2019/11/01(金) 19:11:35.45

アピールポイントを無理やりひねり出すのはどんな世界でもよくあることだし
実測抜きにこんな話をしても意味ない

**デフォルトの名無しさん** · 2019/11/01(金) 19:15:37.38

審査員にMatzいたの？

**デフォルトの名無しさん** · 2019/11/01(金) 19:42:20.78

>>14

class ore_no_yume(musume)
@osaifu = musume.osaifu
@function try(musume)
if self.osaifu > 10000000000
(
text="かわいい"
text.append(musume.name)
print("もうすぐクリスマス")
print(text)
print("プレゼントにLVのバッグ")
print("ドンペリで乾杯してヘネシーで酔っ払う")
)
return

class Person(name)
@name = name
return

kanna = Person("橋本環奈"
@osaifu=10000000000000000
return

ore_no_yume(kanna)

**デフォルトの名無しさん** · 2019/11/01(金) 19:55:08.89

blawanって聞くだけで笑っちゃう

**デフォルトの名無しさん** · 2019/11/01(金) 19:58:03.62

ぶらわん？

**デフォルトの名無しさん** · 2019/11/01(金) 20:37:04.48

function leep_year(y)
return mod(y,400)==0 or (mod(y,100)!=0 and mod(y,4)==0)

**デフォルトの名無しさん** · 2019/11/01(金) 21:36:50.95

>>304
プログラミング言語を作るコンテストってわけじゃないし
他の応募作品の質も考えないと

**デフォルトの名無しさん** · 2019/11/01(金) 21:37:20.15

>>301
そういえば余り関係ないかもしれないけど、VC++6.0とVS2019のVC++とでは、
コンパイラ本体も後者の方が遅くなっているように感じる。

**デフォルトの名無しさん** · 2019/11/01(金) 21:42:33.47

あと、Linuxばかり使っていると気付かないかもしれないけど、
Linux本家のgccやclangですら、Windows上のVC++よりコンパイル速度が
だいぶ遅い。しかし、そのことを指摘したサイトは意外と検索にはかからない。
感覚的には5倍～10倍程度の速度差がある気がする。

**デフォルトの名無しさん** · 2019/11/01(金) 21:57:01.41

それはないわ

**デフォルトの名無しさん** · 2019/11/01(金) 22:34:19.32

Windows上のclangも、CUIのHello WorldをコンパイルするだけでもVC++より
ずっと遅い。

**デフォルトの名無しさん** · 2019/11/01(金) 22:55:08.69

コンパイルするプロジェクトの規模で変わらんの？

**デフォルトの名無しさん** · 2019/11/01(金) 23:41:54.60

http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html
Windows版Chromeの場合、Visual Studioと比べるとclangは15%ビルドが遅いらしい

5倍～10倍の速度差を感じるとしたら相当なバイアス掛かってるからそういう人の意見は適当に聞き流しておけばいい

**デフォルトの名無しさん** · 2019/11/01(金) 23:43:12.89

俺でも言語作れる気がしてきた

**デフォルトの名無しさん** · 2019/11/02(土) 00:17:42.06

>>318
インタプリタなら簡単だぞ

**デフォルトの名無しさん** · 2019/11/02(土) 00:18:53.74

LLVM使えばインタプリタ並みに簡単になるんじゃねーの？

**デフォルトの名無しさん** · 2019/11/02(土) 00:21:37.37

blawnのソースパクって1文字変えてコンパイルすれば新言語誕生だぞ
それで自尊心を満たしておとなしくしていていくれ

**デフォルトの名無しさん** · 2019/11/02(土) 01:00:02.52

いきなりデッチ上げられたクソ言語だろ

**デフォルトの名無しさん** · 2019/11/02(土) 01:22:38.92

C++は理由があってああいう文法になってるんだから
気に入らないんだらPythonでも使えばいいのに
なぜわざわざ新興言語なんだ
サポートの保証はあんのか？

**デフォルトの名無しさん** · 2019/11/02(土) 01:47:31.06

アホなコンパイルすれば速度上がるだろ

単に早いとか遅いとか言っても参考になら？

**デフォルトの名無しさん** · 2019/11/02(土) 06:37:36.91

中学生にきみら必死やなw
なんかwindowsでもexproit調べるソフトを中学生が作って公開されてるけどさ。
糞遅くてワロタわ。
cとアセンブルじじいが、もっと速くできるってうるさいのが5ch
爆笑よw

**デフォルトの名無しさん** · 2019/11/02(土) 06:40:15.53

でも、発想が評価されるっていいんじゃない？
アセンブルじじい、もう時代遅れなんだよww

**デフォルトの名無しさん** · 2019/11/02(土) 07:52:45.00

2vs3戦争に疲れてpython死んでしまったか

後継言語は決まったな

**デフォルトの名無しさん** · 2019/11/02(土) 09:50:56.72

>>317
リンク先読んでないけど、実体験とは全く違う結果で何かおかしい。
現実にclangもgccもVC++よりずっと遅い。

**デフォルトの名無しさん** · 2019/11/02(土) 09:56:17.20

>>328
多分、そのプロジェクトの場合、「clangを使う」と言っても全面的にmsvc
を置き換えていない気がする。そもそも15%のみの増加という数値は現実と
かけ離れているし：
Note that Clang is not a replacement for Visual Studio, but an addition to it.
We still use Microsoft’s headers and libraries to build Chrome, we still use
some SDK binaries like midl.exe and mc.exe, and many Chrome/Win
developers still use the Visual Studio IDE (for both development and for
debugging).

**デフォルトの名無しさん** · 2019/11/02(土) 10:04:42.51

>>325
>cとアセンブルじじいが、もっと速くできるってうるさいのが5ch
>爆笑よw
若い人はいきなりC#から入るように仕向けられているし、ベンチマークテストは
C#有利な嘘情報ばかりが氾濫しているし、clangとVC++の速度差が15%程度しかない
という嘘情報も出回っている。正しい情報を届けないと日本のIT産業はますます
駄目になる。
C#がC++の速度を上回っている結果になってるベンチマークテストは、
C++だけは駄目なやり方を使っている。一件、最新のSTLを使っているようだが、
それがいけない。最新のSTLが、速度的に良い方法ではないからだ。
昔からの伝統的な生配列などを使ったものがC++の真の速度。

また、Linuxが流行らなかった一つの理由に、実際に使ってみると、gccの速度
が遅かったからというのも有ると見ている。なので、コンパイラの速度は非常に重要。
そしてそれは、flexを使っていては達成しにくい。

**デフォルトの名無しさん** · 2019/11/02(土) 10:25:00.56

昔のDelphiのようにコンパイルが速い言語が欲しい

**デフォルトの名無しさん** · 2019/11/02(土) 10:36:05.74

StackOverflow でも、Windows上のgccの遅さは指摘されている：

https://stackoverflow.com/questions/8194954/is-there-any-performance-issue-between-cygwins-gcc-over-msvc-compiler-on-window
>GCC on Windows (especially Cygwin distribution) is damn slow in compile speed,
>but I guess this is expected. GCC is cross-platform, has about 5 middle phases
>(transforming from one tree to another), has pluggable architecture, and many
>other things that could sacrifice compile speed for flexibility.

「Windows 上での GCC(特に cygwin 上で）は、コンパイル速度が物凄く遅い。」

damn slow = 物凄く遅い。

**デフォルトの名無しさん** · 2019/11/02(土) 10:45:36.06

じゃあ何なら早いんだ

**デフォルトの名無しさん** · 2019/11/02(土) 10:46:13.73

>>333
VC++。

**デフォルトの名無しさん** · 2019/11/02(土) 10:52:12.41

話整理しろよ無能
マシン
OS
コンパイラ、リンカー
コンパイラ、リンカーオプション
ソースコード
これらがどういうもので速度差がいくらなんだよ

**デフォルトの名無しさん** · 2019/11/02(土) 10:52:30.96

テキストみたいな細かいファイルを沢山読み書きする場合のfile ioが死ぬほど重いんだろ
cygwinだと顕著

**デフォルトの名無しさん** · 2019/11/02(土) 10:56:02.68

cygwinのせいかと思って、Linuxでも試してみたが、確かにcygwin版よりは
速いが、やっぱり遅いことが分かった。実際、あるプロジェクトを全ビルド
してるとき、マルチコアビルドにしても、ビルドがなかなか終わらなくて困った。
gccではアジャイル開発的な試しながら作るやり方は難しいのではないかと
思う。

**デフォルトの名無しさん** · 2019/11/02(土) 11:05:18.70

じゃなくてgccはどのos上なら早いのか、っていう話

汎用ソフトvs専用ソフトならwin専用に作られてるclが早いのは当然、
それ自身をクロスコンパイル死まくってるgccが遅いのはむしろ当然だ
遅い＝全環境で動く、ってのはJavaも同じだ

**デフォルトの名無しさん** · 2019/11/02(土) 11:07:58.77

>>338
日常的に道具として使う側にとっては、クロスコンパイルで遅くなってる
という理屈で溜飲が下がる分けでも無い。

**デフォルトの名無しさん** · 2019/11/02(土) 11:39:14.88

>>330
Linuxが流行らなかったってどこの世界で生きてるの？

**デフォルトの名無しさん** · 2019/11/02(土) 12:13:58.58

>C#がC++の速度を上回っている結果になってるベンチマークテストは、
>C++だけは駄目なやり方を使っている。一件、最新のSTLを使っているようだが、
>それがいけない。最新のSTLが、速度的に良い方法ではないからだ。
>昔からの伝統的な生配列などを使ったものがC++の真の速度。

ほんそれ
C/C++とアセンブラ以外のほぼ全部の言語に当てはまるわ
ウソをまき散らす香具師らの多いこと多いこと

**デフォルトの名無しさん** · 2019/11/02(土) 12:15:20.34

>>332
cygwin1.dll 経由だと遅くなるのは当たり前
mingw と比較汁

**デフォルトの名無しさん** · 2019/11/02(土) 12:56:40.07

mingwもそうだが実行時に外部dll読み込むせいで起動が遅くなる
俺のソフトもLinuxからWindowsに移植したとき起動がすごい遅くなった

**デフォルトの名無しさん** · 2019/11/02(土) 13:25:56.32

でも gccはLinux上でも結構遅い。

**デフォルトの名無しさん** · 2019/11/02(土) 13:27:23.60

中学生が作った言語にケチつけるスレは賑わってるのに自分で作るスレの閑散ぶりｗ

「コンパイラ・スクリプトエンジン」相談室16
https://mevius.5ch.net/test/read.cgi/tech/1405822579/

**デフォルトの名無しさん** · 2019/11/02(土) 14:19:03.06

>>344
結構じゃなくて10倍なんだろ？
どんな環境か明らかにしろ無能

**デフォルトの名無しさん** · 2019/11/02(土) 15:54:37.26

>>346
Windowsのcl.exeとLinuxのgccを両方使ってみたことがある人ならすぐに分かるから
書くまでも無い。あなたは使って無い証拠。

**デフォルトの名無しさん** · 2019/11/02(土) 16:54:38.14

>>343
同じ gcc でも cygwin は別格だが mingw じゃなくて
tdmgcc でコンパイルしたネイティブアプリは起動速いんだよな
なんでだろ

**デフォルトの名無しさん** · 2019/11/02(土) 17:55:20.12

>>347
両方使ってる
同じソースをビルドをしてるわけじゃないが10倍も遅いって感じたことないね
お前が何か間抜けな間違いしてる可能性の方が高い
Linux gccでは並列分散ビルドされてないとかな

**デフォルトの名無しさん** · 2019/11/02(土) 18:15:57.46

>>349
10倍ということは無いかもしれないが、3～5倍はありえる。

**デフォルトの名無しさん** · 2019/11/02(土) 19:27:06.54

昨日は5倍～10倍と言ってたのに1日で変わる
バイアス掛かってる奴の言うことなんてその程度だ

**デフォルトの名無しさん** · 2019/11/02(土) 19:40:25.08

何のスレやらわからなくなっているが
for,ifがネストできないバグは修正されたようだ

**デフォルトの名無しさん** · 2019/11/02(土) 22:55:12.83

感覚としてはclのがビルド時間は長いが実行速度は速いって感じではある。