C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[5]: C#の可能性


(過去ログ 139 を表示中)
掲示板トップ C# と VB.NET 入門 新規作成 利用方法/規約 トピック表示 ランキング 記事検索 過去ログ

[トピック内 7 記事 (1 - 7 表示)]　 << 0 >>

■81978 / inTopicNo.1) 　C#の可能性
  ▼■
□投稿者/ おじさんプログラマ (1回)-(2016/11/26(Sat) 22:34:45)

分類:[C#]　

Unix系のプログラムでバイナリデータを標準出力に書き出してきます。Windows
に移植済みなので動作には問題ありません。
それをパイプで受け取ってTCP/IPで別のＰＣに送ります。データを送る際には
若干の変更を加えてから送ります。プログラムの起動はC#側から行います。
こういった非常にプリミティブなプログラムをC#で記述できるでしょうか？？
ここにはC#の経験豊富な方がいらっしゃるようなので質問します。
できるけど簡単ではないとかいった回答は無意味ですので察してください。
引用返信 編集キー/
■81979 / inTopicNo.2) 　Re[1]: C#の可能性
▲▼■
□投稿者/ Azulean (734回)-(2016/11/26(Sat) 23:11:52)
■No81978 (おじさんプログラマ さん) に返信
> こういった非常にプリミティブなプログラムをC#で記述できるでしょうか？？

「プロセスを起動して標準出力を得ること」、「バイナリを自身のロジックを以て加工すること」、「TCP/IP で通信すること」はいずれもできる話です。

「C#」とやりたいこと（パイプと標準出力、TCP/IP で通信）をキーワードとして検索するとサンプルや紹介記事に当たりやすいと思います。
それらを読んだ上での疑問点を示してもらった方が答えを得やすいかと思います。

// 私は今の時点で難しい話ではないと思っていますが、パイプで扱う処理を普段書かないので断定はしていません。
引用返信 編集キー/
■81980 / inTopicNo.3) 　Re[2]: C#の可能性
▲▼■
□投稿者/ おじさんプログラマ (2回)-(2016/11/26(Sat) 23:48:58)
すいません、ここで聞きたいのは
「プロセスを起動して標準出力を得ること」、
「バイナリを自身のロジックを以て加工すること」、
「TCP/IP で通信すること」
じゃないのです。「プロセスを起動して標準出力を得ること」これをググってみると
上位にでてくるのは「テキスト」の標準出力を得ることばかりです。
バイナリ（要するに８ビット１バイトのデータの塊）を得るサンプルが見つからない
のです。
ちなみにコンソールアプリケーションがお行儀よく標準出力を使っているとは限り
ません。そういった経験を踏まえての質問だとご理解ください。特に今でも動く
16bitコンソールアプリはたいてい標準出力は使っていません。
TCP/IPで通信ってのもバイナリでのサンプルってのは殆どありませんし、加工と
いうのもビッグエンディアンでの３２ビット整数とかを扱う必要があります。
タイトルの通りにＣ＃にそういった「可能性」があるのかってことです。
CLIにはこういった可能性が見えてたのですがＭＳは捨てました。
引用返信 編集キー/
■81981 / inTopicNo.4) 　Re[3]: C#の可能性
▲▼■
□投稿者/ Azulean (735回)-(2016/11/27(Sun) 00:14:35)
■No81980 (おじさんプログラマ さん) に返信
> バイナリ（要するに８ビット１バイトのデータの塊）を得るサンプルが見つからないのです。

それを明瞭にしていただいた方が良いかと思います。

確かに Process クラスの StandardOutput は StreamReader なので「文字列」ベースであることは事実かと思います。
試していませんが、「process pipe windows binary C#」で検索した結果で当たった下記のページでは BaseStream プロパティを使うことで達成できるとは書いていますね。
http://smdn.jp/programming/netfx/standard_streams/1_process/


> ちなみにコンソールアプリケーションがお行儀よく標準出力を使っているとは限りません。
> そういった経験を踏まえての質問だとご理解ください。
（略）
> 16bitコンソールアプリはたいてい標準出力は使っていません。

「たいてい」ではなく、今の対象のプロセスがどうかが鍵だと思いますが、実際はどうなのですか？
使っていないことが事実であれば、「パイプで受け渡す」というのは、C/C++ だとどう書きますか？
その対比事例を出してもらえれば、C# ではどうかという話をしやすいと思います。


> TCP/IPで通信ってのもバイナリでのサンプルってのは殆どありませんし、

日本語で見つからないのであれば英語圏も対象にして検索してみて、それらしいキーワードを探すところですかね。
下記のスレッドでは TcpClient の GetStream メソッドで Stream クラスのオブジェクトを取り出し、Write している事例ですね。
http://stackoverflow.com/questions/11969993/how-send-data-tcp-in-binary-frame-format


> 加工というのもビッグエンディアンでの３２ビット整数とかを扱う必要があります。
> タイトルの通りにＣ＃にそういった「可能性」があるのかってことです。

リトルエンディアン実行環境でビッグエンディアンのバイト列を int として読み直すには、並べ替えは必要ですね。
http://schima.hatenablog.com/entry/20110301/1299001406

「可能性」という言葉にどういった意図まで込めているのか伝わってきませんので、有無についてはあなた自身で判断していただくしかないかと思っています。
引用返信 編集キー/
■81982 / inTopicNo.5) 　Re[3]: C#の可能性
▲▼■
□投稿者/ Azulean (736回)-(2016/11/27(Sun) 00:19:02)
一点追加。

■No81980 (おじさんプログラマ さん) に返信
> CLIにはこういった可能性が見えてたのですがＭＳは捨てました。

もしかして、C++/CLI のことですか？
別に「GUI を作ることは非推奨」というだけであり、部分的に C++/CLI にすることは今でも有用です。
GUI を C# で作り、下位層だけ C++/CLI で作れば良いですよ。
（あるいは、コンソールアプリケーションで良いなら、C++/CLI にもプロジェクトテンプレートが残っています）
引用返信 編集キー/
■81984 / inTopicNo.6) 　Re[4]: C#の可能性
▲▼■
□投稿者/ おじさんプログラマ (3回)-(2016/11/27(Sun) 14:49:44)
「可能性」というのは「これから勉強します」な方々にC#をお勧めできるか
という点です。
もう２０年も前になりますか、バイナリのデータをダンプして　0x12345678
が78 56 34 12 と書かれていて「ファイルがプロテクトされている」と言っ
たSEさんがおられました。
＞＞？もしかして、C++/CLI のことですか？
その通りです。

ご推奨のようにGUIをC#で、データ処理をC++/CLIでと提案したら絶対ダメ、
MFCで書いてくれと言われて経験の浅い新人さんには開発をお願いできま
せんでした。
C#で動く立派なアプリケーションがOfficeであれば十分に説得できたで
しょうが、C#あるいは.NET上で動くアプリケーションで「これ！」っと
いうのがあれば有償フリーを問わずにご教授ください。

とりあえずこのトピックは閉じます。
解決済み
引用返信 編集キー/
■81985 / inTopicNo.7) 　Re[5]: C#の可能性
▲▼■
□投稿者/ Azulean (737回)-(2016/11/27(Sun) 15:37:18)
■No81984 (おじさんプログラマ さん) に返信
> 「可能性」というのは「これから勉強します」な方々にC#をお勧めできるか
> という点です。

Windows 界隈がメインであれば、生産性という観点では十分におすすめできると思いますね。
Xamarin や VS for Mac などの存在も出ていますし、PC とスマホがターゲットなら生きてくるかと。


> もう２０年も前になりますか、バイナリのデータをダンプして　0x12345678
> が78 56 34 12 と書かれていて「ファイルがプロテクトされている」と言っ
> たSEさんがおられました。

リトルエンディアンやビッグエンディアンという言葉を知らない人もいますね。
Windows 上だけで動き、ハードと通信せず、ファイルをバイナリレベルで解析する必要性がないような現場であれば成り立つので、知らないからどうのこうのというのは案件・環境次第でしょう。

昔話もよくない気はしますが、低レベルの層を扱う必要性が少なくなったこともあり、「メッセージループで動くから当然だよね」みたいな話も説明から入らないといけない情勢だと思っています。


> ご推奨のようにGUIをC#で、データ処理をC++/CLIでと提案したら絶対ダメ、
> MFCで書いてくれと言われて経験の浅い新人さんには開発をお願いできま
> せんでした。

絶対ダメとする根拠がよくわかりませんが、後段の C# で動くアプリケーションの実績を求める感じからすると、.NET アプリケーションに対する拒否感からでしょうか？
昔ながらの実績ある手法にこだわるのは悪くありませんが、その要求を満たせる人材は業界内で減りつつあるので、どこかの段階で考えを改めることになるかもしれません。

あるいは、新人を頑張って育てていくことになりますが、なかなか厳しい道のりです。
学生の方はプログラムに興味を持ったとしても、Visual Studio Community で C# の道に歩みそうなので、未経験の段階で C++/MFC に接触することがほとんどないこと、入門書の類いはもう出ていないことから、どうやって教えていくかに悩みます。
（パワフルな人でないと、逃げてしまう（やめてしまう）可能性すらあると思っています）

// MFC も投資対象になっていなさそうな雰囲気ですし、開発環境・人材の両面から将来性は厳しいと思っています。


> C#で動く立派なアプリケーションがOfficeであれば十分に説得できたで
> しょうが、C#あるいは.NET上で動くアプリケーションで「これ！」っと
> いうのがあれば有償フリーを問わずにご教授ください。

身近なところで言えば、最近の Visual Studio の Shell は C# と C++ で作られていますね。
私の身近なところでは、C# 率がかなり高いので、採用を忌避する理由が想像できない感じになっています。
解決済み
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -