1 :
仕様書無しさん:
MSDNのドキュメントにはC#やVB.NETで.NETを利用する方法は書かれてますが
C++で.NETを利用する方法は書かれていません。
更に参考文献もあまり見つからず
VC++.NETという題の付いた本でも、単に開発環境にVC++.NETを使うだけで
内容はMFCの解説だったりする事が多いです。
そこで、このスレでは、C++で.NETを利用すると言う事限定で行きませんか?
2 :
仕様書無しさん:04/01/31 16:13
4 :
仕様書無しさん:04/01/31 17:57
test
5 :
仕様書無しさん:04/01/31 19:21
固定ポインタをこてぽと呼ぼう。
もうこてぽ。
やっぱりこの先、C++からC#やJavaなんかにどんどん移行していくのかな・・・。
7 :
仕様書無しさん:04/02/01 11:43
まだVC++6.0使ってる香具師は、WIN32APIが消滅するまでは移行しないだろ
8 :
仕様書無しさん:04/02/02 03:58
VC++.NETでもWin32アプリは開発できるわけだが・・・
managed やるぐらいなら、はじめからC#使え
C#キモイんだもん
11 :
仕様書無しさん:04/02/02 11:17
ManagedC++なら
Win32APIもMFCも従来のC/C++も.NETも全部使える。
しかも併用可能。
C#より幅が広いのだよ
12 :
仕様書無しさん:04/02/02 22:59
>しかも併用可能。
もうそんなのやだ。
Java見たいにあれもダメ、これもダメ、
なんてやってダメになっていくよりまし。
>>12 併用可能といっても従来と違ってなんでも使い放題なのではなく、
管理された状態でなんでも使える。
たとえばポインタを使用してはならないと宣言された場合、
言語仕様でポインタを使用できなく出来る。
だから誰かが規約外のことをしようとしてもすぐに見つけ出せるので、
以前のような混乱は起こらないから安心していい。
誰かILXのすれ立ててくれ
そろそろC由来のlink/loadを捨ててほしいよ
それで十分だろ
半端なVMが流行らんのもようわかったし
17 :
仕様書無しさん:04/02/03 22:15
>>11 何が悲しくていまさら MFC 使うねん。
18 :
仕様書無しさん:04/02/03 22:16
C# 覚えたら、かったるくて Java やら、ましてや C++ なぞ戻る気にもなれんわい。
19 :
仕様書無しさん:04/02/03 22:18
>>18 MSの言語だけど、何が悲しくて、激しく同意。C#はすっきり。
でも、ExceptionのcatchだけはJava流にして欲しかった。<-書かないとコンパイル
エラーになるところ
21 :
仕様書無しさん:04/02/03 22:24
VisualStudio.NETを眺めて見てもVB/C#(.NET)とC++(Win32)との扱いの差は…
もうC#(.NET)でいいかなぁって思う。
なんかC++でWin32アプリ作るの面倒になってきちゃったよ。
でも.Netフレームワーク入ってないPC多いからね
俺もMFC捨てたいんだけど、これまでの製品の関係でOLEをサポートせざるを得ない…。
24 :
仕様書無しさん:04/02/04 00:04
>>22 そうなんだよな。
そういう俺の環境にもVS.NET入れるまでは入ってなくて
「.NET Framework1.1が必要です」なんて言われると、ウザッて思ってた。
入っちまえばいいんだけどな。勝手だよな。
25 :
仕様書無しさん:04/02/04 00:11
VC++6.0使ってて、いまさらCOMの勉強してんですが、
これから.NETでのアプリ作成が主流になるとすれば
C++は使われなくなっていくということなんでしょうか?
COMで作られた資産の活用は、今後どうなって行く
のですか? C#ってそんなにイイんですか?
.NET Framework って、昔の VB Runtime 環境依存症候群みたいには
ならないのかなーってチョト不安。
添加の MSだからな。
27 :
仕様書無しさん:04/02/04 01:09
.NETFrameworkはDirectXみたいにOSに組み込むような形だから
喉元過ぎれば・・・じゃない?
一応下位互換だろうし。。。
>>25 C++が消える事は無いだろうけど
何が悲しゅうてCOMを使わねばならんって感じはあるね。
COMに変わる技術が.NETのマネージドコードだし
29 :
仕様書無しさん:04/02/04 06:40
>>27 side-by-side だからほぼ OK。
30 :
仕様書無しさん:04/02/06 23:32
>>25 .NET Framework が遅くてオーバーヘッドになる環境じゃなければ、COM コンポーネント
はもう新たに作る理由はないね。
いままでの COM ライブラリ資産を使いたいというのなら、.NET にインポートして
もともと .NET のアセンブリだったかのように使えるから、そのまま使えるよ。
COM 独自の制限は付いてしまうけど、それは従来 COM を使っていたときのものと
同じだから。
31 :
仕様書無しさん:04/02/06 23:43
.netが今の10倍くらいになればいいけど 遅すぎてな。
( ´-`).。oO(赤くても足りないね・・・・
>>31)
33 :
仕様書無しさん:04/02/07 00:20
>>31 そんな遅いですか?
Pentium 4 2GHz で 512MB でサクサク動いてます。
34 :
仕様書無しさん:04/02/07 00:34
35 :
仕様書無しさん:04/02/07 04:34
今後のアプリ開発で C++ + .NET という選択肢はないんでしょうか?
ハローワークを見ると、C#のスキルに対する需要がまったくない
ので、まだC++からC#の移行に踏み切れないのですが。
ろんぐほーん
はほとんどC#で実装だっけ?
C++もコボラーのように毛嫌いされてしまうのか・・・
38 :
仕様書無しさん:04/02/07 22:27
>>35 C# で募集をかけると、経験者が少ないので応募がほとんどないのです。
C++ や Java で募集をかけ、社内で C# を教育させるというのが一般的です。
39 :
自称C++厨をクビにせよう運動:04/02/09 10:22
グゴゴゴゴゴォ!!!
いまこそ、プログラマ革命を起こすときだ!
(亜ぼーんする愚か者には核ミサイル無量大数本分の死を!)
~ 自称C++厨の化けの皮をはがせ!運動展開中! ~
(本当は自称C++厨なんてたいしたことがない、上辺だけなのだ! 真実を見よ!)
大半のC++厨はインチキ詐欺師の卑怯者!
オブジェクト指向も知らなければデザインパターンも知らない悪い奴である。
しかも悪名高いウォータフォール信者と来た! 許せん! 今こそ正義の一撃を!
大半のC++厨は汚いコードを書いてチームをわざと混乱させメンテナンスの手間を増大させる悪魔なのだ!
大半のC++厨は自己保守的で官僚的で革新性が無く
自分のスキルの程度を誤魔化すためにわざとソースコードを読みにくくしているのだ!
(こいつらはわざと読みにくくすれば他人が解読するのにに手間がかかるので
凄いと思いこまれると勘違いしている馬鹿どもなのだ)
こんな卑怯者が許されるか!
蓋を開けてみればただのC言語しかできないとんでもない低脳である。
こんな悪魔のような給料泥棒なやつが金をもらっていることは絶対に許されるべきではない!
即刻減給するかクビにしてやるべきである!
このような卑怯なC++厨の行為は宣戦布告と見なさなければならない行為であり
大義名分を持って即刻解雇すべきである!
自称C++厨の化けの皮をはがせ! 自称C++厨の化けの皮をはがせ!
自称C++厨の化けの皮をはがせ! 自称C++厨の化けの皮をはがせ!
自称C++厨の化けの皮をはがせ! 自称C++厨の化けの皮をはがせ!
正義は勝つ!悪の枢軸・自称C++プログラマをこの世から抹殺せよ!
ドキッ
自称Cプログラマはもっとタチが悪い。
>>39は、何も知らんようだな。
C++プログラマを自称する方が、責任感があってマシ。
今時、「Cプログラマ」と称するヤシにろくなのはいない。保証します。
業務でC++を使わずCだけやってきたヤシはほとんどいない。
いたとしても、早々転職などしない。基幹部分の開発者だからだ。
人材派遣で「Cプログラム経験あり」ときたら、まずカスであると見てよい。
こういう人材を雇うプロマネはアフォ。
このケースでは、コボルあがりが即席C研修で箔をつけたに過ぎない。
見抜けよな、アフォども。
>>41 A.Iソフトのカーマック様は自称Cプログラマですが何か?
あのQuakeやDOOMやUNREALを開発した天才をカス呼ばわりするとは
>>41はどれほどのPGなのだろうか
>>42 藻前がC・C++未経験者or初心者orそもそも非PG
だという事だけはよく判った(w
>>44 僻みか?
実績ある人を称えるのは普通だと思うが・・・
>45
42が41の意図をまるで掴めず言葉尻だけに反応してるって皮肉ってるだけでしょ。
あなたももう少し読解力つけたほうがいいと思う。
47 :
仕様書無しさん:04/02/16 00:43
この間、うちの隣に住むおばあちゃんが病院に行ったんです。それで医者に
こう言ったそうです。
「左のひざが痛むんですけど」
すると医者はこう答えたそうです。
「歳だからね」
ひどいでしょ。でもおばあちゃん、負けず嫌いなのでこう言ったそうです。
「右のひざも同じ歳なんですけど」
質問があります。
"Visual C++ .NET Standard 2003" で
インストーラの作成ってできるのでしょうか。
いろいろ探しましたがビンゴな情報が出てきませんでした。
んじゃ、自分でVC使ってインストーラー作れば?
書き方が悪かったです。
VC++ .NET 2003には
インストーラを手軽に作成できる
ツールは付いてるのでしょうか、ということです。
52 :
仕様書無しさん:04/02/16 23:19
53 :
仕様書無しさん:04/02/16 23:26
>>52 C# とか Java とかって Decorator パターンで役割を分けてあるのはいいんだけど、
いちいち Stream s = new TextReader(new BufferedStream(new FileStream(...)));
とかって面倒だよ。
MC++のメリットはwin32apiや既存のdllが簡単に呼べるところ。
現実的には、そういった部位だけMC++でコンポーネントとして書き、C#やVB.NETで書いた
コードと組み合わせることになるんじゃないかな。
んじゃデメリットは?
特にデメリット感じないんだが・・・・
個人的に長年使い慣れたC++を使い続けられるのは嬉しい。
C#やった事ないけど、また覚えるの大変だし。。。
56 :
ブッシュ大統領:04/03/15 11:17
三大悪の枢軸国の紹介
C++帝國(北朝鮮) ← C++厨代表の正体は、何と! 金正日だった!
VB帝國(イラン) ← VB厨代表はイランに潜伏していいた!
Perl帝國(イラク) ← Perl厨代表フセインがついに逮捕された!
>>47 10年位前に青森のラジオでやってたやつだな、その話し。
58 :
仕様書無しさん:04/03/22 21:19
>>49 漏れの使っているエンタープライズは
インストールプロジェクトWizardがついてるぞ
Windowsインストーラーを作成できるよ
C++を.NETで利用するならば
ISAPIかATL COMか NT(2K) サービス
あたりの実装用だと思うのだが
あ・あとDDK使ってドライバか
アプリケーションプログラマには不要な言語かな
それ、Managedじゃないな。
61 :
仕様書無しさん:04/03/23 15:23
62 :
仕様書無しさん:04/03/23 15:32
63 :
仕様書無しさん:04/03/23 15:42
>>60 でも
>>59のようなコードを書くには、(VS.NETの中での)選択肢はVC++.NETしかない。
managedコードでドライバやシステムサービスが書けるなら別だけど。
あと、実行速度が要求される場面とかね。(VBのもっさり感には呆れた)
逆に.NET Frameworkを使うアプリしか書かないなら殆どメリットが無い。
実行速度が同じなら手軽に作れる方が開発効率が上がるし。
# VS.NETのインターフェースは好きだけど、支給されたPCがショボイので
未だにVS6使ってたり。
ム板向けのスレがなぜここに?
66 :
仕様書無しさん:04/03/24 10:27
>>64 ああ、統合開発環境のことを言ってるのね。
>>1が言っているのは.NET FrameworkをC++から使うMC++のことを言ってるんだと思うよ。
VB.NETでもMC++でも実行速度はあまり変わらないでしょう。
>>55 デメリット:
1) マネージコード用の構文を新たに覚える必要がある。
2) マネージコード用の構文で記述しないとガベコレで管理されない。つまり、ガベコレの
恩恵を受けるにはPGがそれを意識してコーディングする必要があり、リークの危険性は
存在しつづける。(これはメリットでもある。)
3) C#が標準になる可能性がある。MC++でも学習しなければならないのなら、最初から
C#を学んだほうが学習コストが低くすむかもしれない。
スレ移動申請したほうがいいのでは。
>>64 実行速度を考えるならば .NET VBでコールするライブラリCOMをC++で
書くのが本筋かな
ん、でもなあフレームワークのオーバヘッドがあるから
劇的には速度改善しないのかな?
64教えてくれ
ああん
今.NETのVC++プロジェクトを開いてみたら
ASP .NETが作成できるのだね
勉強不足だった。
しかし、これ使って組むの椰子はそうとうCマニアだろうな
72 :
仕様書無しさん:04/04/02 19:41
ASP.NETごときをやったくらいでCマニアだ? 笑わせるな。
あんなものをやったくらいではVB厨以下のレベルに下がるだけだ。
>72
そうか。そんなものなのか ASP .NET (C++)は
しらんかった
75 :
仕様書無しさん:04/04/03 20:41
ム板では何であんなにMS信者が必死なんですか?
77 :
仕様書無しさん:04/04/28 22:45
VC++.NET2003はC++の.NET環境が整ってきているのですが、デバッグ実行時の起動が超遅いです。
プロジェクトを新規作成して何もコードを書かずにデバッグ実行を開始しても、フォームが出てくるまで30秒ぐらい待たされます。
デバッグなしの実行ではすぐに出てくるのでデバッガの問題だと思うのですが。
2002の時も「Hello World」がコンソールに出てくるまでやはり30秒ぐらいかかります。
どなたか解決策をご存じないでしょうか?
ちなみに環境はWinXPPro、AthlonMP2000+Dual、メモリ512MBです。
ノート(WinXPHome、PentiumM1.4GHz、メモリ512MB)や職場のPC(Win2k、Pentium4-2GHz、メモリ256MB)でも同様でした。
よろしくお願いします。
79 :
仕様書無しさん:04/05/03 12:09
VC++.NETで.NET Framework使うのに資料が少ないのは納得できる。
でも、構文拡張までされてるのには驚いた。
.NET Frameworkだけ使うならSDKにアセンブラやメイカが付属してるから
そっちを使うのが良いのかも
>>80 その程度で驚くなよ。
BCBを見てみろ。closureとかpropertyとかpublishedとか
根本部分から大幅に拡張されている。
82 :
仕様書無しさん:04/07/16 11:42
ヘ_ヘ
ミ・・ ミ ということにしたいのですね?
( ° )~
83 :
仕様書無しさん:
恋を語らず何を語る?という世の中ですが、このコピペを必ず5つのスレに書き込
んでください。あなたの好きな人に10日以内に告白されます。嘘だと思うんなら
無視してください。ちなみにあなたの運勢が良かったら5日以内に告白&告白したらOKされます