nim

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

>>83
最近のは勝手に gcc 入れてくれるよ。

**デフォルトの名無しさん** · 2019/11/06(水) 15:17:56.57

HANDLEもこっそりtypedefに_PTR変えたんだっけ

**デフォルトの名無しさん** · 2019/11/06(水) 15:20:05.05

誤爆った

**デフォルトの名無しさん** · 2019/11/09(土) 00:06:35.30

Nim playground
https://play.nim-lang.org/
次スレから>>1に入れといてよ

しかしver1到達したのに全然盛り上がらんのなお前ら

**デフォルトの名無しさん** · 2019/11/09(土) 03:28:50.22

https://wandbox.org/
こちらでもNim使えますよ。

**デフォルトの名無しさん** · 2019/11/10(日) 11:17:11.92

>>85
distフォルダにmingwの7z玉入れておけば、オフラインでのインストールもできるね。

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

>>84
日本語の書籍はないが、原著のドキュメントは割とわかりやすい。docs/tut1.htmlから読み始めるといいかもしれない。
NIAは評判が良いらしいのと、製本版を買うと電子書籍版が無料で付いてくるらしい。

国内でのNimの翻訳は有志が約二名ほど作業しているが、まだ始まったばかり。時間かかりそうだね。

**デフォルトの名無しさん** · 2019/11/18(月) 09:38:29.23

DLLのCの関数を呼ぶ方法はいくつかあるようですが
なぜいくつもあるのでしょうか？
どれが一番効率が良いのかとか新しいのかとか判りにくい

**デフォルトの名無しさん** · 2019/11/18(月) 15:24:43.91

単純にdll内の関数を呼びたいならdynlibプラグマを使うのが一番楽。
少し低レベルな機能が必要ならdynlibモジュウルにあるプロシイジャアを使えばいいんじゃなかろうか

**デフォルトの名無しさん** · 2019/11/18(月) 17:09:32.08

成る程。

**デフォルトの名無しさん** · 2019/12/10(火) 23:17:13.67

nimに対応したソースコード可視化ツールってある？

**デフォルトの名無しさん** · 2019/12/12(木) 17:09:11.38

nimってあまりかっこよくないね

**デフォルトの名無しさん** · 2019/12/13(金) 23:01:47.25

Cにコンパイルしてからコード解析ツールに。

**デフォルトの名無しさん** · 2020/03/25(水) 04:10:40.05

nimコードはトランスパイルする前ならクロスプラットフォームなんだろうか？

**デフォルトの名無しさん** · 2020/03/27(金) 15:59:22.92

こんないい言語なのに結局欠点はCに依存してる点

**デフォルトの名無しさん** · 2020/03/27(金) 16:10:13.08

あんまり本出ないね
むしろチャンスか

**デフォルトの名無しさん** · 2020/03/27(金) 22:55:09.53

あの糞マクロ以外大して面白みのない言語だしなぁ

**デフォルトの名無しさん** · 2020/04/07(火) 05:01:02.90

逆にマクロの完成度高い言語ってなに？

**デフォルトの名無しさん** · 2020/04/07(火) 07:46:31.57

common LISP

**デフォルトの名無しさん** · 2020/04/07(火) 14:00:10.17

Schemeは？

**デフォルトの名無しさん** · 2020/04/07(火) 19:47:26.61

nimのマクロは完成度高いと思う。でも完成度高いマクロという存在自体が糞。

**デフォルトの名無しさん** · 2020/04/08(水) 12:06:55.28

MACRO-80

**デフォルトの名無しさん** · 2020/04/10(金) 23:13:42.18

>>102
糞マクロを褒めてるのであって
逆じゃないと思うんだが

**デフォルトの名無しさん** · 2020/04/10(金) 23:14:33.21

>>101>>105が同じってことだろ
common lispなんてはるかに糞になるし

**デフォルトの名無しさん** · 2020/04/10(金) 23:15:34.44

マクロならrustのが定評あると思うが

**デフォルトの名無しさん** · 2020/09/19(土) 22:27:13.04

小数の配列作りたいんだけどやり方教えてください。
[0.0, 0.1, .. 0.9, 1.0] みたいな。

Python なら hoge = [i/10 for i in range(11)] かな。気持ち悪いけど。

**デフォルトの名無しさん** · 2020/09/22(火) 12:29:56.17

lc[i*0.1 | i<-0..10 ]

**デフォルトの名無しさん** · 2021/01/10(日) 21:59:51.09

>>69
var name = readLine stdin
var name = stdin.readLine
で完結してるよ、型推論で>>72にも言った通り型を何回も書く意味がない。付け加えれば()カッコも
要らない。第一引数クロージャーのラムダ式で言えばカッコが必要ないのに書く意味が無い。そして
varとletとは不変性だが、rustやVの様にたかがGCを搭載したく無いだけで、どこでもmut mutして
プログラマに負担を強いるより良い（あくまで個人の感想です）
さらに、procとfuncも、片方が純関数なのはキーワードとして明示できる統一性としてありだね。
まあpragmaが多すぎる気もするけど、if likely(true)/unlikely(false)の様にCPUキャッシュ分岐予測に
直接関与出来る高級言語としては、他に類を見ない。GCが嫌ならOFFに出来るし、そして重い
Stop the Worldが嫌ならそれをしないGCに変えることが出来る、言語としては機能が多くて
Goの様に究極なシンプル（なのに統一性が微妙）じゃ無いけど、こりゃ良いわ
var name = stdin.read LineEnum

**デフォルトの名無しさん** · 2021/01/10(日) 22:14:35.92

