21/08/20 09:19:57.77 o3I8mN8U0.net
>>981
ありがとう
ColumnHeadersHeightSizeMode = DataGridViewColumnHeadersHeightSizeMode.AutoSize
こうしてたのが不味かったらしくAutoSize以外にしたらちゃんと右端のもColumnHeader機能するようになった
988:デフォルトの名無しさん
21/08/21 23:10:50.06 7GAoG1Iq0.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
989:デフォルトの名無しさん
21/08/22 13:15:17.99 0Cz6ueFz0.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
URLﾘﾝｸ(nim-lang.github.io)
第二プログラミング言語として Rust はオススメしません Nim をやるのです
URLﾘﾝｸ(wolfbash.hateblo.jp)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
990:デフォルトの名無しさん
21/08/22 14:58:48.54 6XaRws1Na.net
aws lambdaにdeployしたfunctionのステップ実行ってできる？
991:デフォルトの名無しさん
21/08/24 22:42:58.40 VqhrUkYM0.net
変数って全てカプセル化して関数でアクセスするようにしないと駄目ですか？
変数がたくさんあるとき
private float hoge;
private float fuga;
void GetFuga
void BetHoge;
って関数たくさん用意するのも見ずらいと感じるのですが
992:デフォルトの名無しさん
21/08/24 22:44:31.74 /tCnVXeL0.net
プロパティがあるでしょ
993:デフォルトの名無しさん
21/08/25 03:00:37.95 ZsIr98ED0.net
>>986
気にしなくて良いよ。ダメってことはない。
理由が出来てからカプセル化すれば良いんじゃないかな。
994:デフォルトの名無しさん
21/08/25 06:59:01.74 tgvUkE6r0.net
publicにしたいのは自動実装プロパティ使おう フィールドと大差なく書ける
public float Hoge { get; set; }
995:デフォルトの名無しさん
21/08/25 07:58:42.14 6XLAMhRo0.net
他の人使わないなら、プロパティーもフィールドも変わらん。
他の人使ってないなら別にdllでアセンブリ状態で参照させてないってことだから、
必要な段階でフィールドからプロパティーに変えればいい。
呼び出し側の書き換えも要らんし。
996:デフォルトの名無しさん
21/08/25 08:17:57.51 IF2R2rJ/r.net
結局なんでそうするかって言ったら想定外の値が入ることを避けるためと修正が必要になったときに修正範囲を小さくするためだからなあ
997:デフォルトの名無しさん
21/08/25 10:50:00.29 w4zcDk6l0.net
プロパティで実装しておくとVS上で何か所から参照されているのか表示されて
その参照場所へ簡単に飛べるようになるから個人開発でもお勧め
998:デフォルトの名無しさん
21/08/25 10:54:21.96 8yGiroeZd.net
個人で開発するなら入力チェックしなくて良いと思う。
見せかけだけのプロパティとか、そういう場合が多いかな。
999:デフォルトの名無しさん
21/08/25 10:55:37.16 sdRC5LrgM.net
機械的にプロパティやアクセサメソッドを実装するのはやめたほうがいいよ
面倒だと感じる時点で設計を疑ったほうがいい
DBのエンティティクラスみたいなのを除けば、本当にクラス外に公開する必要のある変数って極僅かなはず
1000:デフォルトの名無しさん
21/08/25 11:03:46.23 dGOrb7NRM.net
>>994
そんなことねーだろハゲ
処理1-24までの出力が全部必要な
処理25とか普通にあるだろ
その時処理1-24の閉じられたクラスのプロパティが全部必要になるとか普通によく見るわ
お前はないの？
経験値が足りないんじゃない？
1001:デフォルトの名無しさん
21/08/25 11:49:57.68 sdRC5LrgM.net
>>995
リファクタすりゃいいんじゃない？
まあSIみたいだから後で弄るのは難しいのかもしれないけど
1002:デフォルトの名無しさん
21/08/25 12:22:10.74 uVderaMI0.net
privateなフィールドとプロパティどちらにするか迷ったけど、
プロパティにしとけばgetとset別々に検索できるから便利だと気づいた。
1003:デフォルトの名無しさん
21/08/25 15:24:05.86 ZkAj8L4Pa.net
無意味なsetが後々悪さをすることがある
>>990
の言う通り他の人が使うか使わないかで左右されるが、３ヶ月後の自分はほぼ他人だったりする
1004:デフォルトの名無しさん
21/08/25 19:45:50.20 tgvUkE6r0.net
次スレ立てられた
ｽﾚﾘﾝｸ(tech板)
1005:デフォルトの名無しさん
21/08/25 19:53:31.05 2EffLwye0.net
また逢う日まで
1006:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 101日 9時間 7分 32秒
1007:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています