C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/08/30(木) 12:52:55.39

>>58
modernはC++11以降を使うなら必読だぞ
むしろ素effectiveやmoreの方が古くてあんまり役に立たなくなってる

2018/08/30(木) 13:14:44.70

>>63
gccの独自拡張じゃねえの
むしろMSはそれに合わせてる

長いものには巻かれろ、ってヤツだ
長い方はMSじゃなくgcc

2018/08/30(木) 13:37:08.32

柴田の本は昔から悪書扱いされてる
あえて読むことはないと思うわ

2018/08/30(木) 13:37:55.22

だから読んでないわけか

2018/08/30(木) 13:58:51.87

昔は読んでたよ
20年以上前かな
いまでもjavaやc++のやつは図書館でたまにペラペラしてみるけど
読みづらくて全然合わないと感じる

同じジャンルで山田祥寛の本があったらそっちを読む

2018/08/30(木) 14:09:38.78

つまり読んでないってことだろ

図書館でペラペラってなぜそんなことをするんだ
C++を20年以上やってるんだろ

2018/08/30(木) 14:38:25.23

人にC++言語について教える時に、人口に膾炙した書籍の表現を使うのが無難だからでしょ。

54 (ﾜｯﾁｮｲ 9593-kT/R) · 2018/08/30(木) 15:34:47.96

>>56 すまん <cstdio.h> は変ね。<stdio.h> と <cstdio> が混ざってしまった。
<cstdio.h> というヘッダが存在する処理系もあるか知れんけど、
#include で使えと教えてる本はないだろうな。

主旨は「半端に古い本だと」で変わらないけど、良い例が出せんわ。

2018/08/30(木) 15:49:06.15

>>72
それを言うなら
<stream.h> //cfront 1.0
<iostream.h> //ARM
<iostream> //C++98
じゃね？

2018/08/30(木) 16:04:11.38

質問なんだがコンパイル時間の観点から見て、ヘッダをインクルードするときは必要でない限りcppファイルでincludeするべき？

2018/08/30(木) 16:13:39.13

#includeのネストを避けろということか？
そう主張する連中もいるが、俺は反対

2018/08/30(木) 16:18:52.75

>>74
ちょっと質問の意図がよくわかんないんだけど、逆に言えば
「ヘッダファイル (*.h) が他のヘッダファイルを include するのはコンパイル時間を増大させるか？」という意味？

あんまり関係ないよ。
よっぽど大きいプロジェクト (gcc とか) ならちょっとしたことで結構な差が出ることは無いとは言えないけど、
それでもプリコンパイルヘッダとかを活用すればだいぶん時間は短縮できるし、
更に高速化したいならキャッシュサーバを使うコンパイラもある。

https://github.com/yrnkrn/zapcc

・小さいプロジェクトでは気になるほどの差はない
・大きいプロジェクトではツールで解決しよう

2018/08/30(木) 16:23:45.00

コンパイラは可能な限り高性能なマシンで使うべし

2018/08/30(木) 16:52:55.72

例えばstd::stringをhoge.hでは使わずhoge.cppのみで使われている場合
hoge.hで#include<string>と書くと、他のファイルからhoge.hをincludeしたとき無駄が出るはず
だからhoge.cppで#include<string>と書いた方がいいのが、それとも些細な差なので全部hoge.hにぶち込んでもいいのかということ

2018/08/30(木) 16:55:06.24

なるほど、実装で使うだけで宣言にはいらないものか
だったらhoge.cppで#includeしたほうがいいね

2018/08/30(木) 17:19:10.16

http://www.geekpage.jp/programming/linux-network/select.php

なんかソケットごとに違うポートを割り振るものだと思ってたのですが、

listen(srcSocket, 1);//第二引数はクライアント上限数

この第2因数をいじったら同じポートでも普通に接続できました。
このまま気にせずselect処理書いていっても大丈夫ですかね...？
通信関係あまり知らないのでバグったりするとどうなるか分からずちょっと怖いです。

相手用のソケットは
int dstsocket[5]の様な感じで作って中身は全部一緒です

2018/08/30(木) 17:49:39.07

>>78
その場合だと .cpp に書いた方が当然良い。

2018/08/30(木) 18:56:44.69

プリコンパイル済みヘッダを、いちいち書かなきゃいけなくなるのがあれだから使わない方がいいと言われたことがある
なぜそれでコンパイルが遅いって文句言ってるのか分からない・・・

2018/08/30(木) 21:34:38.22

https://ezoeryou.github.io/cpp17book/
辞書にするならこれ。役に立ったら書籍版買ってあげよう。

2018/08/30(木) 22:17:19.27

書いても大丈夫だが、そういうやりかたにするならselectでﾌﾞﾛｯｸしないように注意したほうがいい
selectをﾌﾞﾛｯｸしたままの状態にすると、当然、そのあと永遠にacceptされない
きっとｽﾚｯﾄﾞにしたほうが簡単

2018/08/30(木) 23:08:40.56

>>78
hoge.hでstd::stringを使ってないのに#include<string>を書く、という発想が理解できない
#include<string>はstd::stringを使ってるところに書く、使ってないところには書かない、でいいじゃん

変更があって使わなくなったのに#includeは残ってるのがありがちで嫌なところ
静的解析とかで指摘して欲しい

2018/08/30(木) 23:48:27.87

>>80 ひきすう

2018/08/31(金) 14:08:47.35

>>80
変な心配せずに書いて覚えた方が早いよ
あと最初TCPって言ってたよね？
もしTCPで通信ごとにポート変えなきゃいけないなら、Yahoo見に行く時毎回ポート変えてんの？
HTTPは80番って決まってるやろ？
あと何のためにその第二引数があるの？

2018/08/31(金) 19:45:34.91

恥ずかしながら char と signed char が違うものだって知りませんでした…（独り言）

2018/08/31(金) 19:48:20.37

処理系による

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-zBrR) · 2018/08/31(金) 19:53:07.91

>>88
signed char とか unsigned char とか明言されず、ただ char としか書いていない場合、
その char が signed char になるのか、それとも unsigned char なのかは
「処理系依存」・コンパイラ依存だった、という経緯が C の時代からあったのでした

「signed char でも unsigned char でもない『「alternative な char』がある」
という意味ではないのです
"alternative char"…なんかだ魅惑される響きだと感じ入ってしまうのは、私だけですか…

2018/08/31(金) 20:24:19.94

>>90
char は signed char でも unsigned char でもないです。
C でも C++ でも。

2018/08/31(金) 20:30:14.89

？
charとsigned charとunsigned charは全部別の型だろ。

2018/08/31(金) 20:39:51.15

char は (型システム的には) signed char でも unsigned char でもないけど、
符号付きか符号なしのどちらかではあり、
その表現は処理系によって signed char か unsigned char のどちらかと実質的に等しいことになってる。

だいたいは暗黙の型変換が自然にうまいことやってくれるんだけど、
C++ だとオーバーロードの解決にかかわるところとかややこしいな。

2018/08/31(金) 20:40:27.43

std::byteとかいうゴミはどう使えばいいんだ？

2018/08/31(金) 20:41:47.58

>>89-90
そういう話じゃなくて文字列型にはchar, unsigned char, signed charの3つがあるって話じゃないの？

2018/08/31(金) 20:50:33.26

>>94
数値計算のための演算子が定義されてないのが重要なポイントだな。
なんらかの入力をビットパターンとして処理したいときに使える。

ビット表現に関する C/C++ での規則は未定義の部分もあって、
数値とビット表現の対応付けは処理系 (アーキテクチャ) によるので、
数値としての演算の結果 (の数字をビットパターンとして見た場合) は一意ではない。
std::byte でデータを保持しておけばうっかり数値計算してしまったりしない。

std::byte があることで特にできるようになることがあるわけじゃないけど、
うっかりを防止するために防衛的に使うもんだと思う。

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/08/31(金) 20:57:38.41