付け加えるとHaskellみたいなproc() = の宣言が微妙キモいけどfunc(): T =があるから、まあ妥当だね
rubyの様なreturnを書かないのは良い。result=xは便利だけど微妙....でそこまでやるならOptionと
Future、そして例外を統一して欲しかったな。
普通にtry: except: finally:があるのも点数が高い。Araqが言う様に例外と(Label)goto based exceptは
ほとんど同じ何だから、今どきの言語が例外が無いのはおかしい。まあ他を悪く言う気はないけど
Goの様に意味合い的に同じでfinallyに対応するdeferがあるのも良いよね

**デフォルトの名無しさん** · 2021/01/12(火) 15:33:30.76

超時空ロングパス

**デフォルトの名無しさん** · 2021/01/12(火) 15:57:17.72

この言語がJsと比較で優れてる点ってあるの？

**デフォルトの名無しさん** · 2021/01/13(水) 08:29:44.80

JavaScript？であれば、JavaScriptはECMAScriptのバージョンとともに型無しのダックタイプから
クラス定義で見られるように型を導入して大規模コードを書く際に静的な安全性を求めてきた、
言語的な特徴でもあった動的なメソッド上書きやapply/callは悪とみなされつつ、改良が進む。
TypeScriptもその特徴であろう、altJSあるいはJSX派生と呼ばれる一種の方言が多量に誕生した
一方でJavaScriptの遅さや１言語依存からwasmが考え出されて多くのコンパイラでwasm開発が
できるようになった。Nimも例に漏れずJSバックエンド及びwasmコンパイルが可能である。
Rustもwasm開発はそうだがJSバックエンドは無い、Goもwasmは出来るがサイズが大きい
NimはGoに比べても型チェックが厳しい、Rustはそれに借用いわゆるボローチェックがそれに
加わるRustもそうだが型安全性はばつぐんだ

**デフォルトの名無しさん** · 2021/01/14(木) 18:15:15.39

jsって割と底辺だと思うから
Nimはそれより上だろ

**デフォルトの名無しさん** · 2021/02/25(木) 19:45:58.25

1.4.4 age

**デフォルトの名無しさん** · 2021/04/17(土) 20:22:19.25

1.4.6 age

**デフォルトの名無しさん** · 2021/04/30(金) 20:42:36.52

Windows defenderでウイルス判定される

**デフォルトの名無しさん** · 2021/05/01(土) 12:24:15.54

それはどうしようもない
https://forum.nim-lang.org/t/7830

**デフォルトの名無しさん** · 2021/05/10(月) 13:57:34.01

頼むからもう少し流行ってください。Dropトレイト、Rcトレイトと戯れてあいつのコードを直したくない

**デフォルトの名無しさん** · 2021/05/10(月) 15:07:45.08

明日に向かって吠えろ

**デフォルトの名無しさん** · 2021/05/13(木) 14:29:40.54

Software Design に記事持ち込め

**デフォルトの名無しさん** · 2021/05/15(土) 12:35:34.04

https://www.akiradeveloper.com/post/give-up-nim/

**デフォルトの名無しさん** · 2021/05/19(水) 07:49:19.67

2015年2月なんて大昔だろ…Version 0.11頃の話、貼る奴w

**デフォルトの名無しさん** · 2021/05/19(水) 07:53:15.04

間違えた。
2月だから0.11さえ出てないわ、0.10.2…

**デフォルトの名無しさん** · 2021/05/26(水) 22:06:31.04

>>120-122
バージョン1.4.8がリリースされました
2021年5月25日ニムチーム

Nimチームは、Nim1.4の4番目のパッチリリースであるバージョン1.4.8を発表できることを
嬉しく思います。バージョン1.4.8は、1か月のハードワークの結果であり、23のコミットが
含まれており、最も重要なバグが修正され、ORCメモリ管理がさらに改善されています。
すべてのユーザーにバージョン1.4.8をアップグレードして使用することをお勧めします。

リリースのハイライト
develブランチと同様に、v1.4.8はcsources_v1を使用して構築されています。つまり、
AppleM1チップで使用できます。
バージョン1.4.6は、いくつかのウイルス対策ソフトウェアでいくつかの誤検知を引き
起こしました。私たちのテストによると、これはv1.4.8では発生しないはずです。

**デフォルトの名無しさん** · 2021/06/24(木) 16:12:27.31

なんか結局流行らなかったな
2019ごろはちょっと来そうな雰囲気出してたのに

**デフォルトの名無しさん** · 2021/06/24(木) 16:13:02.76

今でも一番書いてて気持ちいい言語ではあるけど

**デフォルトの名無しさん** · 2021/06/24(木) 17:25:26.02

Luaといい勝負？

**デフォルトの名無しさん** · 2021/06/27(日) 14:10:40.69

Luaの理念は、簡素、高効率、高移植性(simple, efficient, extensible)、現在はpowerfulとかに変えた。
JITもあるが型の概念が希薄で基本はNativeではない。GCあり、プロトタイプベースのOOPSもC/C++の
相互運用も図られているが、主な用途は本体のプログラムを拡張するスクリプト、ゲームの拡張や
３Dモデリングソフトなどの拡張。

一方、Nimは「Efficient, expressive, elegant」（効率的、表現力豊か、エレガント）であり、型は厳格。
関数、あるいはプロシージャ呼び出しも厳密。Goにあるinterface{}のようなものは無く、Cというか
リンケージ指定、オブジェクトコピー方法、インライン展開など明示するような言語と一体化されたプラグマ。
言語と一体化されたマクロ・テンプレート。状況で選べるGC、例外try-catchとdeferを全否定をしない。
RustのようにGCを排除したためプログラマに押し付けた借用チェックは無い。
Goよりも小さくて速いGC、それによる速度低下は最小限、Rustは学ぶ価値が確かにあるが非常に高い敷居。
Nimは非常に低い敷居(Goほどではないが）、表現力はC/C++そのもの、限りなく抑え込まれたタイプ量。

**デフォルトの名無しさん** · 2021/06/27(日) 20:05:41.95

そんなにヒドいかな？

**デフォルトの名無しさん** · 2021/08/21(土) 08:23:43.68

Nimにガベージコレクション(GC)有りは事実なのですが、
NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されれば
GC無しで、View types参照の有効性を検証する
ことによってメモリ安全性を保証しつつ高速化して
C/C++/Rustの代替に出来ますか？

**デフォルトの名無しさん** · 2021/08/21(土) 08:47:50.25

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

**デフォルトの名無しさん** · 2021/08/21(土) 22:20:40.33

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 08:04:08.99

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/10/02(土) 12:07:48.96

いつの間にかJetBrainsのプラグインが出てたね。今更気がついたよ
これもかなり良いんじゃない？
https://plugins.jetbrains.com/plugin/15128-nim

**デフォルトの名無しさん** · 2021/10/27(水) 21:47:06.11

const str = [0, 1, 2, 3, 4]
for i in 0||str.high: echo str[i]
# nim --passC:"-fopenmp" --passL:"-fopenmp" c main.nim

**デフォルトの名無しさん** · 2021/10/28(木) 12:20:10.25

>>92
Cの関数だけでもいろいろなコンパイラーにより規約が違うから、ダイナミックなリンケージを非常に素直に
書ける言語はこれくらいだと思う。rustもFFIで呼べるけど
https://ja.wikipedia.org/wiki/呼出規約

**デフォルトの名無しさん** · 2021/10/29(金) 07:15:01.84

Nim言語の開発者が$100k相当のBitcoinの寄付を受け取ったことが話題になっています。
www.reddit.com/r/programming/comments/qg2srd/nim_receives_100k_in_bitcoin_donations/

**デフォルトの名無しさん** · 2021/11/11(木) 20:14:42.95

>>99
公式での処理系は基本的にはC/C++のトランスコンパラですがJSのトランスコンパラとしても動作します。
言語的には依存している分けではなく、gccやclangの最適化の恩恵を受けるためにあえてそのようにして
いるようです。
また直接バイナリを吐き出す別のコンパイラarnetheduck/nlvmもあります。CrystalやRust、Swiftなどの
LLVMバックエンドと同じです。コンパイル時間を短縮しllvmバイナリとして僅かに小さくなります。

**デフォルトの名無しさん** · 2021/11/22(月) 17:33:11.29

RustよりC++より速いんですか？　始めてみようかな

**デフォルトの名無しさん** · 2021/11/22(月) 20:36:44.15

いろんな意味で早いと思う

**デフォルトの名無しさん** · 2021/12/17(金) 19:10:05.51

Version 1.6.2 released
https://nim-lang.org/blog/2021/12/17/version-162-released.html

**デフォルトの名無しさん** · 2022/02/10(木) 01:19:39.92

Version 1.6.4 released
https://nim-lang.org/blog/2022/02/08/version-164-released.html

**デフォルトの名無しさん** · 2022/03/29(火) 04:55:27.78

1.6.x系だけDLしようとするとマルウェア警告出るんだけどこれ大丈夫なんかね

**デフォルトの名無しさん** · 2022/03/29(火) 14:58:47.55

Nimの公式サイトから入手したものなら大丈夫なはず。
Nimに含まれている実行ファイルやNimでコンパイルしたプログラムがアンチウィルスソフトウェアに誤検出される問題は多くの人々から報告されている。
Nim言語でマルウェアを書いてる人がいるせいで誤検出さるようになったらしい。
アンチウィルスソフトウェアは悪いことしないプログラムでもマルウェアと似たようなビットパターンを見つけるとマルウェアとみなすっぽい。

**デフォルトの名無しさん** · 2022/03/29(火) 15:37:13.13

>>148
なるほどね？
サンキュー😉👍🎶

**デフォルトの名無しさん** · 2022/03/29(火) 20:54:07.21

マルウェアと誤検知されたくなければnimで開発しない方が無難か。

**デフォルトの名無しさん** · 2022/03/31(木) 21:33:49.63

多くの人が使っているプログラムでない限り誤検出される可能性はある。
C++使ってたころにビルドが完了してすぐに誤検出されことがあったし。

**デフォルトの名無しさん** · 2022/03/31(木) 21:54:44.97

そういうどっちもどっち論じゃないだろ。>>148は有意に誤検知が多いと言っているように見えるが。

**デフォルトの名無しさん** · 2022/04/01(金) 11:47:01.52

Nimコンパイラ自体がマルウェア扱いだからな。

**デフォルトの名無しさん** · 2022/04/03(日) 00:58:55.13

Nimを書き初めて1ヶ月...procの第一引数に設定したオブジェクトにprocがバインドされる謎構文にはたまげたけど書き味がいいし気に入ったなあ

**デフォルトの名無しさん** · 2022/04/03(日) 10:37:31.39

>>154
ちょっと誤解しているようだけど、a.foo()って書いたら自動的にfoo(a)に変換されるだけだよ。
第一引数の型にそのprocがバインドされるわけじゃないよ。
X.nim:
type
　Foo* = object
　　x: int
proc foo*(f: Foo) = echo f

Y.nim:
import X
proc bar*(): Foo = Foo()

Z.nim:
import Y
#X.nimをインポートしてないとfoo()は呼べないよ
bar().foo()

**デフォルトの名無しさん** · 2022/04/03(日) 10:53:58.62

Nimではプロシージャの呼び出し方が何通りかある。
echo("Hello")
# Command invocation syntax
echo "Hello"
# Method call syntax
"Hello".echo
"Hello".echo()
# Generalized raw string literals
# 引数が文字列リテラル一個のときのみ
echo"Hello"

**デフォルトの名無しさん** · 2022/04/03(日) 20:20:01.30

>>155
なるほど👀
それでも変わった感じですよねえ

**デフォルトの名無しさん** · 2022/04/09(土) 11:44:54.12

>156
Method call syntax はスマートだから他言語でも流行ってほしいところ。
特にPythonは真っ先に採用して欲しいわ。

**デフォルトの名無しさん** · 2022/04/22(金) 04:37:03.66

あまり何通りもあるのはperlみたいになりそうでよろしくないな。

**デフォルトの名無しさん** · 2022/05/05(木) 20:58:23.76

Version 1.6.6 released
https://nim-lang.org/blog/2022/05/05/version-166-released.html

**デフォルトの名無しさん** · 2022/05/06(金) 17:32:07.42

>>160
急にコンパイルできなくなって困ってたら
vccexe,exeがトロイ認定受けて削除されてた…
MSはnimをトロイだとみなしてるのか

**デフォルトの名無しさん** · 2022/05/08(日) 11:28:42.79

>>161
前に一回同じ現象出たわ
コンパイル失敗するしWindows Defenderはうるさいしで何かやらかしたかと思った

**デフォルトの名無しさん** · 2022/05/18(水) 23:08:10.33

ニンニン

**デフォルトの名無しさん** · 2022/06/14(火) 14:49:13.90

二ムってドイツ製？

**デフォルトの名無しさん** · 2022/06/22(水) 00:08:54.72

Araqってたしか国籍は南米じゃなかったか

**デフォルトの名無しさん** · 2022/06/22(水) 00:28:49.96

>>164
すまんドイツ人だったわ
顔面からずっと南米の人だと思ってた

**デフォルトの名無しさん** · 2022/07/26(火) 18:12:34.65

ニンニン

**デフォルトの名無しさん** · 2022/07/26(火) 18:15:36.24

浣腸

**デフォルトの名無しさん** · 2022/07/27(水) 03:59:11.24

Aliasing restrictions in parameter passingかview typesが実装されればNimもRust並にメモリ安全になると思うんだけど。
みんなはどう思う？
https://nim-lang.org/docs/manual_experimental.html#aliasing-restrictions-in-parameter-passing
https://nim-lang.org/docs/manual_experimental.html#view-types

**デフォルトの名無しさん** · 2022/07/28(木) 11:23:58.38

>>169
むしろ--mm:orcならRustよりNimのほうが循環もGCするだけメモリ安全だし、リリースビルドでオーバーフローチェックが意味不明にoffになり、言語仕様としてループindexにunsignedを使うRustのどこが安全なのかと小一時間。
まあNimでのdangerコンパイルと似てるし、構文上まだ危険な超絶ハック表現が出来てしまうので素人にはオススメ出来ない諸刃の剣。だけどsqlパッケージの文字列前提を絶対変えてほしい

**デフォルトの名無しさん** · 2022/07/28(木) 14:19:26.27

RustのBorrow Checkerはメモリリークを防ぐものではないからね

**デフォルトの名無しさん** · 2022/07/29(金) 02:16:03.41

nimの言語的とか技術的な弱点や欠点って何？

**デフォルトの名無しさん** · 2022/07/29(金) 03:05:46.34

templateまたはmacroの第一引数がuntypedだとmethod call syntaxが使えない。
method call syntaxでgenerics parameterを指定するときにfoo.myproc[:int]()みたいな感じで[]の中の初めに':'を付けないといけない。method call syntaxを使わないときは':'は不要。
という感じでmethod call syntaxにちょっとした罠がある。

**デフォルトの名無しさん** · 2022/07/29(金) 12:18:00.08

macroが全く別言語になってる錆やその他諸々よりも、ちゃんと言語の最小サブセットになってるからまだマシ

**デフォルトの名無しさん** · 2022/07/29(金) 13:08:45.89

なるほど

**デフォルトの名無しさん** · 2022/09/10(土) 16:11:58.36

win10 x64 nim-1.6.6 x64 です
(A)
var hoge = newSeq[uint16](16)
# hoge[...] に wchar_t の文字列 L'\x0' 終端がある (サロゲートとか無い状態で 4文字分)
echo convert(cast[string](hoge[0..3]), "utf-8", "utf-16")
(B)
var fuga = newSeq[char](16)
# fuga[...] に char の文字列 '\x0' 終端がある 4文字分
echo cast[string](fuga[0..3])

(B)の方は期待通り 4文字分出力されるのですが
(A)の方はなぜか 2文字くらいで切れてしまいます
echo convert(cast[string](hoge[0..7]), "utf-8", "utf-16")
と修正すると 4文字出ましたが何か腑に落ちません

**デフォルトの名無しさん** · 2022/09/11(日) 06:48:19.18

>>176
そもそも何をしたいの?
windowsで日本語を表示したいだけならutf8を使ってればOk
デフォルトでNimのコマンドラインプログラムを実行するとchcp 65001コマンドを実行したときのようにコードページをutf8に変更される。
chcp 65001を実行してもちゃんと日本語が表示されるようにターミナルを設定しよう。

utf16なテキストをutf8に変換して表示したい場合はできるだけcast使わないようにコードを書こう。
castは危険なのでできるだけ使わないようにしよう。
(castはビットパターンが同じまま別の型と見なす変換なので実装詳細を知らずに使ってるとうまく動かない)
最初からstringに文字列を格納するようにするとか、ループで一文字づつstringにコピーすればcastは避けられると思う。

**デフォルトの名無しさん** · 2022/09/11(日) 15:33:59.58

上の例とは若干違いますが
var u16 = newSeq[uint16](8)
for n in 0..7: u16[n] = cast[uint16](65 + n)
u16[7] = 0
echo u16 # -> @[65, 66, 67, 68, 69, 70, 71, 0]
echo convert(cast[string](u16), "utf-8", "utf-16") # -> ABCD
let u8 = cast[ptr UncheckedArray[array[16, uint8]]](u16[0].addr)[0]
echo u8 # -> [65, 0, 66, 0, 67, 0, 68, 0, 69, 0, 70, 0, 71, 0, 0, 0]

ABCD のところが ABCDEFG にならないのがなんでかなーというのも
同様の現象が原因だろうと思います

**デフォルトの名無しさん** · 2022/09/11(日) 15:42:19.33

echo convert("\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x00\x00", "utf-8", "utf-16")
これは
ABCDEFG
と出力されます

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:12.92

>>178 の例で
var u16 = newSeq[uint16](16)
と定義しておくと(他は変更無し)(後半は0で埋まってる)
ABCDEFG
と表示されます

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:57.35

まあ cast に何を期待してるんだと言われればそれまでなんだと思いますが腑に落ちませんでした

**デフォルトの名無しさん** · 2022/09/11(日) 19:01:47.42

nimってIDEやデバッガは近いうちに計画されてるの？
vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな
条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが

**デフォルトの名無しさん** · 2022/09/11(日) 19:50:17.68

>>182

vscodeのプラグイン
nimsaem.nimvscode + webfreak.debug ではだめか？

**デフォルトの名無しさん** · 2022/09/11(日) 22:55:03.70

やっぱりその組み合わせか
どうにも使いづらいんだよねぇ
言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな

**デフォルトの名無しさん** · 2022/09/12(月) 01:44:56.16

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast

**デフォルトの名無しさん** · 2022/09/12(月) 01:47:29.58

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの？
そうでないならcast使うのはやめたほうがいいよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:10:20.86

>>181
seqやstringのデータ構造を理解しcastが何をしているか理解すれば納得できると思うよ
https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim
https://github.com/nim-lang/Nim/blob/devel/lib/system/strs_v2.nim
そもそもseq[uint16]からstringへcastしてる時点でもうデタラメなんだよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:17:45.60

>>182
NimにGDBでデバッグできるようにするプラグインが付属していて
gdbでブレークポイントをおいたり変数の中身を表示したりできます。
https://internet-of-tomohiro.netlify.app/nim/gdb.ja.html

**デフォルトの名無しさん** · 2022/09/12(月) 20:00:29.06

>>178 >>180
var u16 = newString(16)
for n in 0..7: u16[n * 2] = cast[char](65 + n); u16[n * 2 + 1] = '\0'
u16[14] = '\0'
echo u16 # -> A B C D E F G
echo convert(u16, "utf-8", "utf-16") # -> ABCDEFG

**デフォルトの名無しさん** · 2022/09/12(月) 22:26:15.30

>>189
castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。
お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた

**デフォルトの名無しさん** · 2022/09/12(月) 22:30:11.19

こんな感じです
ｌeｔｃ=６５u１６ + n
u１６[n * ２] = ｃｈar(ｃ and 0xｆｆ'u１６)
u１６[n * ２ + 1] = ｃｈar(ｃ shr ８)

**デフォルトの名無しさん** · 2022/09/13(火) 11:55:15.89

>>176
これ観ろ
https://khchen.github.io/winim/winstr.html

**デフォルトの名無しさん** · 2022/09/13(火) 12:06:13.19

言語仕様としてはモダンな言語の中で1番わかりやすいし
Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ
やはり個人開発者の言語が流行ることはもうないのか

**デフォルトの名無しさん** · 2022/09/13(火) 15:06:32.01

>>189 >>192
ありがとうございました

**デフォルトの名無しさん** · 2022/09/13(火) 16:00:02.06

アク禁？

**デフォルトの名無しさん** · 2022/09/13(火) 16:03:11.36

var ws = newWideCString(8) # ws.len == 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
# ws.len == 8
ws[7] = Utf16Char(0) # ws.len == 7
echo ws # ABCDEFG
と比べて

**デフォルトの名無しさん** · 2022/09/13(火) 16:05:36.05

なぜ拒否られる？

**デフォルトの名無しさん** · 2022/09/13(火) 16:06:26.54

驚き最小の法則ですね
var s = newString(8) # s.len == 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
# s.len == 8
s[7] = '\0' # s.len == 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:07:15.32

判ったｃｈａｒだけダメなんね

**デフォルトの名無しさん** · 2022/09/13(火) 16:09:20.44

驚き最小の法則
var ws = newWideCString(8)
echo ws.len # -> 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
echo ws.len # -> 8
ws[7] = Utf16Char(0)
echo ws.len # -> 7
echo ws # ABCDEFG
と比べて
var s = newString(8)
echo s.len # -> 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
echo s.len # -> 8
s[7] = '\0'
echo s.len # -> 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:11:32.87

インド人もびっくり

**デフォルトの名無しさん** · 2022/09/13(火) 19:05:39.59

Win土人
Nim土人

**デフォルトの名無しさん** · 2022/09/16(金) 10:37:25.88

proc testfunc(x: cint): cint {.exportc, cdecl, dynlib.} =
return x
と描かれたソースを
nim c --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されて
import ctypes
ctypes.cdll.LoadLibrary('./hoge.dll').testfunc(123)
と実行出来たのですが
nim cpp --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されているはずなのに
LoadLibrary のところで
FileNotFoundError: Could not find module '(fullpath)\hoge.dll' (or one of its dependencies).
Try using the full path with constructor syntax.
と言われてしまいます
多分 or one of its dependencies が引っ掛かっているのではないかと思うのですが
何が足りないのでしょう？ stdc++ の shared library ?

**デフォルトの名無しさん** · 2022/09/16(金) 10:57:11.84

libstdc++-6.dll
をコピーしてみましたがだめでした

**デフォルトの名無しさん** · 2022/09/16(金) 11:30:30.18

nimpy
nimodule

**デフォルトの名無しさん** · 2022/09/16(金) 13:53:03.44

>>203
objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。
使い方忘れたからググってね。
Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。
他にも依存しているdllを見れるツールは色々あるけど

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

>>206
windows用にもobjdumpあんの？

**デフォルトの名無しさん** · 2022/09/16(金) 16:24:53.42

windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました

**デフォルトの名無しさん** · 2022/09/16(金) 16:34:58.81

>>206
objdump -p hoge.dll | findstr "dll"
で出て来たのが
libgcc_s_seh-1.dll
libstdc++-6.dll
kernel32.dll
msvcrt.dll
でした
libstdc++-6.dll
だけではなく
libgcc_s_seh-1.dll
も必要でした
無事動作しましたありがとう

**デフォルトの名無しさん** · 2022/09/18(日) 09:51:11.78

>>200
https://github.com/tauplus/nim_doc_ja/blob/master/nim-meory_ja.md#%E6%96%87%E5%AD%97%E5%88%97%E3%81%A8%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9Strings-and-seqs

**デフォルトの名無しさん** · 2022/09/22(木) 10:36:47.71

import nimpy
import nimpy/py_lib as lib
initPyLibIfNeeded()
let wx = pyImport("wx")
let app = wx.App()
let frm = wx.Frame(nil, -1, "Hello, work!")
discard frm.Show()
discard app.MainLoop()

簡単杉感嘆

**デフォルトの名無しさん** · 2022/09/22(木) 15:46:35.23

こんなのや
https://github.com/khchen/wNim
こんなのも
https://github.com/simonkrauter/NiGui

**デフォルトの名無しさん** · 2022/09/23(金) 15:49:32.66

セルフホスティングくらいでけるのか？

**デフォルトの名無しさん** · 2022/09/23(金) 16:54:42.46

>>213
セルフホストってどういう意味で言ってるかは知らないけど
Nim forum自体がNimで実装されてるよ。
https://github.com/nim-lang/nimforum

**デフォルトの名無しさん** · 2022/09/23(金) 20:37:31.28

プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ
しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか

**デフォルトの名無しさん** · 2022/09/23(金) 22:00:58.25

出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ

**デフォルトの名無しさん** · 2022/09/23(金) 22:27:48.78

https://github.com/nim-lang/Nim
ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。
gccなどのCコンパイラとgitがあればソースコードからビルドできる。
ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。
それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。

**デフォルトの名無しさん** · 2022/09/24(土) 20:13:52.60

わりとどうでもいいな

**デフォルトの名無しさん** · 2022/09/25(日) 02:56:32.67

Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか
あらかじめビルド済みのCコンパイラを持ってきてビルドする
ではそのビルド済みのCコンパイラはどうやってビルドされたというのか

**デフォルトの名無しさん** · 2022/09/25(日) 08:27:58.95

たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?

**デフォルトの名無しさん** · 2022/09/26(月) 14:35:28.98

BigBangは未だ仮説だ

**デフォルトの名無しさん** · 2022/09/28(水) 12:46:44.72

toSeq(0..360|24).map(rad)
と描くと
Error: type mismatch: got <SteppedSlice>
と言われて怒られたので
toSeq(0..360).filter(x => x mod 24 == 0).map(rad)
で描き治したら一応動く訳だが
0..360|24
観たいに描く方法は？

**デフォルトの名無しさん** · 2022/09/28(水) 13:40:07.41

iterator `|`(x: HSlice; y: int): int =
みたいな演算子のイテレータを定義すればいいじゃん。

**デフォルトの名無しさん** · 2022/09/28(水) 17:12:46.81

nim 1.6.8 出た

**デフォルトの名無しさん** · 2022/09/29(木) 21:45:04.30

ウィ

**デフォルトの名無しさん** · 2022/10/02(日) 11:50:55.49

>>223
iterator items(s: SteppedSlice): int =
var c = s.a
while c <= s.b:
yield c
c += s.step

を定義したらイケました
有賀豚

**デフォルトの名無しさん** · 2022/10/16(日) 04:20:39.65

ニンニン

**デフォルトの名無しさん** · 2022/10/22(土) 14:42:48.48

本日のNimConf2022期待age

**デフォルトの名無しさん** · 2022/11/02(水) 12:51:11.01

1，2ヶ月くらい前に
Nim言語のマニュアル日本語訳がOSDNのページにアップされていて
これで5年後には結構人気が出るかもと喜んでいたら
突然ページが消滅してショックだった

キャッシュを探したけど発見できないので
コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです
(ライセンス上問題が無ければですが)

**デフォルトの名無しさん** · 2022/11/02(水) 22:26:34.03

古いキャッシュならInternet Archiveにあった
https://web.archive.org/web/20201128232605/http://nim-lang-081.osdn.jp/
https://web.archive.org/web/20200928154858/http://nim-lang-081.osdn.jp/docs/manual.html

まあキャッシュ古すぎて更新追いついてないけど

**デフォルトの名無しさん** · 2022/11/02(水) 22:33:40.08

https://ja.osdn.net/users/megumi_engines/projects/
このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね
プライベートが忙しくなったのかな

**デフォルトの名無しさん** · 2022/11/03(木) 15:08:48.38

Last Update: 2022-09-21 01:12
Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。

理由はよう判らん
githubにfork無かったかな

**デフォルトの名無しさん** · 2022/11/04(金) 07:27:29.10

日本語訳マニュアルの代わりになるかどうかはわからんけど
amazonで日本語のNim言語の書籍が売られてるよ。

**デフォルトの名無しさん** · 2022/11/05(土) 00:35:21.38

当時高校生の描いたやつか
CやC++との連携について
一行しか描かれてなかったな

**デフォルトの名無しさん** · 2022/11/06(日) 13:47:02.47

c2nim にがっかり感なんだけど
こんなもん？
それとも使い方間違ってる？
期待し過ぎ？

**デフォルトの名無しさん** · 2022/11/06(日) 16:29:46.57

単純化した具体例がないとなんとも

**デフォルトの名無しさん** · 2022/11/06(日) 16:42:07.10

わかっているのかもしれないけど、c2nimはどんなC言語のコードもNim言語に変換するものではない。C言語ライブラリをNim言語から使うためのバインディングをCのヘッダーファイルから生成するツールみたいなものだ。
c2nimに似たことができるこんなツールもあるよ。
https://github.com/PMunch/futhark

**デフォルトの名無しさん** · 2022/11/07(月) 12:40:52.04

>>230
全く使えないキャッシュだな

**デフォルトの名無しさん** · 2022/11/07(月) 12:44:41.58

>>229
3年前の nim 1.4.0だけど Nim日本語マニュアル
https://github.com/tauplus/nim_doc_ja

**デフォルトの名無しさん** · 2022/11/07(月) 13:21:56.37

ダメだこりゃ
みんなでzigに移動しよう

**デフォルトの名無しさん** · 2022/11/07(月) 14:15:04.63

いーんだよ　グリーンだよ

**デフォルトの名無しさん** · 2022/11/08(火) 12:57:20.87

template hoge(fuga: string): string =
fmt"{fuga}"

観たいなときに fuga が undeclared になるんだけどなんで？

**デフォルトの名無しさん** · 2022/11/08(火) 13:05:00.14

>>237
なるほど良さげ

Sounds great, what's the catch?
Futhark is currently in an alpha state.
It currently doesn't support C++, and it doesn't understand things like function-style macros.
It might also mess up on definition types I haven't seen yet in the small handful of libraries I've tested it against.
All of these things are things I hope to get fixed up.

**デフォルトの名無しさん** · 2022/11/08(火) 13:15:11.71

>>242 自己レス
出来ました本当にありがとうございました
template hoge(fuga: string): string =
block:
let injectedfuga {.inject.} = fuga
fmt"{injected_fuga}"
https://qiita.com/momeemt/items/000d1f6c384f4f00e103

**デフォルトの名無しさん** · 2022/11/08(火) 18:53:20.46

>>244
それは公式ドキュメントのここに書いてあるじゃないですか。
https://nim-lang.org/docs/strformat.html#limitations

**デフォルトの名無しさん** · 2022/11/08(火) 19:07:14.22

Pythonスレでテンプレになってる内容をNim用に変更したので
次スレからはテンプレにしてください

-----ここから

Nimの★ソースコードをそのまま５ちゃんに貼るとインデントが崩れてチヌ★
【【【複数の連続半角スペースはなにもなかったことにされる＆タブは普通には入れられない】】】掲示板の仕様なので、
プログラム文は↓等の、いわゆるコードうｐ用サイトに貼ってこいください。
ttps://glot.io/new/nim　　　　結構使える。
ttps://play.nim-lang.org/　　　本家。
ttp://ideone.com/　　　　　　デフォ設定はC用のため、言語選択ボタン押下がﾋﾟｺ手間かも。
ttp://pastebin.com/　　　　　まずまずシンプル。

-----ここまで

**デフォルトの名無しさん** · 2022/11/09(水) 22:27:24.03

判り初めた my Revolution

**デフォルトの名無しさん** · 2022/11/10(木) 13:14:50.85

試してみた
本家 https://play.nim-lang.org/#ix=4ftO
スッキリ https://glot.io/snippets/gf9x33imvc
ダメぽよ(実行時エラー？) https://ideone.com/9BYjHA (たまに死ぬよねこのサイト)
貼るだけ？ https://pastebin.com/07h9Zjrx

ideoneがダメなのはバージョンの問題？

**デフォルトの名無しさん** · 2022/11/10(木) 13:25:08.92

これで逝けました
https://ideone.com/HBEKZu
pragmaのNimNodeを指定出来なかったらしい
ideone の Nim は (nim 0.19.4)

**デフォルトの名無しさん** · 2022/11/10(木) 14:16:57.58

https://wandbox.org/

**デフォルトの名無しさん** · 2022/11/10(木) 15:04:27.30

↑のWandboxでも最新の安定版Nimを使えるしコードを共有できる。

**デフォルトの名無しさん** · 2022/11/10(木) 15:55:36.21

ここまでのまとめ
ttps://glot.io/new/nim　　　　結構使える
ttps://wandbox.org/ 最新のNim使える
ttps://play.nim-lang.org/　　本家
ttp://pastebin.com/　　　　　ソース貼り付けのみ

**デフォルトの名無しさん** · 2022/11/10(木) 16:23:45.65

やっぱオフサイドスタイルはクソかよ。

**デフォルトの名無しさん** · 2022/11/10(木) 16:52:41.86

>>250
wandboxだと(っていうかそれ以外でもかもだけど)
実行ボタンの上に
$ nim c ./prog.nim
って表示されてて c を cpp に変更したくても出来ない
左上の「コンパイルオプション」らしい枠に cpp を入れると
$ nim c ./prog.nim cpp
になったわ

**デフォルトの名無しさん** · 2022/11/10(木) 20:00:36.53

>>254
確かにwandboxだとnim cppでコンパイルできないっぽいね
もしかしたらgithubのwandboxリポジトリに要望を出せば対応してくれるかもしれない。もしくは自分で機能を実装してpull requestを出すか

**デフォルトの名無しさん** · 2022/11/11(金) 10:16:18.33

ここは未完成なのかな
日本語マニュアルっぽいけど
https://2vg.github.io/Nim-World/

**デフォルトの名無しさん** · 2022/11/12(土) 14:40:51.16

自分で育てる感覚楽しいですね

**デフォルトの名無しさん** · 2022/11/15(火) 13:26:12.68

type
Hoge* = object
fuga*: int
としないで
type
HogeObj* = object
fuga*: int
Hoge* = ref HogeObj
とするのは必須？習慣？
前者のデメリットは DeepCopy だというのは判るのですが
毎回後者を使った方が良い？

**デフォルトの名無しさん** · 2022/11/16(水) 09:07:52.80

{.byref.} じゃね？

**sage** · 2022/11/16(水) 13:30:51.35

横からだが
>>259 のbyrefと >>258 は完全に等価？

**デフォルトの名無しさん** · 2022/11/16(水) 15:57:06.50

proc 読んだとき ref のフリをする fake が 259

**デフォルトの名無しさん** · 2022/11/16(水) 18:16:18.08

ref objectは一つのオブジェクトを複数のオブジェクトから参照したいときや継承使ってオブジェクト指向なコードを書くときに必要となる。
それ以外の場合はrefのついていないobjectのほうが速くなることが多い。
ref型は常にヒープに確保されポインタ経由でアクセスされるけどobjectだとスタックに確保できるしポインタで間接的に参照する必要もない。
object型のseqだとメモリ上に連続して確保されるけどref object型のseqにするとメモリ上に連続して確保されるとは限らないからキャッシュミスが起きやすくなる。
ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるからコピーのコストが問題になることがあんまりないと思うよ。
C++で言えばobjectはstructをそのまま使っている感じでref objectはstructをstd::shared_ptrごしに使っている感じ。

**デフォルトの名無しさん** · 2022/11/17(木) 09:41:27.60

proc incx(i: int): int =
let j = i
{.emit: "++j;".}
result = j

echo incx(5)

https://glot.io/snippets/gfgq0p65a6
let で定義された変数も書き換え可能なんですね素敵ですね

**デフォルトの名無しさん** · 2022/11/17(木) 09:41:55.68

>>259-260
全く別物

**デフォルトの名無しさん** · 2022/11/17(木) 09:45:16.34

>それ以外の場合はrefのついていないobjectのほうが速くなることが多い。

これはどうかなぁ
遅くなることの方が多いと思うが

**デフォルトの名無しさん** · 2022/11/17(木) 10:53:32.89

>>265
どうしてrefのついてないobjectのほうが遅くなる場合が多いの?

**デフォルトの名無しさん** · 2022/11/17(木) 14:28:18.19

>>263
emit pragma使っているんだからNimの安全性は無効になる。
rustでunsafeを使うようなもの。

**デフォルトの名無しさん** · 2022/11/17(木) 15:18:49.83

>>262
>ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるから

ってことは {.byref.} 描く必要無い？

**デフォルトの名無しさん** · 2022/11/17(木) 17:33:28.89

>>268
自動でやるのは関数の引数にオブジェとを渡した時だから
それ以外にコピーが頻繁に発生しないなら
byrefいらないんじゃね?

**デフォルトの名無しさん** · 2022/11/17(木) 18:51:38.00

>>268
https://nim-lang.org/docs/manual.html#procedures-var-parameters
に
var parameters are never necessary for efficient parameter passing. Since non-var parameters cannot be modified the compiler is always free to pass arguments by reference if it considers it can speed up execution.
って書いてあります。

**デフォルトの名無しさん** · 2022/11/17(木) 19:03:15.70

>>268
https://nim-lang.org/docs/manual.html#foreign-function-interface-byref-pragma

Nim manualではbyref pragmaがForeign function interfaceの章の下にある。
つまりbyref pragmaはC/C++の関数に引数をポインタ渡ししなきゃいけないときに使うもの。
それ以外のときに使う必要性はほぼ無いってこと。

**デフォルトの名無しさん** · 2022/11/17(木) 21:39:23.14

>>265
そんな速度差気付くことある？

**デフォルトの名無しさん** · 2022/11/18(金) 05:58:57.10

君らスタックの消費は気にならんのけ？

**デフォルトの名無しさん** · 2022/11/18(金) 06:16:37.43

>>273
10kバイト以上のでかいobjectをたくさん使うとかならスタックを使わないようにref objectにしてヒープに確保してもいいと思う。
けどそんなにでかいobject型のローカル変数をたくさん使うことってあんまりないきがするけど。

**デフォルトの名無しさん** · 2022/11/18(金) 09:39:59.23

たとえば
https://qiita.com/dumblepy/items/8d13592d6760d0155d89
>オブジェクトの宣言にはref objectを使います。
>Nimでは関数の引数に入れられた変数の容量に応じてコンパイラが自動で値渡し/参照渡しを調節しますが、
>これは挙動の予測が付かずバグの原因になりえます。
>ref objectでオブジェクトを宣言していれば必ず参照渡しになるので、
>アプリケーション開発ではこちらに統一しましょう。

みたいなことが

**デフォルトの名無しさん** · 2022/11/18(金) 10:17:44.40

問題無い訳ではないとも
https://flat-leon.はてぶろ.com/entry/nim_arg_pass
バージョンや記事の年代に気を付けないといかんのかね

**デフォルトの名無しさん** · 2022/11/18(金) 11:42:20.25

古いけどここの議論は判り易い
https://forum.nim-lang.org/t/1207

**デフォルトの名無しさん** · 2022/11/18(金) 11:48:22.19

>>270
それは var の説明であって ref の説明ではないですね

**デフォルトの名無しさん** · 2022/11/18(金) 12:02:19.50

>>275
>>278
refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。
refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止

**デフォルトの名無しさん** · 2022/11/18(金) 12:10:00.28

だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。
ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。

**デフォルトの名無しさん** · 2022/11/18(金) 12:24:09.04

参照とか reference とか同じ名前だから混同してるのかも知れないが
Nim の参照型と C++ の参照型は全く別物
C++ の引数で使う参照型 & は Nim では var の方が近い
Nim の ref は C++ ではポインタ * と思った方が良い
Nim では
GC で管理されるポインタが ref
GC で管理されないポインタが ptr

**デフォルトの名無しさん** · 2022/11/18(金) 17:46:16.11

これ使うか使わないかでも全然違うのよね --gc:arc

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

最近は --mm:arc

**デフォルトの名無しさん** · 2022/11/19(土) 16:28:59.40

--mm:orc 推奨