俺個人の勝手な予想では
マイクロソフトはOS事業からの撤退の準備を始めてるんだと思うよ
VSの64ビット化って具体的に何がうれしいの？
メモリ馬鹿食いになるだけじゃん
> メモリ馬鹿食いになるだけじゃん
RAMとHDDを大量に売りつけるのが64の真の目的だからな
やっぱりメモリ消費が少ない地球に優しい16bitに皆戻るべきだよね
>>9,12
だってMicrosoftが独自にOS開発続ける明確な理由が
もうなくなってきてるでしょ
Linuxへ移していくための準備に思えるわ これまでのWindows資産バッサリ捨てられるわけないやろ
>>6
Ｘ 俺個人の勝手な予想では
〇 バカの妄想では >>14
Linuxは、いろんな意味で全然Windowsと同じ土俵に立ててない。
今までを考えると、これからもたいして変わらない。
そんなものにユーザーが移るわけがないし、Microsoftがそれを期待するわけもない。 >>15
ばっさりとは行かないから
連携とかマルチプラットフォーム化やってるんでしょ
Windowsにメリットがあって辞める必要もないなら
WSLだっていらない気がする Windowsでどれだけ稼いでるか少しは調べてから現実を見ようね
WSLはプログラマー需要を少しでもWindowsにも取り込もうとしてるだけに思えるが
前スレのJavaの話題でふと思ったけど、ドザ個人的な使用範囲では.NETなソフトは
たくさん使っているけどJavaなソフトはMinecraftしかないわ
Minecraftも最近全然やってないんだが、Javaランタイムの更新通知がこないだ
表示された時に、長いこと使ってないみたいだから消せば？みたいなメッセージ
が出てた
俺の使用範囲が狭いのは置いといて、どこでJavaが活躍してんの？
Androidくらいしか知らん
Microsoft製品関係だとSQL Serverのデータ仮想化PolyBaseやDevOps Serverのコンテンツ検索ElasticSearchなどでJavaは必須
現状ではAzul SystemのZulu OpenJDKがデフォルトでインストールされる
失礼します
visual studio 2019 でWindowsアプリケーションのフォームにメニューバーを付けようとMenuStripドラッグ&ドロップしたのですが「ここへ入力」が表示されません
表示するための解決法はありますか？
>>28
16%ちょい、収益構造はなかなかいいバラスを保ってる
>>29
サーフェスってBingアドインより売れてないってマジ？ まあ売れてないって言っても6ビリオンドルだから6,000億は超えるけどね
Ads は Addin ではなくて Advertisings
いわゆる検索ページからの広告収入だろう
>>13
それは違う。
16BITの8086系では、セグメントアドレスを買えずに一度に扱えるメモリは
64KB に制限されていたが、それではほとんどのGUIのアプリでは足りなかったので
far pointer や huge pointer を使うのが広く行われていたから、16BITの
アドレスでは足り無い事が明らかだった。
ところが32BITのアドレスでは未だに2GBのメモリーで足りなくなるアプリは
ほとんど存在し無い事が知られている。 >>34
誤: 16BITの8086系では、セグメントアドレスを買えずに一度に扱えるメモリは
正: 16BITの8086系では、セグメントアドレスを変えずに一度に扱えるメモリは
少なくとも8086系の16BIT CPUでは、フラットにアクセスできるアドレス範囲
が狭すぎて、本格的なGUIアプリを作っているプログラマーはとても苦労していた。
huge pointerを使えばずっとアドレス範囲が広がるが、とても遅くなるので積極的
に使うのは避けられていた。far pointerは、セグメントアドレスを変えなければ
一度にアクセスできるのは 64KB までだったので、使いにくかった。
一度に使えるアドレス範囲が 32BITになることは劇的にプログラミングがし易くなった。
ところが、64BIT化しても、このような激的な利便性の向上は起きない。 Z80全盛時に8086憶えたけど
第一印象「オマエ、ソレハナイダロウ」だった
>>35
知らんがな。ｗ
そんな、クロックは今の数百分の一、キャッシュメモリもなかったような時代のことなんか。
提供する側ならともかく、提供される側が主張するようなことではない。 >>38
「Outportによる一部の領域のバンク切り替え」から
「CPUによる一般化されたバンク切り替え」に変わっただけという感じだった。
まだアドレスが、
絶対アドレス = 上位16BIT * 65536 + 下位16BIT
だったら良かったのに、
絶対アドレス = セグメント値 * 16 + 下位16BIT
という変な分け方がされていたのも最悪だった。 >>39
しかもセグメントレジスタが、汎用レジスタではなかったので
addなどの演算が直接的には出来なかったのも痛かった。 >>39
> 絶対アドレス = 上位16BIT * 65536 + 下位16BIT
それやるとページが64kB単位になるからページをまたがる処理がめっちゃ面倒になるぞ
今みたいに多少メモリーが無駄になってもいいやっていう時代ならいいけど物理メモリーにきちきち詰めていくとどうしても複数ページにまたがる領域ができてしまう >>39
境界またがってアクセスするときに後者の方が便利だ(と当時は思われた)からだろう >>42
現実にはアセンブラで書いた場合ですらそんな使い方が必要になる経験をしたことは無かったな。
Cで書いたらそういう機能はもっと不要。 8086のアドレスバスは20本(最大メモリ空間1MB)
16ビット長のレジスタでアドレス指定するためにセグメントレジスタで4bitシフトさせた上でオフセットと加算するという手法を採用した
8ビットCPU開発者からの移行を考えれば当時としては合理的な設計ではある
CPU設計者はハードウェアよりで考えているのかも知れんが、
マシン語プログラミングを沢山経験積んだ一目線で見ると、
>>39 の前者の方になってる方が断然が使いやすかった。
8086よりマシン語が人気だったZ80は、ある意味では前者。
アドレスは、16BIT レジスタ HL, DE, BC, IX, IY に入れられるが、
HL は、8BIT レジスタの H と L が2つ組み合わさったもので、
HL = H * 256 + L
の関係が有った。
これは物凄く便利だった。 >>47
自分の理想としてのきれいさとかアドレスのわかりやすさにひっぱられすぎやろ。ｗ
実際には、セグメントレジスタをベースにしたら、実アドレスは忘れてオフセットで考えればよかったんだから、具体的にそんなにわかりにくいものでもない。
まあ、知らんけど。 >>48
マシン語には、せっかく carry flag という便利なものがあって、
16BIT レジスタを2つ使って 32BIT アドレスの足し算、引き算がとても
高速に出来る。例えば、DX:BX で 32BIT アドレスが表現できていたなら、
add BX,4
adc DX,0
のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
だから、ds:[BX] などとせずに、[DX:BX] と書くことが出来ていたなら、
物凄く便利だったはず。 アドレスが32ビットに拡張されたのはi386から
ページングと仮想記憶が導入されてやたら複雑化したけど
＞。ｗ
またこのアホが舞い戻ってきたか
知らない話題に首突っ込んで否定するだけの中身なしの阿呆
>>44
セグメントの考え方を理解してないだけじゃね？
セグメントはページとは違って論理的な領域でそれを物理アドレスの何処に置くかをセグメントレジスタで指定してるだけの話
>>49
> add BX,4
> adc DX,0
> のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
それ毎回やるの？
すげー遅くなるよ >>51
「否定」？ｗ
ただの指摘やで？
「阿保」とか自己紹介もほどほどにな。 >[DX:BX] と書くことが出来ていたなら、物凄く便利だったはず。
これは判らんでもないが当時は貴重なレジスタがもったいない
VS2019スレで昔話するのやめてもらっても良いですか昭和生まれさん
プログラマー板でやれよ
>>52
>> add BX,4
>> adc DX,0
>> のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
>それ毎回やるの？
>すげー遅くなるよ
実際には、BYTE huge *ptr; に対し ptr += 4 を実行するともっと複雑な
例えば以下のようなコードにするしかなかった。もう少し高速なコードも
作れるかも知れないが、一番単純に書いた場合、
例えば、ES:BX が ptr に相当するとして、
xor cx,cx
add bx,4
adc cx,0
shl cx,12
mov ax,ES
add ax,cx
mov ES,ax
つまり、[DX:BX]方式なら2命令で済んでいたところが、SEG:[BX]方式しか使えなかった
8086は、7命令も必要となった。
だから、8086はZ80より設計が悪いとされた。 >>52
>セグメントの考え方を理解してないだけじゃね？
>セグメントはページとは違って論理的な領域でそれを物理アドレスの何処に置くかをセグメントレジスタで指定してるだけの話
むしろ、日本の中でも数人レベルで理解してると思ってるが。 >>54
その通りではあるが、それは霊で書いただけで、DXの変わりに
[DS:BX]や、[ES:BX]
と書けて、なおかつ、
adc DS,0 や adc ES,0
のような命令が有るだけでも大変喜ばれていたはず。 >>56
なお、8086は、shl reg16,imm という命令は無く、shl reg16,clを
使う必要があったのでさらに1命令増えて全体で8命令となる。短くしたいなら、
BYTE huge *ptrをES:[BX]でアドレッシングするとして、ESの下位12BITは
使わずに必ず0になっている約束にしておいて、
mov cl,4
mov ax,ES
rol ax,cl
add bx,4
adc ax,0
ror ax,cl
mov ES,ax
とすれば、7命令で済む。 >>54
なお、8086はバレルシフタが搭載されてなかったので、shl reg,clや
rol reg,cl, ror reg,cl 命令は、cl の回数だけCPUの中で実際に繰り返して
シフトやローテートを行っていたので、clに4を指定すると4*4=16
クロックほど必要だった。
だから、>>59 は7命令のように見えても、実際には、合計8回分の
ローテートを含んでいるので13命令を実行する程度の時間が掛かる
ことになる。
これが8086の設計の悪さである。 >>61
8086系においての 16BITから32BITへの進化は 32BITから64BITへの進化
に比べて遥かに重要だったという事を知って欲しいため書いている。 >>62
アーキテクチャの話なら286のプロテクトモードの話
すっ飛ばして何の意味があるのかね？ >>56
いや、セグメントなら領域のサイズが64KB以内とわかってるならそんな計算は不要
ページだと小さいサイズであってもページまたがりを考慮しないとダメだから常に
> add BX,4
> adc DX,0
が必要になるって話
>>57
> むしろ、日本の中でも数人レベルで理解してると思ってるが。
数人レベルで誤解してるの間違いだろw あー、もしかして8086のセグメントと286以後のセグメントを混同してるのかな
zobがこの間、技術書展(4?)で薄い本出して
いただろ。
数人しか理解してないなんてマウントの
材料にするような話では無いな
>>57
> 日本の中でも数人レベル
あー、そういうおひとの書き込みななんか。ｗ
もうマジメに相手しないほうがええな。 子供のころにアセンブラの経験をしてない平成生まれはかわいそうだがプログラマに向いてない。
Java連呼してる奴もそうだろう。あんな糞言語にあっさり洗脳されるなんて。
これだけは言える。Java使いは低能ばかり。
そもそも一番Javaの普及に貢献したMSとgoogleを訴えまくってJavaから撤退させたアホ集団。
>>78
Sun/Oracleのゴールは、Javaの普及やないんやろ。
それはそれで一理。
まあ、今から考えると、あんなものが普及しなくてよかった。ｗ わりとまじめに聞いたいんだが
キチが住みついてないスレって、あるのか？
SQL Server 2019 Developer
Azure DevOps Server 2020 Express
>>81
キチにもレベルっつーもんがあると思うんだ… アセンブラ界の沼は深いぞ
日本で屈指のレベルとか自称するような奴はまだ沼にたどり着いてすら居ない
google,ms
これからはrust推しでいくよー
google→androidのコードをrust化
ms→vsにrustは入れません！
いつも口だけで何もやらないマイクロソフト
>>85
それは短絡的だろ
googleが自分らが入れるから
msより自分らを優遇して欲しいって
交渉しないわけがないんだよ
そうなるとmsサイドとしてもえーってなっちゃうじゃん
こういうのってそういうものよ >>85
だからこその後方互換性の高さっつーのもあるやろ。
vscodeからでええんや！ GoogleだってAndroidよアプリ開発にRustが使える訳でもないし
そもそもRustはまずRust for Windowsが安定化しないとわざわざVisual Studioでインストールできるようにする必要性もない
>>88
タイポ
Androidよ→Androidの >>85
わざわざ既存のコミュニティを壊しにかかるとしたらそれこそアホやろ MSはすでにカーネルの一部をrustで書いてるとかゆーのどこかで読んだ気がしたけど
>>86
>googleが自分らが入れるから
>msより自分らを優遇して欲しいって
>交渉しないわけがないんだよ
>そうなるとmsサイドとしてもえーってなっちゃうじゃん
ここ、意味が分からない。
優遇って、誰がだれを優遇するの？ どのプロジェクトにも頭がおかしい奴がいて勝手にマイナー言語使ってドヤ顔するアホがいる。
それをもってMSはJava押しだのrust押しだの言い出すバカがいるから困る。
いや、でもRustはホントによさそうなんだよなあ。。。
ためしにcargoをインストールしてみ？
rustをマイナー言語とか言ってる時点で注意せんともう化石状態やで
アップデートで勝手にアジュールインストールするなよ。
>>100
公式セミナー出た事無いね！
貴方には人脈が足りないわ IIS (Web Server)
SQL Server
DevOps Server
Visual Studio関係で手元に置いておくならこれくらいか
Azure出始めの時は日本MSの人が英語読みでアジュアって言ってたけどしばらくしてアジュールになったね
C++で実装して、Windows10 64bit用のDLLや実行形式exeをビルドする場合、
どのバージョンのVisual Studioを使うのが効率的で確実なんだろ？
2019？それとももっと古いVSの方がいいのかな？
新しいバージョン恐怖症なもんでｗ
>>108
VCランタイムが2015,2017,2019で共通になって(2019のアップデートに伴い)頻繁に更新されるから
古いバージョンを使うことによるライブラリが原則更新されないというメリットがなくなった >>109
早速ありがとう。
実は、VC++2005で【ヒープ割り当て→計算、描画処理→ヒープ解放】を繰り返し行う、.DLL＋.exe を実装してるんだけど、
その .exe+.DLL をWindows10 - 64bitで走らせると：
１）VC++2005、Debug Win32ビルド → 問題なし。exe起動後、【ヒープ割り当て→計算、描画処理→ヒープ解放】を何回でも反復できる。
２）VC++2005、Release Win32ビルド → exe起動後、【ヒープ割り当て→計算、描画処理→ヒープ解放】を100回繰り返したあたりで、固まる。エラーは出ない。VC++をプロセスにアタッチしてデバッグすると、無限ループに陥っている模様。
３）VC++2005、Release x64ビルド → 上の２）に同じ
４）VC++2005、Release x64ビルドの.slnを、VC++2005の「デバッグ開始(F5)」から実行する → １）と同じく問題なし。
５）VC++2005、Release x64ビルドの.exeを「Windows 7の互換モード」で実行する → １）と同じく問題なし。
てな具合で、Windows10主流の今、大概VC++2005も潮時かなｗって思ってるｗｗｗ
それとも俺のプログラムにどこかエラーがあるのかな？！
_DEBUGディレクティブ周りは何回も見直したんだけどなぁ。 その問題を逆手に取ってシステム攻撃可能なコードにでもしたらセキュリティの問題として修正せざるを得ないんじゃない？w
>>110
おまえのエラーであるほうに賭ける！
でも、コンパイラの不具合もたしかにあるからなあ。ｗ >>111
自己レス
よくよく思い出せば、自分が問題を確認した時のバージョンはvs2017だったからvs2013に戻してた
という経緯だったので、>109そのまま受け取れば個人的には問題無さそう
というか、vs2013とvs2015の間に壁があるのかな？
>>110
とりあえずvsのバージョン変えてテストしてみればいいと思う >>110
なにやら騒がせてしまったが、無限ループに陥った原因は、どうやら俺のプログラムミスだったっぽい。
ビルド方法や実行方法や互換モードの違いで、プログラム挙動が変化する理由は不明だけど。
またおとなしくROMってるわｗ
結論：
ま だ ま だ VC++2005 は い け る ！ ！ ！ >>108
VS2019を入れれば問題無い
ちなみにインストールするときにオプションで
VC2017コンパイラとかインクルードファイルとかライブラリとかの環境も
それ以前のも一緒に入れるとか選べる
あとでbuild環境を選択すれば良い >>110
>>116
概出だから知ってるだろうけど
デバッグモードだけ成功するパターンは
初期化し忘れとかヌルポとかが多い visual studio code を使い始めたのですが、固まることが多く使い物になっていません。
推奨スペックを教えていただけないでしょうか？
メモリ４Gではダメでしょうか？
>>119
4Gで固まるんだ
開発するなら8Gはあったほうが良いかと
今時のPCならそんなに問題起きないけど結構古いPC使ってない？ >>119
環境を書かないで、vs codeが使いやすいという人が多くて混乱するよね。
ggってもどのくらいのスペックでまともに使えるかの情報が出てこない。
例えばYouTubeで動作してる動画があったとしても、まず環境が書いてない。
Androidエミュレーターでもそうだ。試して見ると極端に遅いのになぜかYouTubeでは
高速に動いてる動画があり、環境は書いてない。スパコン上のLinuxで
Wineエミュレーター上でAndroidエミュレーターを動作させている可能性すらある。 Ruby on Rails, WSL2, Docker Compose, Node.js,
VSCode(拡張機能・Remote WSL, Remote Container)
今は未経験者でも、こういう技術。
10年以上のプロよりも、技術力は上！
メモリの最低ラインが、Windows 10 で16GB、Mac で32GB。
Windows でも、32GB あった方が良い
メモリ8GB じゃ、Windows/Linux, Docker, Rails、データベースを動かすのは、キツイ
ここはvscodeのスレじゃないのでどっちにしろスレチ
120<<< 中古です
東芝ダイナブック satellite pro 550Bです。
>>117
ありがとう。VS2019も検討してみる。
>>118
ヌルポインタやらかした場合、そのポインタのメンバに触った瞬間に実行時エラーにならないこともあるんかな？！
>>110は何とか解決して、今はVC++2005のReleaseビルドでも、Win10上でヒープ割り当て→処理→ヒープ解放を何回でも反復できるようになった。
無限ループが発生しないように、問題のループを実装から取り除く改修を行って解決した！ 自作のミニツールをプロジェクトごと公開したい場合、削除しておくべき不要なファイルって何があります？
必要なもの以外すべて。
ソリューションファイル、プロジェクトファイル、ソースファイル、リソースファイル以外。
つーか、必要最低限そうなファイルだけcommitして、それをexportして、もしビルドに失敗したら足りないファイルを追加して、を繰り返せば。
visual studioがデフォルトで生成する.gitignoreに従えば大抵は事足りるでしょ
よほど特殊なライブラリとか使ってるんじゃなければ
自分で作ったヘッダとソースとリソースだけあればOK
ソリューションとかプロジェクトは新規で突っ込んでも逝ける状態のが理想的でクリーンな公開
新規ソリューションのデフォルトフォルダってsorce\repos\ソリューションフォルダだと思うだけどさ、このreposって何か意味あるのかな？
sorce直下にソリューションフォルダ置くのと変わらなくない？
repos直下をgitのルートにすることを想定してんのかな？
>>135
reposはリポジトリの複数形なんだからreposのサブフォルダーがgitのルートになるんだよ source直下はreposしかないって事だよね？
sourceかreposいらなくね？ 片方でよくね？ 無駄に階層深くなってるだけの気がするんだけど
何か他に、sourceに置くことが想定されるファイルあるの？
ああVslsFileSystemProviderVSCorePackageのエラーうぜぇ。なんで直すのが16.10なんだよ。
来週なの？意外と早いね。16.8が11月で16.9が3月だからまだ先だと思ってた。
XBOXコントローラーでVisual Studioを操作したいです
Visual Studio 最新版 (16.9.4)
C++で new char[サイズ(即値)] と書くと
サイズの上位32bitが消されて正しくアロケート出来ない
たとえば、new char[0x100000000ll] とやると new が 0 バイトで呼ばれる
おま環？
std::size_tにキャストされているからでは。
64bit環境なのでsize_tも64bitです。
uint64_t size = 0x100000000ull;
new char[size];
とやっても同じで、
コンパイラ上定数として扱える場合には上位がカットされ、
サイズが変数やテーブル参照のような場合には正しくアロケートされるようです。
以下コンパイル結果
--------
char* data_ = new char[0x100000000];
00007FF63F38310D xor ecx,ecx
00007FF63F38310F call operator new[] (07FF63F3811E5h)
--------
char* data_ = new char[0x110000000];
00007FF66238310D mov ecx,10000000h
00007FF662383112 call operator new[] (07FF6623811E5h)
--------
operator new()ならどうなる？
個人的には、配列要素数に32ビット制限があっても、そんなにおかしいとは思わんなあ。
operator new, operator new[] だと大丈夫
--------
char* data_ = (char*)operator new(0x100000000);
00007FF70520310D mov rcx,100000000h
00007FF705203117 call operator new (07FF705201046h)
--------
char* data_ = (char*)operator new[](0x100000000);
00007FF7CA02310D mov rcx,100000000h
00007FF7CA023117 call operator new[] (07FF7CA0211E5h)
コンパイラのバグ(仕様？)なのかなぁ
ツールセットをLLVMに変えると配列でもrcxレジスタを使うね
やっぱそうか。
じゃあコンパイラが期待する配列添字定数の型が32ビットなんやろ。
VCはintきめうちのところがときどきあるような。
今は知らんけど、昔はenumがそうだった。
6.7.2.2 Enumeration specifiers
3 The identifiers in an enumerator list are declared as constants that have type int and may appear wherever such are permitted.
6.7.2.2 列挙型指定子
意味規則 列挙子並びの中の識別子は，型int をもつ定数として宣言され，この型の定数が許されるところならばどこに現れてもよい。
はっきり、intと書いてある
今のVSにはclang-clが提供されているけど、これでカバレッジとれている人いないかな？
--coverage 付けて clang_rt.profile リンクしてビルドまではできたんだけど、実行すると
終了時にexit()の中で例外を吐いてしまう。
> 昔はenumがそうだった。
> Cの話は関係ない。
何の話？
>>154
そらC++やろ。
Cとは意外に違うんやで？ C++/CLIがいらんことしやがって
enum class なんてものが
>>140
それ書いた時、なんで来週と思ったか思い出せないんだけどw
多分16.5(2020.3/16)と16.6(2020.5/12)の間が2ヶ月だったからかな
でもリリース周期見ると必ずしも期間決まってるわけじゃないみたいだから、今週かわからんわ
先に謝っとく。ごめんw
16.0 2019.4/2
16.0.22 2020.1/22
16.1 2019.5/21
16.1.6 2019.7/9
16.2 2019.7/24
16.2.5 2019.9/10
16.3 2019.9/23
16.3.10 2019.11/10
16.4 2019.12/3
16.4.21 2021.4/13
16.5 2020.3/16
16.5.5 2020.5/12
16.6 2020.5/19
16.6.4 2020.7/14
16.7 2020.8/5
16.7.14 2021.4/13
16.8 2020.11/10
16.8.7 2021.3/9
16.9 2021.3/2
16.9.4 2021.4/13 >>156
enum classはC++11以降でも実装されてるけど >>158
？その仕様の元がCLIなんだが？
前後の繋がりが読めない人？ >>145
「00007FF63F38310D xor ecx,ecx
00007FF63F38310F call operator new[] (07FF63F3811E5h)」
ここが既におかしい。64BITアプリなら、ecx ではなく rcx でなくてはならない。
147 の方は実際にそうなっている。
ecxは32BITレジスタ、rcxは64BITレジスタ。
また、ecxやrcxは、メンバ関数の関数呼び出しに置いてはthisの値を入れるために使われるレジスタ。
なので、前者のnewは32BIT版が呼び出されていて個本的におかしい。
本当に何もかもが64BIT版になってるか点検すべき。 >>162
ただし、new char[N] の変わりに operator new[N] とすると正しくなっているのは良く分からない現象。
コンパイラオプションに問題が有るか、または、コンパイラのバグ。 >>164
以下のように、配列サイズがコンパイル時定数にされてしまうのを無理やり防ぐといけるらしい：
extern size_t GetArraySize();
int main()
{
size_t allocationsize = GetArraySize();
char *cp = new char[allocationsize];
return 0;
}
size_t GetArraySize()
{
// compile time assert to validate that size_t can hold a 64-bit value
char compile_time_assert_64_bit[(sizeof(size_t) == 8)?1:-1];
size_t allocsize = 0x100000000UL; // 64-bit literal
return allocsize;
} >>145
00007FF66238310D mov ecx,10000000h
00007FF662383112 call operator new[] (07FF6623811E5h)
147
char* data_ = (char*)operator new[](0x100000000);
00007FF7CA02310D mov rcx,100000000h
00007FF7CA023117 call operator new[] (07FF7CA0211E5h)
よく見ると、これら二つで、call文の呼び出し先のアドレスの下位16BIT
は、共に11E5 になっていて、上位アドレスは変わっているが本当は
同じ関数を呼び出しているようだ。リンクするとアドレスは上位も下位も変わることがあるが、
上位アドレスだけ変わる現象としてはセキュリティー対策のためと聞いている。
それで、mov 文が ecx と rcx の違いがあるが、実は mov ecx,imm 命令は
上位32BITが0拡張されるので mov ecx,10000000h は、
実際には、mov rcx,0 と同じなので、145の方は、動作的には
mov rcx,0
call operator new[] // 64BIT 版の new 演算子
となっていて、145もちゃんと 64BIT版の new 演算子が呼び出されているようだ。
問題は、new char[x]のxに定数が有ったときに下位32BITだけに切り捨てられてしまう
コンパイラの動作にあるようだ。 VS2010からのバグですか
早く直してください
>>147
コール元が原因だとわかるようにコンパイル結果を貼ったつもりだったんですが...
そもそも64bitアプリから32bitコードはコールできない >>156
それ以前は、真面目なソースでは重複事故防止のために、わざわざ全要素にenum型名をつけてたからな。
最初からそうなっていてよかったレベルに、もっともな改善だった。 >>166
訂正。桁が大きすぎて1ケタ見間違えた：
上位32BITが0拡張されるので mov ecx,10000000h は、
実際には、mov rcx,10000000h と同じなので、145の方は、動作的には
mov rcx,10000000h
call operator new[] // 64BIT 版の new 演算子
そして、xor ecx,ecx の方が xor rcx,rcx になり rcx = 0 となる。 >>169
enum毎にnamespace?
お前アホだろw >>170
リンク先を見つけて頂いて非常に感謝いたします。
それ以外の事は既に知っていますので大丈夫です。 新機能が無いと管理出来ませんって
プークスクス向いて無いんじゃね？
>>176
新機能がないと管理できないの？ｗ
バカなの？ｗ /std:c++20 ｺﾈ━━━━━('A`)━━━━━━!!!!
Visual Studio 2021 はまだかよ？
もうはよ出せよ
オフラインインストールだから中途半端なバージョンはインストールしたくねぇ
何百年待たせるんだよ
中途半端言うてるのは2019 16.9.5みたいなバージョンだっちゅーの
2021 1.0.0出せ、ほらはよ、お兄さんは急いどんねん
>>185
なんだ、もう17年かぁ
・・・って待てるか、ヴォケ！ VS2021はversion17なので17.0.0
>>187
あら、そうだっけ？
じゃ、VS2021 Version17.0.0、お急ぎ便でリリースしてくれ 今、Version16.3.Xを使ってんだけど、
ソリューション（Aと呼ぼう）をフォルダごとコピーしてからVS起動すると、
コピー元のソリューションで開いてたプログラムがそのまま開いてて
「親切やん？」とか思いながらそれらのプログラムを修正すると、
コピー先の新しいプログラムじゃなくて
「元のソリューションAの（！）」プログラムが書き換わるんだよな
どこ参照してんだよ？
つまりバグだ
だから、コピー後にプログラムが開いてたら
手動で全部閉じてもう一回開き直さんといかん
おまいらも経験あるだろ？
クソ面倒くせぇ
家のPCは最新版にしてあるから
コピー後に起動すると全部のプログラムが閉じた状態から始まるんで、この事象は起こらんけどな
こんなしょーもないバグを作り込みやがって
ちゃんとテストしてからリリースしやがれ、マイクロソフトのクソが！
Visual Studio 2022 Preview 1が夏に出るのを知った上で
Visual Studio 2021を出せと言ってるの?
>>190
うそーん？
今までずっと奇数で2飛ばしで来たやん？
でも夏に2022 Preview出るのん？
ちょっと期待アゲアゲだな
>>191
しばき回すど、ゴルァ！ >>192
visual studio 2002 は奇数では無いような >>193
誰がそんな大昔の話しとんねん？
俺の中でVisual Studioの歴史は2013から始まっとんのや！
規律を乱しおってからに・・・ バージョンなんかどーでもいいんだけど次はどんな目玉機能があるんだ？
2019はInteliCodeだったじゃん？2021はやべー機能あるの？
4GB超のソースファイル処理できるんじゃね？
知らんけど。
>>189
それ当然やん？
フォルダ毎コピーしてんだから参照の情報もコピーするわけで >>199
どんだけ馬鹿なんだよ？
なんで絶対参照してんだよ
相対参照すりゃいいだろ
お前は引っ越した後も
前のマンションの風呂に入りに行くのか？ >>201
引っ越ししたら更新するだろ
相対参照は脆弱性の元 >>201
お前は引っ越した後は
通学先/通勤先をずらして変えるのか？ なるほど
>>189 は
コピーしたプロジェクトのパスの問題じゃなくて
自動で開いて始まる機能がおせっかいだったと主張しているに過ぎないのな >>192
2008
2010
すぐ思いつくだけでも >>202
> 引っ越ししたら更新するだろ
じゃ、参照情報も更新しろよ、ヴォケ！
「フォルダ毎コピーしてんだから参照の情報もコピーするわけで」と書いたのは一体どこの馬鹿だったっけ？
それに従うと「更新」じゃなくて「コピー」せんといかんのだが？
てめぇの言ったことと矛盾してることにすら気付かないほど馬鹿ということは判った >>203
そこを相対参照にしてどうする？
通学先/通勤先は「マンション」の中には「無い」
そこは絶対参照でいい
今の世の中、こんな馬鹿がプログラム組んでんのか？
そりゃみずほ銀行も不具合起こすわ >>206
俺は絶対参照前提で話してるんだぞ
コピー後更新するのは自分だろ >>204
ほぼ正解
正確には、自動で開いて始まるなら正しいパスで開いてほしい
しかし、正しいパスで開けないなら自動で開いて始まる機能はお節介 >>210
ツール
->オプション
->プロジェクトおよびソリューション
->全般
->ソリューションの読み込み時にドキュメントを再度開く
これをOFFにせずにバグバグ言ってんの？ ID:872BWcRl0
都合の悪い>>200は見えない見えない >>208
> コピー後更新するのは自分だろ
自分で更新させるならさせるでいいが
前のマンションの水道代の請求書を送ってくんなやって話だ
>>204はちゃんと問題点が把握できているのに対して、
>>208との馬鹿さ加減ときたら・・・
同じプログラマーでも要件獲得の時点でこんなに差が出るんだな >>209
お前は良いとこ突いた
確かに、マンションの外＝絶対参照ではないな
ただ、通勤先というのは相対参照には向かないな
必ず隣の家で働くこと、とかいうルールでも無い限りな >>211
その設定は知らなかった、感謝する、ありがとよ
しかし、
①それをデフォルトにせぇよ（今の版ではデフォルトになってるが）
②「ソリューションの読み込み時にドキュメントを再度開く」にしたら、なんでコピー「先」のプログラムを開けよ
とだけは言いたい
②は明白にバグだから、バグバグ言わせてもらう >>215を訂正： ②「ソリューションの読み込み時にドキュメントを再度開く」にしたら、コピー「先」のプログラムを開けよ >>212
ちゃんと>>200は見えとるわ
その更新が大仕事になるんで早く新しいメジャー・バージョンを出せよ、という元々の主張に立ち返るわけなんだがよ
容量の問題だけで言うと、前回32GBぐらい要したから、容量を空けないといかん
オフラインインストールだから、丸一日潰さんといかんという時間の問題もある
それと、俺が都合良い／悪いで見えないとか言うわけねぇだろ、まったく・・・
ところで、>>205にはなんて書かれてんだ？
これだけ見えない >>217
リリースされたばかりだとデカいバグ満載で、ある程度落ち着くまで
バージョンアップを繰り返して時間かかるはずだけどそれは構わないの? というかバージョンアップもせずに古いバージョン使い続けてバクバク言ってんのギャグにしか見えない
低速回線なのかな
未だにADSL1.5Mの奴がいて4GB落とすのに1日かかるそうな
光ならダウンロード5分ほどですぐ終わる、というかこれがデフォだな
>>222
1.5Mbpsが安定して出るなら６時間程度で終わるよ
もしかして算数不得意なのかな？w >>223
ADSLで最大スループットが常に出るわけないだろ >>218
どんだけお人好しなんだよｗ
>それと、俺が都合良い／悪いで見えないとか言うわけねぇだろ、まったく・・・ ←こんな大きな前振りして
>ところで、>>205にはなんて書かれてんだ？
>これだけ見えない ←ここまでボケてんだから
がっつり突っ込んでくれよｗ >>219
構わない
そりゃまたバグバグ言わせてもらうけどさｗ
バージョン16.x.xの集大成として17.x.xを使いたいんだよ
そのぐらいのバージョンアップでなきゃ、やる気が出ない >>220
コピー後に自分で更新するのはいいが
あたかも「自動で更新しときましたよ、兄貴」的にコピー元のコードを表示すんなよって話
でもね、お前がその設定教えてくれたお陰で、しばらく更新せんでもええかな
このバグがうざかっただけで他は我慢できる
いろいろありがとな、今度ケツ貸すわ
>>221-224
まぁ、大人の事情ってことよ >>227
そこはもう「再度」なんだからって割り切ってOFFにするしかないかな
おうちゃんと洗って返すわ >>227
そういえば Access のテーブルリンクなんかは移動されたのを見るか元のを見るか選べたりした
どっかのバージョンでその機能が消えてた気もする C++のプロジェクトで、何も変更がない状態でDebugビルドするとなぜか再リンクされて出力のバイナリが
更新されてしまうんだけど、原因は何が考えられますかね？Releaseだとそういうことはないんですが。
ちなみにオプションでMSBuildのログ出力レベルを詳細にすると、更新されていないはずのobjが
新しいものと認識されているっぽい。
33> ソースのコンパイルが必要です。入力 C:\....\XXX.OBJ は出力 よりも新しいです。
この ｘｘx.obj のタイムスタンプは別に更新されていないし、上のログの「出力」のところはファイル名が空で、
何と比較して新しいとされているのか見てもわからりませんでした。
あと怪しそうなところとしてインクリメンタルリンクも切ってみたんですが変わりませんでした。
一旦、出力フォルダを削除してから、パソコンを再起動して、ビルドし直せば？
バグっている時に、これで直る事もある。
キャッシュか何かの不整合かも？
うーん、削除や再起動はやってみたけど変わらないんですよね。
複数の環境でcheckoutしてビルドすると同じ症状が出るから、プロジェクト設定のどこかだと思っているんだけど。
ありがちなのは、デバグ用スクリプトとかか？
直前直後にファイルを触ってるとか？
バージョン管理システムは使ってないんか？履歴を見たらええ。
チーム開発なら、ちょっとした個人設定のつもりの変更をcommitしてまうこともあるしな。
プロジェクトファイルをテキストエディタで読んだら？
ヘンな設定や漏れがあるんやろ。
何もせずにビルドをやり直しただけで起きるんで、ソースはもちろんなにも変化していないし
objのタイムスタンプも一切変わっていないのに>>231のように再リンクになってしまう。
>ヘンな設定や漏れがあるんやろ。
そう。何かあるんだろうけどそれが思いつかない。
ビルドイベントも見てみたけど何も設定していなかった。 リンク結果のファイルはどうなの？
実は、更新されてないとか削除されてるとかないの？
objファイルのことばっかりやけど。
プロジェクトファイルの中身は読んだんか？
デバグ用とリリース用の部分で差分を確認したり、できることはあるが。
>>236
もう一度順を追って書くよ。
1. ソース等をなにも変更しない状態でDebugビルドをすると、なぜか出力バイナリ(exeやdll)の
タイムスタンプが変わってしまう現象が見つかった
2. MsBuildのログを見てみるとリンクが再実行されている(>>231)
3. objのタイムスタンプは何も変わっていないのになんでだろう？←いまここ
その後試してみたところだと、どうもプログラム全体の最適化(/GL)とリンク時のコード生成(/LTCG)が
有効になってないとこの現象が出るっぽい。ふつう逆じゃないかと思うんだけど。 build完了した後に何もせずそのままbuildしてもってか
>その後試してみたところだと、どうもプログラム全体の最適化(/GL)とリンク時のコード生成(/LTCG)が
>有効になってないとこの現象が出るっぽい。ふつう逆じゃないかと思うんだけど。
他のC++プロジェクトで試してみたところこれが有効じゃなくてもそんな症状は出なかったから
これだけが原因というわけでもないっぽい。
objファイルとかソースファイルの更新日時がおかしいとかない？
ファイル日付が戦前になってしまう現象なら見かけたことあるけど
objの時刻は何度か見直してみたけど別に問題ないんですよね。
>>231の名前のない「出力」が常にエポック日時とみなされているような気がするけど、これが何なのかがわからない。 >>244
もう現象が発生する最小のプロジェクトにしてどこかに上げなよ 質問です。
Visual Studioに載ってるGitの履歴同士の比較で、右のコードを左のコードで上書きするなんてことはできないんですか？
差異は表示されるけど、マージは出来ないんで中途半端だなと思っています。
今は外部の比較ソフトにコピーしてやってます。
>>246
5ちゃんだとこういう答えしか返ってこないから、
他のサイトで聞いた方がいいよ うーん.NET 5のフォームデザイナはエラーが良く出るね
まだ不安定な部分が多いのか
プログラミングを独学で始めようと思っています
今日visual studio2015をインストールしようとしたら、「セットアップパッケージが欠落しているか破損しています」と表示されます
OSはwindows 10 64bitです
原因分かる方いらっしゃいますか？
>>253
2015スレ落ちたみたいw
だから仕方なくここで聞いてるんじゃね 今VS2015を新規インストールする理由って何があるの？
手元にあった入門書が2015ベースだったからとかなんじゃね？
しらんけど
独学なら2019 Community Editionで良くね？
2015 Enterprise Editionのライセンス持ってるのかも知れんがw
今日会社でVS2015入れようとしたら俺のところもパッケージ云々出たな
客が指定してくるんだよな
まあ当面は2019で引っ張って、客に最終ビルドとテストを押しつける口実になったけど
>>256
バージョンでスレを分ける必要はないよな 2015Enterpriseがあるから2015使いたいってのは判らんでもないが
2019Community入れて使えばいい
Releaseするときだけ2015使えろ
>>265
質問者は2015がインストールできないって言ってるんだからreleaseビルドできないでしょうが わざわざ2015を入れようとしてるんだから、
当然ライセンスや互換性などの理由があると想像できるのに
>>262や265のようなことを書く神経がわからん >>267
想像で上から目線とかアホすぎる
> ライセンスや互換性などの理由がある
ならそう書けって話 >>269
だからEnterpriseとか書いてるだろ
そんなこともわからんのかよw 2015入れたいなら2015専用に別のPC用意して
そっちに古いOSと2015入れろ
そのためにMSDNがあるんだろ
Enterpriseなら古いOS付いて来るだろ
>>279
> 2015入れたいなら2015専用に別のPC用意して
今時仮想化だろ 仮想PCだってWindows10だろ
MSDNだと、古いWindows10とかあるの?
Windows10だと結局インストールできないんじゃないの?
>>282
Microsoftをなめんな！
知らんけど。 今、Windows 10 2004 のテストでインストール中だけど
まだエラーはでないな
インターネットに接続できない環境だとパッケージのデジタル署名をきちんと検証できなくて
エラーになる現象はあったと思う。
あと、.NET Framework 3.5の有効化とかかな
>>282
> 仮想PCだってWindows10だろ
意味不明
まさかと思うけどゲストOSはホストFSと同じでないとダメとか思ってる？
> MSDNだと、古いWindows10とかあるの?
そのレベルで話に入ってくるなよ… VS2015フルでインストールしてみたけど
パッケージが破損している
っていうメッセージはでなかったな
JavaSEとAndroidSDKがダウンロードされなかったっていうメッセージが最後に出た
サポート切れの関係だろうな
複数の同僚がVS2015だとJSの編集が出来ないって困ってるな。
固まったりするらしい。
>>282
MSDNにはOSはWindows XPからあるし
Windows10なら大型アップデート毎に初代から全てのバージョンが揃ってる
Windows7なら実際にWindows10の仮想環境で使ってるよ VisualStudio 2017 CommunityでC#のWinフォームアプリ作って楽しんでます。
C#の最新バージョンが使いたくて調べたら2017のアプデではだめで、
2019で新規インストールにしないとダメなんですかね？
その場合、2017で作成したプロジェクトや保存先フォルダ構造は引き継がれるんでしょうか？
2019に変わる際、気を付けることとカありますか？
2019に変えればよろしい
プロジェクト構成も変わらない
2019で初めてプロジェクト開く時に移行しますか？って聞かれるだけ
Win7 Pro でVS2019 日本語版にて、
C++でCUIのHello Worldのプロジェクトを作り、数行のthread local storageの
テストプログラムを書いてデバッガを起動しようとしたら、VSのstatus barに
xxx.dll を読み込み中ですと出たままデバッガが起動できない。
最初の Hello World のままだったら起動できた。
デバッガ無しだと起動できる。
>>289
2017と2019ならそれ以前のバージョンより共存時の罠が少ないので慣れてから2017アンインストールでもいいのよ？ >>294
待ってたら「準備完了」と出てデバッガが使えるようになったわ。
でもステータスバーを見てないとその状態になったことの識別が
めちゃくちゃしにくい。 準備できてない間にも色々いじれるようになっているから逆に分かりにくい。
じゃあ、ステータスバーをでかくしろよ。
WindowsのUI設定でできんかったっけ？
次期VSでは準備中状態をモーダルダイアログで出して、他のことはできなくします。
準備が終わるまでスプラッシュスクリーンに変更します
Build 2021で紹介されて気づいたんだけどインラインのヒント機能がいつの間にかかなり機能アップしてるな
特にラムダパラメーター型のヒントが気に入ったわ
16.10にしたら、16.06で開発していたC++プロジェクトでリンクエラー発生。
「libpng.libが異なるコンパイラで～」のエラー。libpngも16.10でビルドしてリンクし直したら通った。
でも、純粋Cのlibpngはダメなのに、Boostとか使いまくりの別のC++で作った.libはそのままリンクできてる。
何が違うんだ…
ちなみにBoost（1.76.0）も16.06でビルドしたスタティック版を使ってるけどリンクエラー出てない。
zlibやlibjpegも問題なくて、出たのはlibpngだけ。
エラー詳細：
LINK : fatal error C1047: オブジェクトまたはライブラリ ファイル 'foo/bar/libpng.lib' は、'foo/bar/.obj' などの他のオブジェクトとは異なるバージョンのコンパイラで作成されています。同じコンパイラを使用してすべてのオブジェクトとライブラリをリビルドします
>>308
これが発生源になるの？確かにオンになってたのでオフにしてみた。
libpngは配布ソースに入ってるVC++プロジェクトをそのまま開いてビルドしてただけだったんで気にしてなかった… VSってCommunity版でも、ライブラリのソースを見ることが出来る？
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\crt\src
のこと？ 俺んとこでは見れるよ（もちCommunity）
>>312
自分で落として見ればよくね？
マジな話それぐらいの労苦もしたくない奴は開発者に向いてないと思うよ C:\Program Files (x86)\Windows Kits\10/.../ucrt/convert/mbtowc.cpp の
_mbtowc_l() は、「mbchar が NULL 以外で、有効なマルチバイト文字を指している場合、mbtowc 関数はそのマルチバイト文字の長さをバイト数で返します。」とあるように、戻り値は s が指しているMultiByte文字のバイト数であるはずなんだけど、
次のコードを見ると、その文字のバイト数ではなくて、現在使っている MB文字の最大のバイト数
を返している様に思える。このコードは本当に正しい？
extern "C" int __cdecl _mbtowc_l(・・・) {
・・・
if (_isleadbyte_l((unsigned char) *s, _loc_update.GetLocaleT()))
{
/* multi-byte char */
// If this is a lead byte, then the codepage better be a multibyte codepage
if ((_loc_update.GetLocaleT()->locinfo->_public._locale_mb_cur_max <= 1) || ((int) n < _loc_update.GetLocaleT()->locinfo->_public._locale_mb_cur_max) ||
(__acrt_MultiByteToWideChar(_loc_update.GetLocaleT()->locinfo->_public._locale_lc_codepage,
MB_PRECOMPOSED | MB_ERR_INVALID_CHARS,
s,
_loc_update.GetLocaleT()->locinfo->_public._locale_mb_cur_max,
pwc,
(pwc) ? 1 : 0) == 0))
{
/* validate high byte of mbcs char */
if ((n < (size_t) _loc_update.GetLocaleT()->locinfo->_public._locale_mb_cur_max) || (!*(s + 1)))
{
errno = EILSEQ;
return -1;
}
}
return _loc_update.GetLocaleT()->locinfo->_public._locale_mb_cur_max;
}
・・・
}
docs見てみたけど、’その’マルチバイト文字の長さ… とはなっていないね
>>317
int _mbtowc_l(
wchar_t *wchar,
const char *mbchar,
size_t count,
_locale_t locale
);
[戻り値]
mbchar が NULL 以外で、有効なマルチバイト文字を指している場合、
mbtowc 関数はそのマルチバイト文字の長さをバイト数で返します。
mbchar が NULL の場合、またはこの関数がワイド文字の NULL 文字 (L'\0')
を指している場合は 0 を返します。mbchar が指すオブジェクトの最初の
count 文字が有効なマルチバイト文字ではない場合は -1 を返します。 clangのlibc++のソースは次のように、mbrtowcの戻り値を頼りにポインタを進めている :
// MB文字列 --> WIDE文字列 への変換 :
size_t mbsnrtowcs( wchar_t *__restrict dst, const char **__restrict src,
size_t src_size_bytes, size_t max_dest_chars, mbstate_t *__restrict ps )
{
・・・
while ( source_remaining ) {
if ( dst && dest_converted >= max_dest_chars )
break;
// Converts one multi byte character.
// if result > 0, it's the size in bytes of that character.
// othewise if result is zero it indicates the null character has been found.
// otherwise it's an error and errno may be set.
size_t char_size = mbrtowc( dst ? dst + dest_converted : NULL, *src + source_converted, source_remaining, ps );
// Don't do anything to change errno from here on.
if ( char_size > 0 ) {
source_remaining -= char_size;
source_converted += char_size;
++dest_converted;
continue;
}
result = char_size;
have_result = true;
break;
}
・・・
}
.NET5のフォームデザイナだけど、フォームのサイズを少し変えてから
構成マネージャでx64にしようとするとエラーが出て保存できなくなる
16.10で直ると思ってたんだけど直ってないな
新しいフォルダの作成ってショートカット無いんだっけ？
VS 2019 で vcxproj ファイルを開くと
VCProjectVersion 16.0
とは別に
PlatformToolset v142
という項目があるのですが
この v142 っていうのは何のバージョンなんでしょう？
>>322
ビルドツールのこと
プロジェクトのプロパティにも項目がある
v142はVS2019の標準のC++ビルドツール VS2015(C++開発)のことで恐縮なのですが、VS2019でどうかの情報でも良いので教えてください。
ビルド前イベントで自作ツールを実行させ、
それによって自動生成された.cppファイル(事前にプロジェクトに登録されておらず新規に生成)を
その後に走るコンパイルの対象とすることは可能でしょうか？
事前に.cppをプロジェクトに登録しておき、そのファイルを更新という方式とするしかないでしょうか？
makefileでやってるけどね。
ＶＣのプロジェクトって同じＶＣ間でもバージョンが違うと「移行に失敗しました」と出るので使い物にならない
それどころか同じバージョンでもKB1234なんちゃらがないとコンパイルしませんとかやったらトラブルが起きる。
cppソースを自動生成ってすごいな
バイナリを直接自動生成していいんじゃないのか
>>324
ソース書き込みはテキストファイルを出力すればできる。
コンパイル&ビルドはCreateProcessかShellExecuteExでコンパイラかバッチを走らせればできる。
Visual Studioの場合は、VSコマンドプロンプトからコンパイラを直接触ることが可能。 >>324
C++でやりたい場合はCMakeのカスタムターゲットの使用を推奨。 >>326
ただの配列でも名前空間つきならC++なんやで？ >>326
お前はテキストファイルの生成もできないのかよw 焦点はテキストファイルの生成じゃなくてソースコードの生成（AI的なやつ）かと思ったけど
ソースファイル出力は、文字列処理とファイル出力をちょっと難しくしたものだろうけど、
fprintf関数の使い方わかってればそんなにそうではない。
>>330
>>331で書かれてるように、ロジックの自動生成かと思ったからバイナリの話を持ち出したんだよ
テキストファイルの生成が難しいと本気で思ったの？ちょっとは考えろよ ルールに基づいてC++のソースコード生成するのが難しいっていう発想が意味分からん
プログラミング初心者かよw
ちょうど今、PowerShellでC#のコード生成するスクリプト作ってるところですわ
>>333
ソースファイルの自動生成という文を、ロジックの話だと思い込んだんなら、どんだけバカにされてもしゃあないで？
相手に考えろとか言うてる場合ではない。ｗ C#のコンソールアプリケーションを新規で作成するとき、
ターゲットフレームワークは.NET Core 3.1を選べばいいんですか？
今まで作ってきた.NET 5.0のは.NET Core 3.1に読み直さないとダメですか？
C#とC++が混在しているソリューションファイルで、C#のexeからC++のDIIをp/invokeで呼んでいます。
C++のDIIをC#のパスに通す為、C#プロジェクトのビルド後イベントを使ってコピーしているんですが、C++だけ編集した後にビルドしてもC#側はビルド不要判定でビルド後イベントが働きません。
C#のexeは複数あるんでC++のDIIの配置は決め打ちにしたくないです。
何か解決策ありませんか？
>>340
C++のプロジェクト側のビルド後イベントでコピーしたらいいのでは >>340
成果物ビルドなのか、デバグ用実行なのか、目的によるような。
>>342だと、C#側のビルド時にも対応がいるやろ？
デバグ用なら、シンボリックリンクでごまかしてしまうのが一番簡単で融通がきくんちゃう？ 16.10にしたら、フォームのコード書く画面の上部真ん中のプルダウンの
（Form1イベント）
が選択できなくなりました。（Visual Basic）
すごく不便なんでなんとかなりませんか？設定変更なりバージョン戻すなりで。
>>340
dllをコピーするメイクファイルプロジェクトを作ってプロジェクトの依存関係で動くように設定すればできるんじゃないかな make スレが無いようなのでこちらで質問します
Visual Studio 2019 を入れると
nmake と cmake が入ってるのですが
(その他の make ツールもインストールされたかも知れません)
自分で makefile 書いて build しようと思ったら
nmake cmake どちらのを使うのがおすすめですか？
(MSBuild とか IDE とかは使わない前提です)
nmake と cmake は用途が違うし直接比較するものじゃないな。
おすすめを聞く以前にそれぞれどう使うものか調べてみれば？
>自分で makefile 書いて build しようと思ったら
これが条件なら nmake 一択
>>348
cmake は、makefileやプロジェクトファイルなどを自動生成するようなプログラム。
主にマルチプラットフォームに対応したいときにmakefileを手書きせずにるために用いる。 >>344
普段VB.NET使いだけどC#でも同じみたいですな
デザイナの方でやれっとことかな(プロパティの雷マーク) Build 2021の日本語字幕、機械翻訳が酷すぎてなに言ってんのかさっぱり分からんw
>>356
技術評論社が翻訳していた
みかん星人事件はそんな中で起きた >>348
Makefileは書かずに使う方法を最初に覚えるべき。
それを理解したら、書かけるので書き始めればいい。
例：
A>mkdir NAME
A>cd NAME
A>copy CON: x.c
#include <stdio.h>
int main() { printf("hellow,world\n"); return 0; }
^Z
A>nmake x.exe
A>x
hellow,world
A> 自動補完で候補からToStringとか選択するときに、末尾に()付けるような設定って出来ます？
高階関数？考慮して（）を付けないようにしてるのかなと思うのですが
Tostring()くらいなら（）付きで補完したいなって
あれってなんで()付けないんだろうね？
なんか中途半端
VB.NETではToStringでもToString()でも問題ないけど
>>361
どうやって確定させてるのか知らんけど、確定する時に '(' をタイプするだけの話じゃねーの？ >>347
ご助言ありがとうございます。
https://www.atmarkit.co.jp/fdotnet/special/msbuild01/msbuild01_01.html
このサイトで.vcxproj(＝MSBuildファイル)の仕組を学んだ上で試行錯誤した結果、
下記の通りに記述することで目的通り、ビルド前イベントで.cppを新規に生成したときも
続けてコンパイルしてくれるようになりました。
･･･
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
↓以下を追加
<Target Name="PreBuildEvent"> ←上記でインポートされたPreBuildEventターゲットをオーバーライドする
<Exec Command="[.cpp自動生成コマンド]" /> ←IDEから設定せず、ここに手動で記述する
<ItemGroup>
<ClCompile Include="[自動生成先ディレクトリパス]\*.cpp" />
</ItemGroup>
</Target>
</Project> 最近resharperない環境でコード書いたときはかなり戸惑ってしまったわ
Visual Studio も LINQのコードシンプルにする提案とか
機能どんどん増えてるけどresharperまだまだ必要だなって思った
いらね
意識高い系C#erのReSharper信仰は完全に金槌を手にしたら釘を探す症候群
>>295
やっぱり、いくら待っても準備完了にならないことがあることが分かった。 >>374
無用の長物
購入するほどのものではない 欲しいと思う人は買えばいいし、そうでないなら買わなきゃいいだけ。
>>372
Resharper手に入れると必要もないプログラムつくるってことか？
そんな奴おれへんやろ >>378
実効性に乏しい小手先のリファクタリングばかりやりたくなるってことだよ 16.10.1
asp.net core の脆弱性修正あり
ReSharperは検索窓だけは便利だな
と以前は思い込んでたが一度無効にしてVSの標準機能だけでやってみたら意外と悪くなくて遥かに軽快でそれ以来ずっと無効
>>371には当てはまらないんだろうけど、俺みたいにReSharperから出ないから知識が昔のVSのままで止まってる人は多そう ReSharper重いから作業によってオンオフしてるわ
16.10って16.9直後みたいな巨大なバグはないの?