>>91
https://ideone.com/5zhQcP
…なるほど、そういう風に解釈するんですか！？
また一つ賢くなりました

2018/08/31(金) 21:21:37.54

>>97
もうひとつ面白い点としては、そこから void f(char c) の定義を消すと
char c = -12; f(c); という呼出しは解決できずエラーになる。

char, unsigned char, signed char は「順位」が同じなので、
呼出し候補としては同格になってしまい、ひとつに絞れないから。

もしも char が unsigned char か signed char かのどちらかなら、
どちらが呼び出されるにしてもひとつには絞れるのでこういう問題にはならないのだけれど。

ストリームに対する operator<< が char と unsigned char と signed char のそれぞれに用意されているのは、
そういう曖昧さが起こらないようにするため。

2018/08/31(金) 22:36:19.33

>>95
文字列型はchar
signed char, unsigned charは小さい数を格納する

2018/08/31(金) 23:16:56.24

「文字列型」という言葉を使うと語弊がある気がするぞ。

2018/08/31(金) 23:21:39.46

現在時刻(またはPCやexe起動からの経過時間)をmillisecondsで取得する方法ってありますか？
mm-dd-yyみたいな形式ではなくて全部数字で取得したいです

2018/08/31(金) 23:24:08.56

exeだからwindows
つまりGetTickCount()

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/08/31(金) 23:59:05.22

>>101
https://ideone.com/H6bajN

2018/09/01(土) 00:01:43.12

なんでCの頃にcharを符号付きを許したのかが謎
文字は負の値にならないとかいうルールまで定めながら
charをunsignedと定義することを頑なに拒んだ古代の連中は一体何を守ろうとしたのか

2018/09/01(土) 00:06:54.80

charのsignedとunsignedの処理系依存の混乱さえなければ今でもmalloc()はchar*（サイズ1の型のポインタ）を返してくれて便利だったかもしれんのに、

2018/09/01(土) 00:09:21.94

asciiは7bit

いまでもC++はどんなｵﾌﾞｼﾞｪｸﾄでも(char*)でｷｬｽﾄすることは
仕様で許されてる

2018/09/01(土) 00:09:26.78

>>99
そうであればよかったんだけどstreamsでの扱いは全部文字型なんだよな。
おかげでuint8_tをstreamに出力したら文字が出てくる羽目に。

2018/09/01(土) 00:15:47.63

>>106
Ｅ　Ｂ　Ｃ　Ｄ　Ｉ　Ｃ　は　８　b 　i　 t 　じ　ゃ　わ　！

>>106
キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　
標　　準　　の　　言　　語　　規　　格　　で　　は　　+ +　　や　　- -　　が　　で　　き　　ん

2018/09/01(土) 00:21:54.31

ｽﾏﾝ訂正；
誤：キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　
正： v o i d * 引　　数　　は　　キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　

2018/09/01(土) 00:24:45.17

知見が狭い低学歴知恵遅れの世界では
伝統的なﾃｷｽﾄがacsiiをさしてることすら
わかってないらしいわ

普通に古代のﾈｯﾄﾜｰｸで7bitのﾈｯﾄﾜｰｸとかあったからな

char*の変数に代入しないと
ﾎﾟｲﾝﾀｰをｲﾝｸﾘﾒﾝﾄできないとかあたりまえやんけ
C++とか関係ない

相変わらず低学歴知恵遅れはなにをいってるのか意味不明

2018/09/01(土) 00:28:15.78

昔、なんでﾒｰﾙがiso-2022-jpしかかたくなにﾀﾞﾒといわれてたか
きっとその理由も分かってない

2018/09/01(土) 00:36:37.58

>>110
えっっつ！？
伝統的なテキストの7 bitの文字コードはISO 646のことじゃないの；

ていうかASCIIが7 bitで表現できることはなんでCの頃にcharを符号付きを許したのか（>>104）を完全には説明しない
charをunsguned charにキめとけばアドレス全般を現す型としてのvoid*なんてものを別途作り出す必要も無く全員ニッコニコー☆だったかもしれんのに…

2018/09/01(土) 00:37:24.15

>>106
「どんなｵﾌﾞｼﾞｪｸﾄﾎﾟｲﾝﾀｰでも」の間違い？

2018/09/01(土) 00:42:50.43

MSBに1がたってるｵｸﾃｯﾄが1つでも入ってたら
それはﾊﾞｲﾅﾘだ

ｵﾌﾞｼﾞｪｸﾄを(char*)を普通にｷｬｽﾄできる
低学歴知恵遅れのどうでもいい感想やどうでもいい願望なんか関係ない
そういう仕様だからな

安全なPODは普通にｷｬｽﾄされることがある

2018/09/01(土) 00:44:26.13

ｵﾌﾞｼﾞｪｸﾄﾎﾟｲﾝﾀｰなのは
あたりまえ

2018/09/01(土) 01:14:05.21

7ビットでも8ビットでも表現できる言語の数は変わらないから

2018/09/01(土) 06:51:29.42

acsiiってなあに？低学歴知恵遅れさん

2018/09/01(土) 07:13:19.96

>>117
涙拭けよ老眼

2018/09/01(土) 07:40:58.94

>>110

2018/09/01(土) 07:48:51.59

情報系大学3年生
恥ずかしいことに今までやっていた言語がC++じゃなくてCだったことを知った…
（だってVisualStudio起動するときにC++開発モードを選ぶように言われたんだもの）
そういうわけでC++はどんなもんかなと本屋でちらっと明解C++を手に取ってみたら全く別物じゃねえか…
わかんねえよ……ネットで調べてみたら複雑らしいし
Cならatcoderで緑色になるくらいは書けるけど、でも就活のときCしか書けませんC++わかりませんってかなり致命的？

2018/09/01(土) 08:00:36.94

>>104
単なる char を int に変換する時に、符号拡張でも0拡張でも、
そのCPUで都合の良い(速く動作させることのできる)命令を使っていいよ、
っていう部分を重視したんじゃないかな。
文字コードは負にならないから、どっちで拡張しても結果に違いは生じない、
という保証が先にあっての話ということで。
MSBが1になる可能性がある8bit値なら signed/unsigned を明示しろと。

>>112
俺はむしろ「値を格納することを目的としない、抽象的な void* ポインタ」が
総称ポインタとして追加されたのを好ましいと思うけど。
「char* には他のどんなポインタもキャストして代入可能、そのポインタを介して
メモリアクセスすることも許す」の方が苦し紛れな気がする。
もちろん、このルールがないと本当に苦しい、ないと困るものだけど。

2018/09/01(土) 08:15:34.02

>>120
C++は、Cの後置インクリメントという名のとおり
最初はCのつもりで使ってよく
次から少しずつCに対する拡張を憶えていけばよい

Cをマスターしている人にとって
ごく自然に入っていける言語だから
慌てないでじっくりやってみそ

C++の発案者（通称、禿）が書いている有名な本が
まさしくCがわかる人のための論調だ
ISBN-10: 4797375957

就活では何言語が使えるかより
何を作ったかが大事
C++使えます、なんて新人が自称してても
たいていすぐボロが出るし

2018/09/01(土) 08:45:34.91

>122
書籍の紹介をする際にAmazonさんのページへのリンクを貼る人は多いけど、
ISBNだけでタイトルも書かないパターンは初めて見たよ。
『プログラミング言語C++』第4版だね。

おかげで ISBN-10 と ISBN-13 という2種類のISBNがあることも知った。

2018/09/01(土) 10:57:23.80

uint8_tとint8_tを使う。
移植性が良くなる。

2018/09/01(土) 11:04:56.69

んだ
cstdintとかcinttypesとか使えば良いじゃん

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/09/01(土) 11:30:44.62

>>120
私はC++を覚えるのに20年くらいかかっています、アマチュアベースなので

2018/09/01(土) 12:18:34.89

みんなそうだよ
C++はC with Classesから30年以上経っているが
未だに発展途上の言語で
新しい機能がどんどんできているから

2018/09/01(土) 12:35:41.52

文法覚えてもそこがスタート地点

推奨される最先端の実装例を見てみたいがどこにそういう例があるのかも知らない
だれかしらないかなあ

2018/09/01(土) 12:51:44.34

cl /std:c++latestや
clang-cl -Xclang -std=c++2aとかか？

2018/09/01(土) 13:05:09.71

レス㌧クス今全てがつながったわC++完全に理解した！
char→signed int変換を符号拡張でやっても良いという余地を残しておけば、
char→signed int変換を0拡張でやる命令が無いアーキテクチャーであっても、
（たまたま）使う文字コードセットがcharのMSBまで使わないやつ（acsiiとか）であれば
（運よく）変換を1命令で済ませられる

しかしcharをunsigned charとする案に対するアドバンテージはそれだけ…
我々は滅び去った腸古代のアーキテクチャーの痕跡を毎朝目の当たりにしているわけや

2018/09/01(土) 13:20:25.67

>>130は、>>121へのレス
痕跡というのは、C++において（オーバーロードとの絡みで）charがsigned charでもunsigned charでもない別の型である件のこと。

>>127
職業的に使う言語とアマチュアベースで使う言語は接する時間が違うから、上達の速度も違う
C++はCに擬態することで職場でも家でも継続的に新規の機能を試せたから成功した
D言語は職場で12時間C/C++を触った後に家に帰ってD言語脳に切り替えねばならなかったからめんどくさがられて失敗した

この反省を踏まえ、Pythonはいつでも初心者モードでも問題なく使える簡単言語になったそうな
（ちな職場でこっそり使い倒せる言語はやっぱPerlとJavaScrip(ｹﾞﾌﾝｹﾞﾌﾝ

2018/09/01(土) 14:18:13.49

Linux プログラミング・インタフェース、Michael Kerrisk、2012
翻訳者・千住治郎

C++11/14 コア言語、江添亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

これらが、神の書！
膨大なOK・NG パターンを列挙している

これらの本を持って、数年山籠もりすべし！w

初心者用の文法書なんて、一部分しか書いていない。
氷山の一角

ドワンゴ江添の本でも、詳細には切りがないので省略しますとかw
無限に出てくるw

こういう本を書ける、Kerrisk・千住・江添は、頭がおかしくなってるはず！w

2018/09/01(土) 14:22:45.69

上の本高いな

**132** (ﾜｯﾁｮｲ 0b80-4Jnz) · 2018/09/01(土) 15:18:22.65

「Finnegans Wake」の著者、James Joyce も、
翻訳者の柳瀬尚紀も、頭がおかしいと思ったけど、

132 の本は、まさにそう

頭がおかしくないと、これだけ書けないw

2018/09/01(土) 16:12:55.71

vcのwriteFileとかの関数って非同期の時戻り値とかどう処理すべきもんなの？
waitforsingleobjectでまつのはセオリーっぽいが
そこにたどり着くまでに非同期の処理が終了とかまだ終わってないとかいろんなケース想定されるじゃん？

2018/09/01(土) 16:31:40.14

MSDNのWaitForSingleObjectのページ読んだ？
実際に書いてみた？

2018/09/01(土) 16:45:34.07

>>135
WaitForSingleObjectまでに非同期処理が終わってたらWaitForSingleObjectからすぐに抜ける
非同期処理が終わってなければ終わるまでWaitForSingleObjectで待つ
要するにWaitForSingleObjectから帰って来たら非同期処理は終わってる

2018/09/01(土) 17:05:45.30

いまだにﾒｰﾙで昔半角ｶﾅを使ってはいけないといわれてた理由すらわかってないのが
よくわかったわ

EBCDICは8bitとかいってるぐらいだからな
そんなもん意味不明なﾊﾞｲﾅﾘだからな
当然utf8も意味不明なﾊﾞｲﾅﾘ

頭悪い知恵遅れでも分かったふりしてﾃｷﾄｰなこと書けるのが
2ちゃんねるだからな

2ちゃんねるは頭の悪さを自白するのに最適

2018/09/01(土) 17:09:37.10

>>136
書いてみた
パイプを使ったデータのやり取りをしようとしていて
writeFileだけでなくConnectNamedPipeだったりの非同期処理の異常系で困っている
通常の操作はおそらくできてると思うんだが....

>>137
やっぱりそういうことで良いんやね

2018/09/01(土) 17:46:30.13

>>130
>C++完全に理解した！

小悟を経て大悟に至る長大なステップのほんの一段に過ぎない・・・

2018/09/01(土) 18:01:58.23

C++erは3種類しかいない
C++を理解せずに書いている素人、C++を理解したと勘違いしてる素人、いつか人類はC++を理解できるのだろうかと日夜考え続けている素人だ

2018/09/01(土) 18:06:49.23

C++はわしが育てた。

2018/09/01(土) 18:20:12.88

>>141
.0.5%ぐらいは真のC++プログラマーがいると信じたい
今まで出会ったことがない

2018/09/01(土) 19:13:37.84

>>141
「完全な理解」に到達できないようゴールを動かしつづける黒幕、
てのがいそうな感じね。

日々の学習が新規格に追いつかないヘボの愚痴だけど。

2018/09/01(土) 19:30:28.67

実際これ本物じゃないかと思うよね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

2018/09/01(土) 20:34:01.15

>>145
Javaで読み替えてみ。

2018/09/01(土) 20:50:59.81

javaに必要だったのはGCじゃなくてデストラクタだったりして。
噂によると、参照切るために使い終わったらオブジェクトにNULL入れてるらしい。
それってfreeと違うんかい？

2018/09/01(土) 20:53:31.39

今使われてるあらゆる言語に置き換えられそう

2018/09/01(土) 23:46:43.62

進撃の巨人、エンドオブザワールド見たら、ミカサがいきなり不倫してて子供までいる設定に代わっててびっくりしたわ。
原作ではそんな子じゃなかったのに。

**120** (ﾜｯﾁｮｲ 1dc3-4YxK) · 2018/09/02(日) 07:00:47.93

>>120です。レス少し遅くなっちゃったけどレスくれたみんな詳しくありがとう
とりあえずじっくり勉強してみることにするわ
このご時世、就活を意識するならPythonのほうが優先度は高そう感じがするけど…

就活についてのアドバイスしてくれた人がいるけど、納得した。
「できます」「つかえます」って基準が不明瞭だからさして効果はないか。
ちなみにどんなものを作れば有利に働くかな？
趣味でプログラミングをしているけど何か作りたいものがあってはじめたんじゃなくて競技プログラミングが面白そう、という理由ではじめて競技プログラミングをメインにやってた
Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな

2018/09/02(日) 07:15:15.45

>>150
査読論文
100万PVを超えるwebサイト
アプリのレビュー経験
上記以外はマイナスになるだけ

2018/09/02(日) 07:18:34.72

会社によるし何したいかによる
言語仕様やコンパイラに強い人が欲しい会社もあるし
ハードウェアやアセンブリレベルに強い人が欲しい会社もあるし
CGとか映像処理に強い人が欲しい会社もあるし
Windowsのことなら任せろって人が欲しい会社もあるし
OSS界隈の事情に詳しい人が欲しい会社もあるし
コード土方なんかよりパワポのプロが欲しい会社もある

頑張って

2018/09/02(日) 08:54:14.95

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

日本の大企業から、C の専門家、数十人が集まって、この本を書いたけど、
規格について詳しい人は、いなかった

規格書の条文を組み合わせたときに、どういう現象が起こるかわからない。
このレベルの人では、その恐ろしさをよく知っている

ルールの組み合わせ爆発が起こるから、無限！
だから規格を保証できない

よく、わからなかったから規格書を読めっていう奴がいるけど、
そういう奴は、組み合わせ爆発の恐ろしさを、何もわかっていない

2018/09/02(日) 10:18:27.88

言語の入門書を読んで、文法だけを知っている人なんて、いらない。
文法だけじゃ、仕事はできない。
仕事とは、システムを作る事だから

だから企業は、コンピューターリテラシーのある人が欲しい。
OS の知識。システムの運用構築。
デザインパターン・アルゴリズム・データベースなど、すべての範囲

大量の勉強・資格も必要。
その人が到達したレベルの証明書

Ruby が出来たら、Python もわかる。
Rubyよりも面倒くさいのに、なにも、Pythonで書く理由がない

AI・数学系の仕事があって、初めてやるもの

float 変数にずっと、1を足し続けていくと、どうなるでしょう？
ちょっとした質問をされても、勉強していないと答えられないだろ

2018/09/02(日) 10:55:34.36

＞float 変数にずっと、1を足し続けていくと、どうなるでしょう？
答えてどうぞ
ちょっとした質問なんだろ？答えて

2018/09/02(日) 11:00:46.35

突然ケンカ売り始めてワロタ

**154** (ﾜｯﾁｮｲ 0b80-4Jnz) · 2018/09/02(日) 11:38:28.02

120 みたいな「入門書を読んで、出来ます」っていうような奴は、よくいる。
文法をかじったのと、システムを作るって言うのは、全く違う

コンピューターリテラシーが無いと話にならない。
文法よりも、情報処理資格を取った方が、よほど使える

8進数の637 を、16進数で表示しろとか、こういう問題

文法よりも、システムを作るための基礎体力がある人。
登山するのにも、まず基礎体力だろ

2018/09/02(日) 11:40:33.24

>>157
逃げんな答えろ

＞float 変数にずっと、1を足し続けていくと、どうなるでしょう？
正確に答えて

2018/09/02(日) 12:11:20.54

>>158
プログラムで実行すればいいじゃん
馬鹿？

2018/09/02(日) 12:52:47.96

>>158
環境による、以上！

2018/09/02(日) 14:37:45.13

>>150
＞Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな
そっちの方が大きいと思うが・・w
ソフト一本作ったかどうか、ってのは大きいよ

2018/09/02(日) 14:52:19.54

>>150
> Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな

そうかなあ？何処に就職しようとするかで変わると思うんだが、しかし、そこまでできるなら結構有利なネタになると思うんだけど。

2018/09/02(日) 15:50:29.01

とにもかくにも何かを「完成させる」ってのは強いと思うよ。
プログラミングに関する色んな理屈は研究されているけれども、
現実の問題に対して適用できる能力はまた別問題だからね。
深く知っているやつよりも目的を達成できるやつが偉い。

もちろん深く知っている方が色々な問題に対して出来ることは多いはずだけど、
実際にやったという見える実績がないと評価しようがないもの。

評価基準は評価する側のことだから、
ひょっとするとあまり気にしない評価者もいるかもしれないし、
高く評価するかもしれないということはある。
でも、無かったら何にも無いだけ。

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/09/02(日) 17:18:56.14

>>163
＞とにもかくにも何かを「完成させる」ってのは強い
強いですね…
ある程度できてしまうと、情熱が失せるというか妥協するというか手を抜くというか
それを完成形に持っていくのには知性ではなく意志が必要だとおもいます、そして現在は知性（主知主義）よりも意志（主意主義）を評価する時代かと

私についていえば直近は
https://mevius.5ch.net/test/read.cgi/tech/1524570314/795-796
に執心していたのが、α版
https://mevius.5ch.net/test/read.cgi/tech/1434079972/52
ができてしまうと、ある意味どうでもよくなって、β版
https://mevius.5ch.net/test/read.cgi/tech/1434079972/53
を書き上げた頃は、変てこな義務感だけでいわば青息吐息で動いていた感じです、たぶんこれ以上手をいれることはないでしょう、全然未完成なんですけれども…

2018/09/02(日) 17:40:53.37

ゲームってプログラムより素材でしょ