Cの場合は
#define BIT(n) (1<<n)
if(data & BIT(3)){ data &=~BIT(3); }
みたいなやり方をするんだが、C++の場合は#defineは使わない方がいいらしいけどどういう書き方が
一般的なのだろう。
そういう場合にマクロ使うなと言われるのは、単にインライン関数にした方がややこしいバグを産みにくいってだけ
別にどっちでもいい
マクロ関数 BIT() の部分、マスク生成をinline関数にするか、
引数を2つ取って、整数値の指定ビットを落とした値を返すinline関数にするか、
if ~ の部分まで含めて、変数の指定ビットを落とすinline関数にするか…。
と思ってちょいと考えたら、この場合は if 不要と気づいた。
最初から 0 か、ビット操作の結果か、いずれにせよ data の bit3 は 0 になるね。
本筋とは関係ない部分だけど。
>>3
inline関数ですか？
constexperでも関数は作れると思いますが、inlineの方がベターなのでしょうか？
constexper int BIT(int bitno){ return 1<<bitno;}
usingを使ってこんな書き方ができますが、マクロの変換はできないのでしょうか？
using Func = int(*)(int);
あとtemplateはあまり使ったことがないですが、なんかマクロ変換に使えそうな気がします。 constexprは暗黙的にinlineつくからconstexprでもいい
using Funcの部分は根本的に勘違いしてると思う
それの場合intを受け取りintを返す関数のポインタの"型"に
Funcという別名つけてるだけやで
あと前スレ>>999
PCゲームやスマホゲーでも、STL使おうが使わまいが標準のヒープを直接は使わないことはよくあるよ
コンシューマへの移植性やパフォーマンスのためにカスタムのメモリマネージャ作ってるメーカーなんてザラにある
PCだから/メモリ有り余ってるからお仕着せのライブラリを適当に使うだけでいい、と思ってるなら何も分かってない 現実の開発では、とりあえず動くようにしてから余った時間で最適化したほうが速くなるんだけどね
まぁオブジェクトコードから臭いを嗅ぎ取った事は
無いな、感じられる人は耳鼻科行った方が良いかと
>>9
スレ跨ぐなカス
いつゲームの話なんかしたんですかねえ？？？？？？？
それともゲームしか入ってないんですか？？？？？？？？？ 「C」からって限定条件なら tcl/tk + canvas はありだと思うが
別に tcl の勉強しなくても使えるし
void ff()
{
std::packaged_task<int()> pt([](){std::this_thread::sleep_for(std::chrono::seconds(5));return 0;});
auto fut(pt.get_future());
std::thread th(std::move(pt));
th.detach();
//int v(fut.get());
}
上記のように、taskの完了を待機せず、packaged_taskの寿命が尽きても実行時にエラーも出ないのですが
このようなプログラムはありですか
C++ を使っても綺麗にならない
C++ を使ってる意味が無い
揃えさせられるPythonの読みにくさを見るとある程度柔軟な方がいい
ランタイム速度最速を謳ってバカに新機能の実験台になってもらう。
それがc++
>>22
ん？
普通に求めるでしょ？
見栄えとかアルゴリズムとか Most elementary use of C++
古いサイトとか見てるとグローバルな関数に::ってつけるこだわりがよくわからん
::CreateProcessとかさ
>>32
自分の定義した関数にはつけず、win32api には付けて区別しています… 公式「バランス調整はVIP部屋を参考にする」
桜井「○○の使用率ガー」
↓
アホ「調整はVIPの使用率できめるらしい」←？？？？
>>32
大規模開発ならスコープ明示するのはよくやること
std省略NGのとこも珍しくないしな >>31
だから綺麗さなんて曖昧な表現だけだと突っ込まれるって話 double の 999999998 と 999999999 の積が正しい答えである 999999997000000002 じゃなくて 999999997000000000 になります
なんででしょうか
double の範囲に余裕でおさまってますよね？
仮数部の最大値9007199254740992を超えているから
>>40-41
10^300 とかまで大丈夫だって思ってはいけないのですね
初めて理解しました 浮動小数点は元々、誤差があるから、大雑把な数値でよい
正確な数値を求める場合は、整数型か、decimal を使う
>>32
同じ関数で、MFC 版と Win32 版があることがあり、混乱が生じて、
切り分けの難しい不具合を生じる可能性を避けるため、そうしている。
C++だと、実引数を省略することもできる場合があり、その場合、Win32版を
使っているつもりが、MFC版が勝手に呼び出されて、動作が自分の思ったものと
少し違ってしまう可能性があるかもしれない。この時、コンパイラは何の
警告も出してくれないかもしれない。それを避けたいため、絶対に
Win32版を呼び出したい場合には、:: を付けることがある。 DoxygenがモダンC++に対応していないんだけど、何か代わりの物はありますか？
キーボードのPageUpとPageDownの使い方が判りません、他のボタンも。
C++のthreadってOSの無いマイコン環境でも動作するんだろうか？
threadが使えるってことは、ハードウエア的に最低でもタイマー割り込みを使う必要が
あるんじゃなかろうか？ そうするとそういうタイマーなどのハードリソースはすべて自前で
用意するというのが前提のマイコンではどうするんだろとふと疑問に思った。
>>48
どうにもならんのじゃない？
仕様に完全準拠した処理系 (ライブラリ) は提供できんってだけだろ。 effective Modern C++ / Scott Meyersには
C++１１の偉業として
C++の平行対応作業の大部分がコンパイラ開発側が負担する形で実現されたおかげで、標準
規格としてC++の歴史上はじめてどのプラットフォームでも動作が変わらないマルチスレッドプログラム
の開発が可能となりました。
と書かれている。
「どのプラットフォームでも」と書かれているがOSのないマイコンだってプラットフォームだからそれを含まない
と可笑しいとおもうが、、
>>50
そこは、対応しているプラットフォームでは、という前提がつくのは自明だと思うぞ、 そもそも、マイコンにスレッドなんてあるのか？
main 関数しか無いのでは？
マイコンには関数も変数も無いだろ
機械語セットのどこにも関数とか変数とかの命令は無いじゃん
変数が存在してるように見えるのはコンパイラのおかげ
C/C++ というのはそういうランタイムサポートが期待できない環境、いわゆる「ベアメタル」でも使い物になる
システムプログラミング言語であるというのがキモの言語だろ。
フルセットで使える環境なら std::thread という共通インターフェイスを使ってねというだけのことで、
リソースが限られたアーキテクチャでもフルセットが使えるべきというほどのもんではない。
>>48
(組み込みの)マイコンでは、普通、single thread なんじゃないかな。
マルチスレッドを使えるOSを作るのは結構複雑。
>>53
そういうOSをマイコンに作れば使えるようにはなるだろうけど、そこまでは
やってないことも多いと思う。そもそもマルチスレッドはプログラミングが
複雑になり予想も難しくなるのでバグが入り易い。カメラや炊飯器が誤動作して
も困る。 >>53
PCよりテヘロジニアス化(専用機をCPUに統合)が進んでるので、GPGPUみたいな感じってネットで読んだことあるな。 template<class T>
int print(T v)
{
printf("%d",v);// intの場合
printf("%lf",v);// doubleの場合
}
printfを使うことは必須なんですが、どうすれば実現できます？
>>52
戻り値の型をautoと書くとオーバーロードを認識しなくなるとかです。 コンパイル時の条件で型が変わるときはautoで済ますと楽
std::enable_if<>を使うと超長くなるんだけど、doxygenは戻り値の型の欄を改行してくれないので、関数名や説明の欄が横一文字とかになってしまいそうです。
何とかしてほしいです。
>>65
constexpr auto succ(auto num) {
return ++num;
} >>61
%lfて…わかってやってる、ワケないよな >>61
printf("%s", std::string(v).c_str()); >>72
ミスった
std::stringじゃなくてstd::to_stringが正しい なるほど、まず文字列に変換、統一してから %s で表示か。
>>62 の「テンプレート関数の特殊化」を教える例題って説も納得いくけど、
std::string の変換関数の好例でもあるな。
>>71 %lf は規格で認められてる変換指定だね、一応。
間違って使う奴があまりに多いので現状追認で追加された、
という経緯らしいけど。
どうやら C90 では未定義、C99以降は %f と同様みたい。 >>73
%06d とか %7.3f とかできなくなるやん >>75
質問主がデフォルトの書式だからとりあえずそのままで書いた
型ごとに書式を指定するなら上にもあるように特殊化するしかないな 自分で書いといてアレだけど、
C++に含まれるCの標準関数ってどうなってるんだろ?
Cの規格に追従して自動的に更新されてくのか、
ある時点で分裂したら再統合されるまで離れる一方なのか。
後者だとしたら、C99以降でprintf()の%lfが正当になったとしても
C++に関してはどのバージョンでも未定義、って危険があるな。
>>77
今のところつかず離れずを維持してる。
C++ 中の C 関数は「この C 規格を参照」という感じで明記しているので、
ある程度になると状況を見て参照先を変更するってだけ。
まあ関数についてはそれでいいとして、
その他のところも記法は統一して欲しいよなぁ。
C の _Noreturn と C++ の [[noreturn]] はどっちかに統一するのじゃ駄目だったんかなぁ？ とか。 vector<object*> v
がありまして、んでobjectクラスはメンバ変数int numを持ってるとします
このときですねv.at(1)->num, v.at(2)->num,....v.at(n)->numでvをsortしたいなーってのがあるんですけど上手い方法無いもんでしょうか
全然思いつかなくて
>>78
そう言うのは好みだからどっちかが大人になって折れるかよほど力の差があるとかでないと統合は無理 >>61
確か double に対応する書式指定は "%f" であって "%lf" ではない、という記憶がありますが K&Rのfloatは引数にするとdoubleに昇格するというルールが残っているのでしょう
本質ではなく、どうでもいいところにしか突っ込めないんだなｗ
プロトタイプ宣言されたfloat引数にはfloatで渡すけど
可変引数にはfloatは渡せないままなんだな何故か
>>86
va_list にそんな制限あったっけ？ 可変長引数関連はスタック周りを弄るコードを「マクロで」wrapしたものだから
C言語と互換性を持たせるためには仕様の詳細まで引き継ぐしか致し方なかったんじゃないの知らんけど
C++専用のva_listを名前を変えて作ったら解決したかもしれんが
知らんけど
ただしそうしたとしたら、extern "C"したのにC言語から呼ばれへん
何で！？となってﾌﾟﾁ大混乱が生じそう
知らんけどな…
printf()ではdoubleを出力できるのに、
scanf()ではfloatしか受け取れない（doubleをスキャンする機能が無い）というのは
C言語の七不思議のうちの一つ
しかしさすがにscanf()でdoubleをスキャンできるようにする近代化は一筋縄ではいかなさげ
>>84
不定長引数関数ならば、という縛りがつきます >>91
普通に書式"%lf" でできるのではないですか？ ところで質問なのですが代入やコピー構築時に所有権を移動するクラスFooを造りたいのですが、
Foo::Foo(Foo& rhs) : m_p(rhs.m_p) { rhs.m_p = NULL; } // 引数が非constのコピコン
Foo& Foo::operator=(Foo& rhs) { m_p = rhs.m_p; rhs.m_p = NULL; return *this; } // 引数が非constの代入演算子
を定義して、VS2010とかで警告レベルを4に引き上げると
C4239TypeからType&への変換です
という警告が出るのです
これはFooのムーブコンストラクタを定義したら直るので初めてムーブコンストラクタを定義したいのですが、そこで質問
Q1. ムーブコンストラクタにおいてはコピーされる側の変更はﾏｼﾞで不要？
つまり、所有権移動が絡む今回のFooの場合でも次の書き方でおk？
Foo::Foo(const Foo&& rhs) : m_p(rhs.m_p) { }
Q2. ムーブコンストラクタにおいてコピーされる側を変更しても（実行効率以外は）無害？
つまり、所有権移動が絡む今回のFooの場合でコピコンにならって次の書き方をしても安全？
Foo::Foo(Foo&& rhs) : m_p(rhs.m_p) { rhs.m_p = NULL; }
rhsにNULL入れてるってことはrhsのデストラクタで解放されたら困るってことでしょ
一時オブジェクトだろうが何だろうが破棄されるときにデストラクタは走るから、
その例だとNULL入れる必要はある
というかその例は綺麗にムーブを使うべき例
>>101
>rhsにNULL入れてるってことはrhsのデストラクタで解放されたら困るってことでしょ
なるほど確かに…
ていうか鋭い
>というかその例は綺麗にムーブを使うべき例
ﾎﾝﾏや（ﾟДﾟ；）ムーブコンストラだけで動いたわ㌧クス、 実験してから質問せいやというご批判があるかもしれないので釈明
実験はした
しかしコピコンが定義されているとムーブコンは呼ばれなかった（から、>>99のQ1のムーブコンでもちゃんとイゴイタ）のである えｗ
実験するのめんどくさいから質問してたわｗ
ダメだったんだ、ごめんなさい。
コンパイルエラーがとれなくて困ってます
■ ヘッダー側
template<class T>
class Test
{
public:
Test(void (*func)(T)) {}
Test(void (*func)(const T&)) {}
};
typedef Test<int *> TestPtr; // テンプレート引数がポインタ型
■ 呼び出し側
static void func1(int *x) {}
static void func2(const int *x) {}
void main()
{
TestPtr test1(func1); // OK
TestPtr test2(func2); // コンパイルエラー
}
VC2008だと以下のエラーになります。
1 番目の引数を 'void (__cdecl *)(const int *)' から 'void (__cdecl *)(T)' に変換できません。
func2みたいにconst付けるとなんでダメなんでしょうか？
>>104
実験もせずに待つって、マナー以前に自分のためにならんだろ
答えが返ってくるまでボケっとしてんのかと
>>105
関数ポインタは引数の型が違うと別の型になる VC++でmsado15.dllをインポートしようとしても参照されずエラーになるのですが原因は何でしょうか？
>>107
それだけでわかるか。エラー内容くらい書け >>108
C:\Program Files\Common Files\system\ado\msado15.dll に対応するエディターはありません。
このファイルの種類(.dll)のアプリケーションがインストールされていることを確認してください。
重大度レベル コード 説明 プロジェクト ファイル 行 抑制状態
エラー (アクティブ) E1696 ソース ファイルを開けません "C:/Users/owner/Documents/Visual Studio 2017/Projects/20190227/20190227/Debug/msado15.tlh" 20190227 C:\Users\owner\Documents\Visual Studio 2017\Projects\20190227\20190227\Source.cpp 6
ソースは以下の通り
#include <stdio.h>
#include <tchar.h>
#if (WINVER >= 0x0601) // Windows 7 以降
#import "msado60.tlb" no_namespace rename("EOF", "adoEOF")
#else
#import "C:\Program Files\Common Files\system\ado\msado15.dll" no_namespace rename("EOF", "adoEOF")
#endif >>106
なるほど。
typedef Test<const int *> TestPtr;
にしたらコンパイル通りました！どもです！ >>109
必要かどうかわからなかったのですが
regsvr32.exeでmsado15.dllを登録
その後いろいろいじってビルドしてみるとコンパイルできました。
ただし出力ができませんでしたがコンパイルはできたのでとりあえず良しとします。
msado15.dllのようなDLLはC(VC)++で扱うのは難しいですね。
インテリセンスが働きませんから… はじめまして。
C++でスケジューラのようなものを作りたいのですが、
相談に乗っていただけますでしょうか？
C++/MFCのMDIを使用して、ウィンドウ内に複数のウィンドウを配置したいと思っています。
一つのウィンドウにはリスト形式でタスクの一覧を、別のウィンドウでは
ガントチャート形式でタスクの時間ごとにグラフを描画し、その他のウィンドウは各情報を表示出来ればと思っています。
そこで、上記のようなものを作るにあたって、
タスク一覧のウィンドウとガントチャートのウィンドウへドラッグ＆ドロップで行き来したいのですが、
そもそもそのような事は可能でしょうか？
また、チャートの描画をするにあたって、グラフは2Dで描画しようと思っているのですが、
2Dのグラフィックライブラリ等を利用した方が簡単に実装出来るでしょうか？
もし良いライブラリ等があればご教示いたければ幸いです。
私自身、開発言語はC++かC#しかまともに使用した経験がないのですが、
実行環境のスペックがあまり高いものを準備出来ないので、
Core2Duo/メモリ2G程度、良くても型落ちのi3程度で、
実行速度も考慮したくC++を選択した次第です。
もし最適な言語や、開発手法があれば教えていただけると嬉しいです。
無知な部分が多いと思いますが、皆さんの意見をお聞かせ頂ければと思いますので、よろしくお願いいたします。
それなら、OLE D&Dを実装することになる。具体的には、IDataObject, IDataSource, IDropTargetインターフェースの実装。
c++でテンプレ使って実装を別ファイルで隠す場合、
// h //////////////////////////////////////////////////
template<typename T> class cls
{
public:
template<typename U> U func();
private:
T var = 0;
};
// cpp1 //////////////////////////////////////////////////
template<> template<> char cls<char>::func<char> { return var; }
template<> template<> int cls<char>::func<int> { return var; }
template<> template<> char cls<int>::func<char> { return var; }
template<> template<> int cls<int>::func<int> { return var; }
// cpp2 //////////////////////////////////////////////////
template<typename T> template<> char cls<T>::func<char>(){ return var; }
template<typename T> template<> int cls<T>::func<int>(){ return var; }
template<> class cls<char>;
template<> class cls<int>;
//////////////////////////////////////////////////
cpp1みたいに全部型指定していく場合はビルド出来るんだけど、
cpp2みたいに別けて型指定していくと出来ない。
cpp2みたいな事を実現可能な方法って無いですかね？
そもそも書き方が間違ってる？
ヘッダーで特殊化の方法を指定しないといかんとちゃう？ 知らんけど。
cls::func（）の定義を
U cls::func()
ではなしに、
void cls::func(U& x)
とかにすればおkなｷﾓｽ、
なおそうするとテンプレートの特殊化以前に関数のオーバーロードで解決できてしまうﾖｶﾝ、
void cls::func(char& x) { x = (char)var; }
void cls::func(int& x) { x = (int)var; }
void cls::func(double& x) { x = (double)var; }
void cls::func(std::string& x) { x = std::string(var, '0'); }
...
いくらでも作れる……！
IDataSourceじゃなくてIDropSourceだ。ごめんを。
>>117
特殊化の方法、、、私の知識では分からないですね、、、
>>118
hを、
template<typename U> void func(U& dest);
cppを、
template<typename T> template<> void cls<T>::func(char& dest){ dest = var; }
としてみましたが、状況は変わらずでした。
これ、全組み合わせを書かなきゃダメなんですかね？
template<T, U> みたいなのを、
template<T, int> みたいな感じで一部だけ型指定していくのは無理、
というのは見た事があります。 cpp2の翻訳単位内で完全に実体化させないとどうやっても外からはよべないので
少なくともcpp2の中ではそのように書かないといけないと思う
確実にcppに実体作りたきゃ明示的インスタンス化は個別にしなきゃ駄目だろ
>>121
この場合の特殊化は、どのような記述になるのでしょうか？
>>122
なるほど、やっぱり無理なんですかね？
これ、元となっているのは、
// h /////////////////////////////////////////////////
template<typename T> class cls
{
public:
int func();
private:
T var;
};
// cpp ////////////////////////////////////////////////////
template<typename T> int cls<T>::func(){ return var; }
template class cls<char>;
/////////////////////////////////////////////////////////////
みたいな感じで func() に戻り値の型指定を追加したいな、
って事でやりはじめたんですよね。
綺麗に書くのが無理そうならば、必要な物を全部書いていきます、、、 要求仕様がいまいちよくわかっていないが（ﾏﾃ
(1) 任意の型Tの値cls::varから任意の型Uの値を得たい（一種のconverterクラスを作りたい）
(2) 変換関数cls::func()の実装は隠蔽したい
ということならこんなんでど（ry
http://ideone.com/1Fh8sg >>123
やっぱりそういう物なのですかね
>>125
仕様はそんな感じです
ただ、func() の戻り値をテンプレ使用でなんとかする方法が無いのかな、と
サンプルもありがとうございます >func() の戻り値をテンプレ使用でなんとかする方法が無いのかな、と
func()の戻り値をテンプレにしつつ実装は「完全に」隠蔽したい（ヘッダファイルに書くわけにいかない）となると
やっぱコアとなる変換関数は、必要なTとUの全組み合わせについて「完全に」「非テンプレートで」書かないといけない希ガス
（なぜなら、テンプレートのままcppに書いたら他のcppから呼べない（現行コンパイラはテンプレートの分割コンパイルに対応していない
(2)の隠蔽の要求を多少緩和して、template<class U> void conv(int src, U& dst) { ... } を
ヘッダファイルに書いても良いということならUを返すcls::func()をconv()を1個書いたらできるようにはなる
※ 個人の感想です
※ コードには個人差があります
>>127
となると、現在のやり方でコードを完全隠蔽したいとなると、
全組み合わせをcppに書けって事になりますよね、、、
なるほど、了解いたしました
付き合って頂いた皆様、ありがとうございます ｽﾏﾝ>>127は言い過ぎたかもしれん…
全組み合わせをcppに書く作業をそのcppの中でテンプレートを定義して省力化することは可能かもしれん
ただし、そのcppの中で定義したのと同じシグネチャ（名前＋引数）でユーザーコードが別のテンプレート関数を定義でもしたら、
ODRに違反することになる（この場合実際に変な挙動になる危険性が大きい）ので全体を無名namespaceで囲う必要がありそう
無名namespaceの中から選択的に関数をエクスポートできるのかは正直知らん
あんまりテンプレート絡みで無茶はやりたくﾅｻｽ 定義は共通でして
template int cls<char>::func<int>();
みたいなのを使う分だけ書けば良い
ただ、今回の場合クラス内テンプレート関数の特殊化しようとすると怒られるからさらに工夫が必要
ああ、確かに
使わない関数テンプレートをcppで定義してそれの明示的インスタンス化を通してやれば省力化できそう
この場合その使わない関数テンプレートを内部リンケージにしても、その中で実体化要求されたテンプレートのリンケージには影響はないはず
Visual Studioで通ってもgccで通らなかったりするからテンプレートの実体化は厄介。
VC++がC++擬きの別言語なだけだろ
今ごろになってやっと2 phase lookup対応させた
structとclassが違うとリンクでこけるのも糞
VS2017以降のMSVCは許してあげてほしい・・・
えっ、何か革新的なことをしているの？
C++は今までつかったことがなかったんだが、最近マイコンの開発に使ってから
かなり気に入っている。これならPCでも使えるかもと今考えているところ。
組み込み用途だとC++よりCの方が融通効くと思うんだが
最近の組み込みはひょっとして随分恵まれてるのか
>>137
お前さんの認識が古いだけ
数KBメモリーとモダンなプロセッサならC++で開発は普通にできる ふと思ったんですが、Java でデコレーターを記述するのに
BufferedReader br = new BufferedReader(new InpustStreamReader(System.in));
などと、new したオブジェクトのポインタを取っておかず、new したまま放置してしまう書き方がありますが、
スコープ内で new したオブジェクトは、スコープを外れるときに C++翻訳系が自分で delete する、と決め打ちしてしまうと、互換性で問題がでるでしょうか？
そのポインタを別の場所にコピーしてたらどうなる？
頭悪すぎだろ
>>140
では、あからさまに new したポインタを捨ててしまっている記述に限り自動で delete する、というのはどうですか？
目的は…classpath を共用したいのです、classpath はあらたに c++ で書くとして >>141
そのポインタは渡した先でどうなってると思う？
頭悪すぎだろ よくわかんねえけど楽してJavaを移植したいってこと？
Boehm GCでも使ってみたらどうだ
>>142
new したポインタを捨ててしまっている記述に限り、処理系で delete する、と決めるのですから「ポインタを渡した先」というのは存在しないことになります
>>143
C++ と Java で classpath ライブラリを共用したいのです！ >>145
スマートポインタを導入せずとも、ナマポであっても classpath を共用できるようにならないものか
そのためには c++ 処理系にどんな制限or追加を課せばいいか？ >>142
内容を誤解していました、すみません
あらためて回答します
プログラマが new したポインタ値を変数に取っておく記述をした場合は、delete の責任はプログラマにあるものとし、処理系では何もしないものとします >>116
遅レスだけど、テンプレートはcppに隠蔽しようとか考えない方がいいと思う
dllとかにしたいなら別だけど・・ javaでnewしているからってc++でnewするなって
classpath共用が何を意味しているのかは分からんが
>>147
だからさあ
newして渡した先では殆どの場合はそれをフィールドに入れてるだろ
殆ど100%のケースでは「何もしない」に該当するんだよ >>147
そのオレオレC++拡張の仕様を自分で決めて自分で実装して公開してみな。
万に一つもないと思うが、それを有用だと思って喜ぶ人がいるかもよ。 >>151
んんー、それは c++ 的な扱い（delete はプログラマの責任）でいいかと、私の思考に何が抜けているのかな？もう少し考えて見ます >>139
規格ではdeleteしないものをdeleteしたら互換性に問題が出る。
自動でdeleteしたかったらスマートポインタ使うべき
独自c++擬き想定しているならc++17使うのも当然okのはず
生のnew使わせるなんて今時のc++ではとんでもない悪手 VS2017は十分な出来なんだがテンプレートの展開中に内部エラーで転けることがあってそこだけは不満
shared_ptr でJavaやC#のガーベージ・コレクションとほぼ同じ役目が期待できるから別にいいのでは。
C++は、shared_ptrが正式採用されたC++11で別の言語になった印象すらあるわ。
循環参照が検出できないからJavaプログラムの参照をそのまま置き換えればオッケーというわけでもない
もちろんナマポよりは遥かにマシだけど
>>155
面倒だとは思うけど、時間あるなら再現するコードと共にバグ報告送ってやってくれ unique_ptr<hoge> up0(new hoge());
や
shared_ptr<hoge> sp0(new hoge());
と書いたときと
unique_ptr<hoge> up1 = new hoge();
や
shared_ptr<hoge> sp1 = new hoge();
と書いた時で
違いは生じますか？
生じるとしたらどんな違いですか？
>>159
直接初期化とコピー初期化の違いを説明するとクソややこしい話になるんだけど
結論から言えばその場合はどっちも全く同じ new 呼び出しが少なければ少ないほど精神衛生に良い。
複数の関数の戻り値を足し合わせる処理で、それぞれの関数の戻り値をチェックしたい場合のすっきりする方法は何かありますか？
std::string result;
result += func1(a);
result += func2(b);
result += func3(c);
の各func1,2,3の戻り値をresultに足す前に空でないかを確認したいのです (1つでも空があった場合はresultも空にしたい)
単純に一時変数を用意して一つずつ判定するしかありませんか？
typename Iterator::container_type::value_type
こんな風に::で三個つなげるのは合法ですかね？？
funcN() を追加する直前の result.size() を記憶しておいて、
足した後に長さが増えてなかったら、今呼んだ funcN() の結果は空だった、
と判定することはできるか。
string から整数になるだけで、一時変数を使うのは変わらない上に、
処理内容が分かりやすくなるわけでもないけど。
unique_ptr<int> u(new int[2]{4, 5}); // OK (A) -> int * が作られる u.get()[n] でアクセス可能 *u だめ
unique_ptr<int> u = make_unique<int>(6); // OK -> int * が作られる *u でアクセス可能 u[0] だめ
unique_ptr<int[]> u = make_unique<int[]>(2); // OK (B) -> int [] が作られる u[n] でアクセス可能 *u だめ *u.get() 可能
unique_ptr<int *> u = make_unique<int>(2); // コンパイルエラー (C)
unique_ptr<int *> u = make_unique<int *>(2); // コンパイルエラー (D)
unique_ptr<int *> u(new int *); // ok -> int ** が作られる *u = &hoge あれば **u でアクセス可能
(C)(D)がエラーになる理由と
(B)を(A)の様に同時に初期化したいとき
どう書けば良いか知りたいです
>>168
>>169
ありがとうございます
結局こうすることにしてみました
auto addString = [&result] (std::string&& temp){
if (temp.empty()){
throw 0;
}
result += temp;
};
try{
addString(func1(a));
addString(func2(b));
・・・
}catch (...){
return "";
} void f()
{
static std::mutex mtx;
std::lock_guard<std::mutex> lock(mtx);
//何がしかの処理
}
これっていいの？
セーフなわけがあるか！！１１１１！１１！！！！１！
Double Checked Lockingはジャヴァのメモリモデルがうまく対応できてなくて騒ぎになったことがある技法
もし関数内static変数の初期化をDouble Checked Lockingを使わずにスレッドセーフにしようとしたら、
関数に入る度に毎回馬鹿正直にクリティカルセクションに入るために1000クロックぐらい捨てることになってしまうま
スピンロックか何かの黒魔術で若干緩和する実装も有り得るかもしれんが基本は
ジャヴァではなくてC++の処理系がdouble checked lockingする分には
処理系がサポートするネイティブなアーキテクチャのみ考えれば良いから
問題が生じることは無いはずでとりあえずはめでたいと思うが、
グローバルなスタティック変数のように実行前に初期化する仕様にいまさら変えられない事情でもあったか。
リンカにシンボルを渡す手段がｲﾏｲﾁ決め手に欠くｷﾓｽ
あと複数の翻訳単位間ではグローバル変数の初期化順序は保証されない（保証しようが無い）から
そういう混乱を避けるために関数内staticは関数に入ったとき初期化されてﾎｽｲ
個人的には使わないから知らんが
>>171
unique_ptr<int[]> u(new int[2]{6, 7}); ライブラリを作るときは、hpp にはクラスの定義を、cpp には実装を書く、と理解しています。
クラスのメンバでない関数はどう扱うべきでしょうか。
hpp にプロトタイプ宣言を、cpp に中身を書く、というので合っていますか。
なぜヘッダはクラス限定だとおもったんだ?
それ以前にクラス以外では使用したことがないのか?
宣言（Declaration）と定義（Definition）は用語なんで覚えといた方がいいよ
ヘッダに書くのはクラスだから関数だからとかじゃなくて、複数の翻訳単位(≒cpp)で共通で使うかどうかで決まる
1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ
>>190
inline なので（苦笑
>>191
ハ？
回答の体をなしていない。
> hpp にプロトタイプ宣言を、cpp に中身を書く
というやり方は許容されるという意味か。
>>192
覚えました。それで？
>>193
であれば、今私は複数の cpp ファイルを持つ予定はないので、ヘッダファイルは全く不要ということになります。 ライブラリなんだろ？
自分はcpp1つでも、他の人のcppで使わせるためのクラスや関数があるはずだ
それをヘッダに書け
>>195
その際、「プロトタイプ宣言はヘッダで、中身は cpp ファイルに」というルールかマナーか慣習はありますか >>196
特にないから適当に他人のマネしとけばいいと思う。 >>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ
staticは付けた方が良いですか？(苦笑 内部リンケージにするには static を付けるよりも
無名の namespace に入れる方が良いやり方
みたいな雰囲気があるんだけど、
インデントが深くなるのがなんか嫌なんだよね。
インデントは文法に影響しないわけだから、
付けないという選択肢もとれるけど、
それはそれでなんだかなぁって感じだし、
結局は static を付けちゃうんよ。
無名 (unnamed) namespace って使う？
関数よりファンクタの方が速いという情報を見たのですが、メンバ関数を入れ子クラスでメンバファンクタ化すると高速化が期待できますか？
VC2017で試したのですがテスト用の関数が単純すぎるのかグローバルのインライン関数、クラスのメンバ関数、クラスのメンバファンクタで差異が見られませんでした・・・
どこに書いてもいいだろ
他人の書いたコードなんてどうせ誰も読まないし
読ませたいならドキュメントしっかりさせたほうがいい
>>202
その「ファンクタの方が速い」ってのは、一般的に関数ポインタを介するのと比較して、だよ
理由はインライン展開できるからであって、その実験で差異が出ないのは当然 ストアドよりインデックスのほうが速いよってスレなかったっけ。
>>199
使う理由としてはメンバ関数を内部リンケージにしたらリンク速くなるかもという期待だけだな
実際速くなるか調べたことないけど
明示的にstaticとある方が読みやすいし、無名はデバッガで見たときクソ見辛くなるし
c++はこういうダメ仕様多過ぎてうんざりだわ 腐ったビルド戦略のせいで無駄なオブジェクトコードの重複を生じるのはゼロオーバーヘッド原則に反しないのか？は疑問だな
極一部のマニアしか使わない機能付けてオナニーしてる暇があったら、いいかげん時代錯誤なビルド処理の抜本的な見直しをやってほしい
メンバ関数の数はクラスのオブジェクト生成コストにどれくらい影響しますか？
ありがとうございます
というのもメンバ変数がなく多数の関数をまとめただけのクラスがあるのですが、次のどれがいいのか悩んでいまして
(1) 全部static関数にする
(2) クラスをnamespaceにして全部グローバル関数にする
(3) 呼び出す場所で逐次インスタンスを作成する
(4) 呼び出し側クラスでこのクラスのポインタをメンバとして持ち、コンストラクタでインスタンスを受け取るまたは生成する
この場合のベストプラクティスはありますか？
特に何もないなら2
templateと組み合わせるなら1とか3は多用するけど4は無いな
ありがとうございます
(2)でやってみることにします
1 は、どうして君はすべての関数を、static 関数にできると思ったの？
static関数と、関数のライブラリ・モジュール化は関係ない
3, 4 は、どうして君は、関数を使うのにインスタンスが必要なの？
インスタンスの関数は、他の言語ではメソッドと言って、
そのインスタンスのメンバ変数を使うものに対して、特別な名称を付けている。
つまり、各インスタンスで値が異なるもの
メソッドは、一般的な関数とは異なる。
メソッドや一般的な関数と、関数のモジュール化は関係ない
例えば、Ruby では、
Math.log2( 8 ) #=> 3.0
このようにインスタンスを作らなくても、呼べる関数をモジュール関数と言って、
各インスタンスから呼ぶ関数を、メソッドと言って区別している
そう言われるとそうですね
オブジェクト指向ではmain関数以外全部クラス/構造体で作成するものだという先入観がありました
>>214
無理矢理4にしたいケースを考えると、同じインターフェースを持つ関数群A,Bを場合によって切り替えて使いたい場合に敢えてインスタンスのポインタとすることもあるかな。今回の質問者の場合には当てはまらないだろうけど。 >>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ
名前無しでも何でも良いが、その場合はクラスはnamespaceの中に入れないと危険が危なすぐる…
同じ名前空間に属する同じシグネチャのFoo::func()が異なる関数として複数のcppで定義された場合、
どっちが呼ばれるか定まらない処理系が実在する（VC++2010とか
多分ODR違反で未定義動作なんだと思う 曖昧さは、利点にも欠点にもなりうる。
namespaceのグローバル関数ではなくクラスのスタティック関数にすることで曖昧さがなくなりコンパイルエラーを避けられる場合がある。
>>219訂正
CPPでクラスを定義する場合は無名namespaceに入れないと危険が危なすぐる、
無名namespaceは異なる翻訳単位間では別名として扱われるから安全
一方、名前付きnamespaceでは異なるCPPで偶然
同じ名前空間に属する同じシグネチャのFoo::func()が作られてしまう危険性を排除できない >>220
そのクラスに非staticなメソッドを設けたとたん、
>>219と同じ話でどのFoo::func()が呼ばれるかわからないという不正な動作をする危険性が生じる
驚くべきことに、VC++2010の場合リンカが何のエラーも警告も出さない
それでいてしっかり変な動作になる（a.cppで定義したFoo::func()を呼んだつもりがb.cppで定義された同じシグネチャの別のFoo:func()が呼ばれる >>216
C/C++では、staticなどキーワードが全く違う複数の意味で使われるから注意な。 Ruby では、関数名のバッティングを避けるため、2重に囲む。
module 内にclass か、class内にclassを作る
module Net
class HTTP end
class FTP end
end
# インスタンス
Net::HTTP.new
Net::FTP.new
>>224
rubyボットはお呼びでないからもう巣に帰ってくれ static みたいな複雑な概念を、初心者が理解するのは難しい
スコープを限定する意味と、生成・破壊のタイミングの違いと、
2つの異なる概念を使うから、難しい
C++ は、すべてのリソースの生成・破壊のタイミングを追っかけるだけでも、大変
ドワンゴ江添の本「C++11/14 コア言語」にも書いてあるけど、
呼ばれる関数を探索する方法に、Andrew Koenig が提案した、実引数依存の名前探索 (ADL)もある
実引数依存の名前探索とは、C++において関数呼出時に与えられた引数の型に依存して、
呼び出す関数を探索 (lookup)する仕組みのことである。
英語ではKoenig lookup、argument dependent lookup (ADL)、argument dependent name lookupなどと呼ばれる
>>216
>>212の(1)はクラスのstaticメンバ関数のことを言っているのだか、>>216や>>226を見てるとそれを理解していないように思える。
いつも書籍や他人の発言を引用して～～では、という書き方ばかりしているのを見かけるが、自分の中に落とし込んで理解できてないならわざわざ書き込まないでくれ。 質問(ネタ振り)に対して見当違いな返答は混乱の元ってのはその通りとして。
読者の立場では、話題が広がってくのは嫌いじゃない。
投稿者の意見として消化しきれてなくても、
参考資料として「誰それの書いたナントカって本では…」と
紹介してくれるのも有難いし。
その上で「あの著者/本は間違いが多い、例えば…」とか、
「記述が古い、新しい規格でもっと便利な機能が追加された」みたいな
追加情報(具体的なもの)が出てくればなお嬉しい。
名前なし名前空間を名前あり名前空間の中に作ることができる。便利ちゃあ便利。
namespace hoge {
namespace {
int foobar = 1;
};
};
64bit環境で文字列ストリームクラスstd::ostringstreamのインスタンスのスタックサイズが、
gccで376バイト, VS2017で232バイトもあるんだがもっと小さくできるんじゃないの？
ちなみに、std::string はgccとVS2017どちらも32バイト。
どうよ？
>>232
std::ostringstream は文字列の一種というよりも入出力の系統だし、
std::basic_ostream を抱えているのでそんなもんちゃう？ 継承してるしデータとして保持しておくものでもないしな
>>232
質問と関係ないけどスタックサイズって何かわかってないだろ ostream, ofstream, ostringstreamのスタックサイズはgccとVS2017でそれぞれ以下のようになる。
gcc: ostream=112, ofstream=264, ostringstream=232
VS2017: ostream=272, ofstream=512 ostringstream=376
どうよ？
間違えた。gccとVS2017は逆です。
何が言いたいというと、組み込みで気軽に使えるC++を目指すならiostream周りを何とかしないとね、という話。
組み込みで気軽に使えるC++を目指してないしどこまで削れるかはベンダーの努力次第
Cがコンパイル言語であるにもかかわらずprintf()系の構文解析でJITコンパイルする野暮ったさを解決すべく導入されたはずのiostreamがまったく活かされていないね。
その程度のスタック消費でヒーヒー言うような組み込み案件でiostream使わんだろ
>>241
スタック消費でヒーハー言う組み込み案件に進出するのもC++のひとつの課題なのでは有馬温泉 組み込み界隈がC++を活用する目標があるのであってC++の目標ではない
from_chars
to_chars使えって話だろ
それかfmt
class C : public std::function<int(int)>{};
というクラスを定義して、
int f(int i){ return i + 1; }
void main()
{
C c = f;
int i = c(1);
}
みたいな使い方って出来ないのでしょうか？
functional のヘッダを読んでみましたがさっぱりでした
>>245
やりたいのはこういうこと？
class C : public std::function<int(int)>{
using std::function<int(int)>::function;
}; めっちゃ雑にやったけど、
実際にはスライシングに気を付けてな。
>>246
すいません、
知識不足でそのusingが何を意味しているのか分かりませんが、
std::function<int(int)> と、
class C : public std::function<int(int)>{} を、
外側から同じように使いたいという感じです。
現在は、
class C { std::function<int(int)> F; };
みたいになっており、
C c;
c.F = f;
int i = c.F(1);
と、こんな風に使われています。
std::function<int(int)> を継承させてしまい、.Fを消したい感じです。 >>248
単純に
class C : public std::function<int(int)>{}
とした場合、当然だけどクラス C にデフォルトで定義されるコンストラクタは
C::C(void); と C::C(const C&); だから、型が int (*)(int) であるような値を受け取る余地はない。
using std::function<int(int)>::function;
を入れると基底クラス std::function<int(int)> のコンストラクタである
std::function<int(int)>::function; をあたかも C のコンストラクタみたいにできる。
そんだけ。
public 継承してれば std::function<int(int)> の他のメンバはそのまま C のメンバとして
見えるからおおよそ期待する挙動になると思う。 >>249
なるほど、そういう意味だったのですね。
ちょっと試してみます。ありがとうございます。 >>237
2ファイル同時に編集なんてしたらあっという間に食い潰しそうね >>244 が提示してくれた from_chars, to_chars をgccに導入するにはどうしたらいい？
WSLのubuntuを使ってるんだけど規定でfrom_chars, to_charsの定義されたヘッダーファイルが入ってないっぽい。 >>254
たしか8.0でまだ整数しか実装されてない C++テンプレートテクニック第三版っていつ出るんですかね？
テンプレート引数がクラスでpush_back()メンバを持っているというようなことを検査することはできますかね？
std::is_classとdetection idiomで可能かと
でてくしょんいでおむってどの本見ればわかりますかね？
std::byteの使い方がよくわからない。
暗黙の何とかを避けるのに使うんだろか。
単純にバイトを表現する型というのが必要となった
char8_tと同じようなもん
1バイトサイズの整数のつもりでcharを使ったらstreamで困ることがあったりしたしね。
enum class byte : unsigned char { };
ってなってる。
そのベースの型は実装依存
型を取りだして使えってことなんだろうか
なんでenum classなんだ？
typedefと何が違うの？
でも過去にそれで何かあったんでしょ
使うかどうかは任意だしある分には困らない
is_enum_vがtrueになるとか違和感しかない
>>265
なんで
uchar8_t
uchar16_t
uchar32_t
にしないんだろな >>273
ひとりで全部作ってんのか？
誰か使い始めたらそれに巻き込まれるんだよ void foo(std::function<void()> &&f){}
int main(){
auto lamda = [](){};
foo(lamda);
}
なぜコンパイルできるの？
>>282
int main()
{
return main();
}
なぜコンパイルできるの？ int main(std::function<void()> &&f){
return main([](){});
}
すいません、低レベルのかたたちばかりでした。
聞くところ間違えました
なぜc++ main return省略でググらないのか
getoptを標準化してしまうとハイフンで始まる変態ファイル名が鬼門になってしまうかな。
is_iterator、is_containerメタ関数はどうやったら作れるんでしょうね？
iterator_traitsに通してメンバ型が得られるか確認する？
*とか++とかの操作について確認する？
containerはbeginとendでイテレータ取れるか確認する？
template <typename T>
using is_iterator = std::is_class<typename std::iterator_traits<T>::iterator_category>;
これは使えますかね？
結局はそれで何がしたいかによるんじゃね
標準のコンテナやそのイテレータで型分岐したいなら十分だけど、カスタム実装されたユーザー定義のイテレータがそのように実装されているかは分からんし
まあiterator_traitsの特殊化も追加で書くようにすれば使えるか
C++20からは一応イテレータはコンセプトがあるなあ
コンテナは知らん
>>293
はダメな気がするな
template<typename T,typename=void>
struct is_iterator:std::false_type{};
template<typename T>
struct is_iterator<T,std::enable_if_v<std::is_class_v<typename std::iterator_traits<T>::iterator_category>>>:std::true_type{}; >>296,297
アホか、何がマウントだボケ
自分で試しもせずに2chに丸投げとか普通にダメだろ
>>298
iterator_traitsに与える型の要件(だけでいいかどうかはさておき)を満たすなら特殊化なんかいらんでしょ
リファレンス見る限り、iterator_traitsの特殊化はポインタのためだけにあると思う >>300
どの本もそういう書き方になってるんだけど、その理由がわからない。
>>293は呼び出し方によっていろいろ問題が起きるんだけど、その理由がわからなさすぎる。
その辺がスッキリわかる本はないですかね。 本は知らん
SFINAEが使えるのは宣言部分
そこで置換失敗すると宣言そのものが無かったことになる
>>297
マウントが取りたいだけで教える知識がないだけやねんｗ そう
分からない質問には自分で試せ
これがC++使ってる奴の特徴
規約はあるけど「実装が規約」をやっちゃってる部分が多くて、
しかもコンパイラのバージョン依存がひどいってのがc++だからな。
規約は語れても実際にどう動作するか語れない輩も多いだろうね。
どなたか iostreamの存在価値について熱く語ってくれないか。
米国時間4/2にローンチイベント行ってるから日本だと3日かな
>>306
だから分からないのにマウント取るのやめたら？ >>314
バカだろお前
ID:Zu3OGTTsはSFINAEでググれと言われてSFINAEは知ってると言ったろ
その上で>>302の書き込み見ておかしいと思わんのか？
それに>>300で答えは出てるだろうが
> だから分からないのにマウント取るのやめたら？
お前のことだよ このスレの住人は、新しいVisual Studioでどんなことに期待してるの？
Windows formsのC++へ移植してmfcを完全に抹消してくれ
けっこう癖が強いよね。例外やpimpl否定したり。
まあでかいプロジェクトはこんなもんだろう。
例外は実際よくないと思うわ。
pimpl否定ってあったっけ？
うちのプロジェクトも原則例外禁止
むかしは一律禁止だったけど
googleのスタイルガイドは和訳が古くて英語版しか読まなくなって何年にもなるが追いついてるのか？
例外無しとか小規模の組み込み以外で意味あるのかね？
例外使った時点で疎結合もへったくれもなくなると思うわ。
能力的に幅のあるプロジェクトで使うには難しいよ。
>>339
> 能力的に幅のあるプロジェクトで使うには難しいよ。
これには同意するけど
> 例外使った時点で疎結合もへったくれもなくなると思うわ。
意味不明
例外以外の方法使っても似たようなことをする羽目になるだけ
なら意図が明確な例外のほうがマシ 戻り値なら呼び出し元と呼び出し先の間の結合だけだが、例外はよりコールスタックの根本の方へ結合が及ぶことがある
フレームワークのように、例外を使ってあえて中間をすっ飛ばしてコールスタックの上と下を結合させるケースもあるけどね
念の為補足するけど、Javaの検査例外みたいに常に直上での例外処理を強制するスタイルは戻り値と事実上等価だからここでは論外ね
つまり標準ライブラリのほとんどを使うなと言うこと？
他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。
C++ だけの (新規の) プロジェクトなら全く例外を使わないというのは極端なスタイルだと思うが。
例外があると、それが理由で上下の階層が深いシステムになりがちだと思うよ。
節度があれば正直なんでもいいが、言語的にクソ設計を許さないのならその方がありがたい。
c++じゃないところからc++のコード呼び出すなら例外外に出さないようにtry catchでラップするだけだし
逆で途中のコードが例外発生したために解放処理が飛ばされるってなら、raiiクラス化しろって話にならね？
通信経路でやり取りするなら相手が例外処理で実装されていようがされていなかろうがなんの関係もないし
>>347
要は、メッセージングが至高ってことだな 例外だしてどーすんの
ミッションクリティカルで直せるの？
意味ないじゃん
例外使いたきゃ専用言語使えばいい
>>345
> 他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
> そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。
もうそういう極端な例でしか反論できないことはわかったよw >>336
微妙に修正はされてる。
てかクソなc++本読むよりかよっぽど各機能の利点、問題点が簡潔に書けてると思うが。 >>335
pimplに限った話じゃないけど、前方宣言とそれによる定義の隠蔽が推奨されていない。 >>338
大規模なところでも例外禁止あるから
mozillaもそうでしょ
AAAなゲームスタジオでも多い
性能引き出したかったらそういう厳しい制約がいるんだよ >>352
グーグルのガイドラインが極端なのは当たり前だ。
超巨大なエコシステムで成り立ってるわけだし。
例外を使わない派がしばしばグーグルのガイドラインを持ち出すんだけど、
そのガイドラインにすら、最初から設計してたら違ったかもしれないという
文言があるので、 C++ を使った設計理念一般としての強い根拠にならんのよな。
私としては、一般的な C++ での設計の参考にするべきは標準ライブラリだと思う。
標準ライブラリはその言語の思想をよりはっきりと体現するものだし、
それに沿って作ったものは連携しやすくもある。
(昔からあるライブラリの一部は変な個所もあるが。)
>>346
C++ はクソ設計でもどうにか形には出来るっていう方向性だと思う。
まともな設計ならそれが一番良いにきまってるけど、
それが期待できない場合が大半だという現実がある。 例外禁止とかの環境って、
newの失敗とか毎回チェックするの？
規約を守る守らんってことにしか目がいかんのな。
やっぱ馬鹿ばっかだわ。
>>360
newの失敗のチェックって何するの？
null返ったかどうかのチェック？ 例外処理機構が無かったら、メモリ確保に失敗しても、
そこから過去のロールバックができない
自己流で、long jump するぐらいなら、例外処理の方がよい
>>363
いや、失敗したら駄目だろ。失敗しないのが正しい。
プログラミング言語如きが考慮すべき問題ではない。 >>363
そのロールバックってのはCとmallocじゃできないようなものなのかな。 new失敗とかコンピュータが壊れてるからチェックしても意味ない
当然特殊なケースは除くからな
一応言っておかないと組み込みガー君とか宇宙線でエラーガー君が飛んでくるからな
>>359
＞私としては、一般的な C++ での設計の参考にするべきは標準ライブラリだと思う。
設計ではなく使い方の参考に、という意味では賛成だけど
テンプレートバリバリの設計はあまりにもコストがかかるというのを知っといて欲しい
ああいうのは湯水のごとく時間をかけられるからやれるんであって きみらはあれか、元記事とか全然読まずにコメントするクチか
リンク元には「例外は全く新規のプロジェクトならデメリットよりメリットが優先するので使って良い。
ただ既存のグーグルプロジェクトは元々例外を想定していないのでこれに例外のパターンを導入する
とリスクのほうが多いのでやめるべき。ただし Windows については例外がある(駄洒落ではない)」
と書いてあるんだがちゃんと読んだか。ちなみに駄洒落ではない、は俺が追加したのでなく元の文にある
>>368
そんな極端な意味では言ってない。
手間が合理的な範囲内で「参考」には出来るよって程度の話。 エラーにはリカバリーすべきものとそうでないものがある
あとそのエラーが起こる頻度の違い
リカバリーしないものはその時点で即死するのが正しい
リカバリーするものでかつエラーが普通に起こるものはエラーコードで処理するのが正しい
となると残りのリカバリーするものでかつたまにエラーがおこるようなのが例外にする価値があるエラー
あと例外発生時のunwindが重いからそれでも問題にならないもの
となるとあんまり使えるとこないんだよね
そういうわけで最近例外なしの言語がでてきてる流れなんだろう
>>366
コンピュータが壊れない限りメモリ確保が失敗しない環境って凄いな。。。 例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう
問題残したまま実行続けて別の関係ないところで落ちるのが最悪
runtimeで落ちて困るような用途でも、
ソースコードあるやつなら静的解析で例外発生箇所網羅出来そうなものだが
網羅できればリソースリークする危険な場所わかるし、対処も出来るのにね
逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね
>>374
> 例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう
その場じゃなくstackが全部巻き戻ってからでしょ >逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね
んなもんコンテナで隔離する以外使い道ねーわ。
>>376
仕様ってのは例外外に出すか出さないか、
出すなら出し得る例外の種類のリスト
出さないならエラー毎にエラーコードやら返し方やら決めるって話 そうなんだよね
例外の仕組みわかってないやつは平気で動的ライブラリの界面に
例外使ったりするんだよね
あと標準ライブラリ丸出しにするやつもしかり
それ誰も互換性保証してねーから
まあ標準ライブラリの例外の使い方のおかしさも気になるが
std::stoiで例外投げるバージョンしか無い上に何故かlogic_error扱いのinvalid_argumentやout_of_range投げる
いや、これ出る状況普通runtime_errorだよね
>例外含めて外部仕様としてかっちり決まっているべきものじゃね
そこを言語の機構で保証できない、動的言語みたいななあなあ状態なのが残念なところだね。
それをきっちり保証しようとした検査例外はそれはそれで扱いづらいところがあるし。
>>371
リカバリーするかしないか、頻度が高いか低いか、どちらもプログラム（特にライブラリ）を書いてる時点では
言い切れないから困るんですよねぇ。 >>372
無限にnewできる理想郷に住んでるんだろw
相手しなくていいよ 復旧不可能な例外もあれば、些細な例外もあるよね。
戻り値チェックで十分でしょと思うようなところで例外を投げるJava/C#みたいな流儀だと、いちいちキャッチするのが面倒。
Cでは戻り値で判定できたはずのエラー種別が例外クラスで細かく分類されてしまったことで、
エラー処理で書かなければならないコード量が増えて例外のキャッチ漏れまで起きる危険性が生み出された。
その程度の知識で語ってる奴は戻り値方式でも処理漏れするだろw
例外の嫌なところは
処理できない案件を低水準側に丸投げするところなんだよな…
ユニックスのプロセスの死亡順序もそうだが、
計算機業界は常識が逆転してゐる…
というわけでおそらくアプリの設計ｼﾁｭの99%ぐらいは
例外発生＝プログラムの死亡
、とみなして良いはず
ここまで割り切るならはじめて例外はお手軽で便利と言える
例外をキャッチしたらプランBに移行するのが、真の戦闘のプロ。
例外なんてグローバル変数みたいなもの。
だから低レイヤで使うのは仕方ない
std::cin >> a;
は入力を延々と待っている。
これ別スレッドから止めさせる方法はありますか？
（組み込みはともかくアプリの場合は呼び出し元の方が高水準レイヤにあたるのではないかというツッコミが来ると思ったが
来なかったので黙っていよう…
>>390
プランBったって、プログラム起動時にあらかじめmallocしておいた何キロバイトかをfreeして
ダイアログを出して[OK]で終了、ぐらいなんじゃ… >>388
いや、プログラムでは、呼び出し側の方が高レベル、呼び出された側が低レベル
なので、呼び出された側が例外を投げた場合、高レベル側の関数で処理できる
ので適切。 多くの例外の基底クラスになる exception にエラーコード整数値を出力する関数があればもう少しC寄りのエラー処理ができたと思うのだが。
既存のexceptionメンバ関数 const char *what() だけでは扱いが困難。
>>397
必要ならそういうクラスを定義するだけだろ ユーザーにエラー原因を示すだけならconst char*でも大して問題ないし、
catchした側でエラーコードによって何かするというのはたいていアンチパターン。
文字をwchar_tで処理しているプログラムだと例外文字列作るのが面倒
まあ詳細な情報出さずに固定文字列にしてしまえばいいんだけど
templateの使い道がいまいちわからん
STLやboostみたいなものは非常に有益だが
同僚がドヤ顔でコンテナを作ったって自慢してたが、
stlのコンテナを使わずにそいつのコンテナを使う理由が無い
>>403
困ってないなら使わなくてもいいと思うよ。
困る場面がある人のための機能。 同じコードをコピペしなくて済むから、作業量も減るし、保守も楽になる。
>>403
せやな
ただそれは作るものの需要の有無の問題だ 重複があることを事前に発見するのは難しい場合もあるから、
同じことを何度も書いている気がするなと思ったら
どうにかしてまとめることを検討するという程度でもいいかもね。
同じことをしないようにする、いわゆる DRY 原則というものはあるけど、
一方で、それを意識するあまりしなくてよい抽象化層を設けるのも馬鹿らしいということで、
必要になってからやるという YAGNI という考え方もある。
こういうのは程度問題なので、なんでもほどほどにね。
テンプレート（のパラメータにおける型の自動推論）と
関数のオーバーロードの合わせ技によるコードのまとめ力は異常
例えばストレージからintを読み込む関数、doubleを読み込む関数、unsigned charを読み込む関数を
同じ関数名と同じ引数の並び（例えばbool read(FILE* fp, <目的とする型>& x とか）ででオーバーロードしておけば、
template<class T1, class T2, class T3>
bool read_x3(FILE* fp, T1& x1, T2& x2, T3& x3) {
if (!read(fp, x1)) { return false; }
if (!read(fp, x2)) { return false; }
if (!read(fp, x3)) { return false; }
return true;
}
でもって、オーバーロードを実装した任意の型3個の組み合わせについて読込関数が実体化される
（実装されていない型に行き当たったらエラーになるからﾜｶﾙ
これはn個の関数と1個のテンプレートを書いただけで、n^3パターンもののユースケースに網羅的に対応できたことになるからｽｹﾞｰ強力
※ 個人の感想です
>>409
そこはfpも抽象化でしょ。
intハンドル、FILE*、iostream、HANDLE などなど派生関係のないものをtemplate化できる。 なおこのﾃｸをつきつめれば、テンプレートの特殊化というのは普通の意味では要らなくなるｷﾓｽ、
むしろ特定の型の組み合わせについて自動展開を禁止したいときに使う
（例えば可変長データのread関数を、データの先頭にデータの個数を書く約束で作ったとして、
個数を読み込む関数を整数のread(fp, x)に限定したい場合、個数の型をdoubleにした特殊化テンプレートを書いてわざとエラーにするとか、
>>410
FILE* fpは十分汎用的でしかも最大限高速なので他への代替の必要性はほとんど考えられないし、
サンプルコードでむやみに凝っても仕方が無い
※ 個人の感想です テンプレートはヘッダに全部書かなきゃいかんのなんとかならんか？
テンプレートの分割コンパイルは一度実装されたが1年がかりの複雑な仕事になったし
あまりに複雑すぎて普及に至っていないというようなことがプログラミング言語C++で読んだ記憶、
しかし、importキーワードがC++の予約語であるうちはまだ希望がある
FILE* fp は 標準のfgetc()の実行速度が遅くて残念。バッファリングしている甲斐がない。
使いたい型決まっているなら別にできるだろ？
ヘッダで宣言だけ書いて、ソースで定義と明示的インスタンス化すればいいだけ
3大C++無限ループ話題
テンプレート実装の分割記述
getsetの実装
あと一つは？
あるクラスが非トリビアルなコピーコンストラクタをもっていることを検出したい
そのクラスのメンバの型が非トリビアルなコピーコンストラクタを持っていたとしても。
>>413
テンプレートを抜き出してヘッダーファイルを生成するプリプリプロセッサを作ればいい >>421
トリビアルコピー出来ないことを検出したいならis_trivially_copyableで充分だけどそれ以上のことがしたいの？ >>409
糞抽象化の見本みたいなコードだなw。
そのうち使われなくなる種類のコードだ。 >>411
＞ 個数の型をdoubleにした特殊化テンプレートを書いてわざとエラーにするとか、
そういうときはdelete指定が使えるんじゃね？
というかis_floating_pointとかで弾いた方がいいとも思うけど >>409
x3とかつけない方が良くね？
てかvariable template使うところだね 明確な定義があるわけじゃないけど、主に「勘違いした高卒が高等な他人を見下してること、もしくはその様」を指す語としてつかわれてんじゃないの
>>432
猿などが優位だと主張するために
相手に馬乗りになること
こういう場では、
相手に反論した（つもり）なら満足し、
反論を受けると過剰反応を示す奴をさすことが多い。 >>435
＞相手に反論した（つもり）なら満足し、
＞反論を受けると過剰反応を示す奴をさすことが多い。
その説明だと某クソコテしか思い当たらないんだが・・・w オープンソース化されたWindowsの電卓を見たが、クッソ綺麗でモダンなコードだな
>>438
あの手のコードって意味ないよな
無意味に11や14で追加された機能をなんかを使いたがるやついるわー
そういったやつに限って仕事が遅い
ウンチクはいいから、さっさと終わらせろよ Windowsカーネルのオープンソース化待ってます
sort関数の比較関数を、クラスのメンバ関数として定義すると invalid use of non-static member function というエラーが出ます。
なぜこれは禁止されるのでしょうか。
また、どうやって解決したら良いですか。
理屈を知ってる人には当然だけど、初めての人は混乱する部分じゃないかな。
sort で使う比較関数は色んな形で宣言できるけど、宣言する場所によって
エラーにならずに使える関数の形式が違うってやつ。
>>442 メンバ関数にした比較関数のプロトタイプ宣言はどんな感じ？ 非staticメンバをstaticのように使おうとしたときに出るエラーだからsortとか関係ない
Class::funcをsortに入れたんでしょ
Class().funcとするかfuncをstaticにするだけ
Class::funcってstaticじゃないの？
->*みたいな書き方の意義がわかったら一人前どすな
>>444
bool mycomp(string a, string b);
です 結局その場でラムダ式書くのが一番わかり易いんだよね
エクセルで使われているようなGUIにちょっとしたアニメーションをつけるには何使えばいい？
>>454
例えば四角形の座標の終点の値と移動にかかる時間をするだけでヌルッと動いてくれる機能があるやつがいいです 普通にcのsort関数使えばいいのに。
キャストしたら負けとでも思ってんのかね。
std::initializer_list<int> l()
{
return std::initializer_list<int>{1,2,3};
}
std::vector<int> v()
{
return std::vector<int>{1,2,3};
}
int main()
{
for(auto i : l()){
std::cout << i << endl;
}
for(auto i : v()){
std::cout << i << endl;
}
}
0
0
0
1
2
3
なんで？
>>458
std::initializer_listはちょっと変わったクラスで、コピーやムーブしても中身が付いてこない
関数の戻り値にしてコピー省略とかが入ったとしても同様 >>456
cのsort関数はアドレス連続性がないコンテナには使えないでしょ。
vector::sort()とCのsort()の速度はあまり変わらないので、わざわざCのsort()を使う理由がない。 cのsortってラムダ渡せないし、ワザワザ面倒くさい記述してまで使う意味無いだろう。
template<typename T>
T func(T a){
}
という関数の中身として、T が int なら a*2 を返し、T が double ならa/2 を返し、それ以外なら a を返す、という処理にしたい場合どう書いたら良いのでしょうか。
関数ごと特殊化する方法があるのは勉強したのですが、一行分の処理を特殊化するために関数ごと特殊化するべきなのでしょうか。
簡単化のため、必要さが全くない例になっていますがよろしくお願いします。
STLが天才なのは分かったけど、遅くなりそうなのも分かってしまった。
>>463
簡単化しすぎて何を質問したいのかよくわからない
その例の程度の処理なら、intとdoubleの関数をオーバーロードして、template関数でデフォルトの処理も書けばいい
intとdoubleをどうしてもtemplate化したかったら特殊化で書けばいい
前後に長い共通処理がある場合の一部式だけ個別にしたいなら、関数オブジェクトで式を引数にとる補助template関数作って、上記手法で型毎にlambdaで式を変えて補助関数を呼び分ければいい >>466
特殊化する部分を関数として切り出して特殊化すれば良いということでしょうか。 >>450
まずは、エラーなくコンパイルが通って実行できるまで。
単純には、比較関数をクラスの外に出して「メンバ関数じゃない関数」にする。
たぶんソートしたいクラス中には比較する文字列以外のメンバもあるだろうから、
class myclass {
public:
string s; // 比較対象の文字列
int other; // それ以外のメンバ例
... // 他にもメンバ色々
};
こんな感じだと思う。
比較関数は、2つの myclass 型のオブジェクトのメンバ s 同士を比較するから、
bool mycomp(const myclass& a, const myclass& b)
{
return a.s < b.s; // 辞書式の昇順
} あるいは >>468 の段階はすでに通過してて、
「今度は比較関数をクラスのメンバ関数にしてみよう」と思ったのかな。
bool mycomp(string a, string b);
このプロトタイプでクラスの「staticでないメンバ関数」にすると、
その関数はクラスのオブジェクトを介して obj.mycomp((string)a, (string)b)
という形で呼び出さなきゃならないのよ。
ところが std::sort() が比較関数を呼び出す場合は
どのオブジェクトとも関係ない mycomp((string)a, (string)b) を呼ぼうとする。
「クラスのメンバだけど、クラスの個々のオブジェクトからは独立した関数」に
するために、関数の宣言に static を指定する。
class myclass {
public:
string s; // 比較対象の文字列
int other; // それ以外のメンバ例
... // 他にもメンバ色々
static bool mycomp(const myclass& a, const myclass& b); // 比較関数
};
(「改行多すぎ」につき、もう一回だけつづく) (>>469 の続き、長々とすまぬ)
関数の定義(クラス定義の外に書く場合)はこんな感じ。
bool myclass::mycomp(const myclass& a, const myclass& b)
{
return a.s < b.s; // 辞書式の昇順
}
myclass のメンバ関数だと明示するために myclass:: をつけることと、
定義の方には static をつけない、てところが注意点。
std::sort() で使う時は、
std::sort(std::begin(objs), std::end(objs), myclass::mycomp);
「比較関数には myclass のメンバ関数の mycomp() を使ってくれ」と明示。
…する必要が(俺の環境では)あるんだけど、myclass 同士を比較することから、
自動的に myclass のメンバ関数も候補に入れてくれても良さそうな気がする。
なんでダメなんだろ？ たかがソート一つ実行するのにこれってやっぱc++は失敗しとるわ。。
>>468-470
丁寧に教えてくださりありがとうございます。
今のところは、>>468に書かれているようにクラスの外に出す、という方針で対応しておりました。
クラスの中で static をつけて宣言をする、というのが元々やりたかったことに一番近いように思います。重ね重ねありがとうございます。
>>470
> std::sort() で使う時は、
> std::sort(std::begin(objs), std::end(objs), myclass::mycomp);
> 「比較関数には myclass のメンバ関数の mycomp() を使ってくれ」と明示。
これは、mycomp() をクラス内で非static に宣言したときにも使えますか。
それとも、クラスの外で
bool myclass::mycomp(const myclass& a, const myclass& b)
{
return a.s < b.s; // 辞書式の昇順
}
流に宣言、定義した場合に限りますか。 何のために非staticにこだわるんだ？
メンバにアクセスしないならstaticつけとけよ
比較関数をメンバ関数としてクラスに内在させるのが良くない
外部化するか、演算子オーバーロードする
どちらかと言うと比較関数を作らずに大小関係を定義する言語だ
実は、関数やクラスの間の包含関係がある
クラスを比較する関数はクラスの外部におかれるべきであって、メンバ関数にするのは筋が悪い
クラス内部に置くなら大小関係の定義にすべきだ
この手の階層関係は、規格書にもどんな教科書にも一切書かれてないけど、暗黙のうちに了解されている
対称な演算子をインスタンスメンバにするのはセンス無いね
>>463
template <typename T>
T func(T a) {
if constexpr (std::is_same_v<T, int>) return a * 2;
else if constexpr (std::is_same_v<T, double>) return a / 2;
else return a;
} >>477
これの方が関数として切り出して特殊化するより好きな見た目です >>477
それだと実行時に判断コストがかかるじゃん if constexprってtypeidで情報取ってきて比較するみたいなオーバーヘッドが0になりますか？
おじさん久々にC++の仕事受けたんだけど
色々進化してて面食らってます
今、右辺値参照っての勉強中なんだけど
ムーブコンストラクタとかはへーへーほーほー言いながら何となく分かり始めた
んだけどさ、
int &&x = 2; // ok <-これだけ使い途が分からん
ローカル変数の右辺値参照て何に使うん？
実験してみた限り、勝手にムーブとかしてくれるわけでもなさそうだし
ローカル変数に&&付いてると何に使えてんな時便利なの？
>>482
右辺値参照はほぼムーブコンストラクタのためにあると思っていいと思う
左辺値参照と同じように書けるというだけで、使うことはないかと 変数宣言した右辺値参照そのものは左辺値という罠
極力そんな物作るべきじゃないね
>>489
if constexprにするとコンパイル時に評価されて特定の分岐のみが実体化される >>484
回答ありがとう
なるほど、文法上は書けるから仕様上厳密な定義はされてるけど、普通は特に使わないで良いのね 初心者がやたらとアスタリスク使ってポインタの参照値を得ようとするのに似た感じがある。
他言語に移植しにくいだろ、テンプレート化しにくくなるだろ、と小一時間。
アスタリスク使ってポインタの中身取ったらあかんのか・・・
multimap よりも set の vector の方が便利なのですが、異端ですか？
>>482
既に回答がついているとおり、 rvalue 参照はほとんどムーブのための機能。
ローカル変数的に使う理由はあんまりない。
テンプレート関数の仮引数や auto 変数として rvalue 参照 (の記法) が現れたときは
特殊な推論規則 (ユニバーサル参照) が適用されるというのは気を付ける必要がある。 ローカル変数もそうだけどintみたいなオブジェクト性が低いものに使っても意味ないわな。
rustの古いチュートリアルのmoveの例がなぜかintでクソだったけれど最近は文字列型になっとった。
考えうるメソッドが少ない＝オブジェクト性が低い、とかじゃねえの
int型の変数.length() とかは流石に意味不明に見える
言いたいことは分かるが聞き慣れない言葉を使っているということでは
リテラルが右辺値ってのがよくわからんのだが
上の例のように右辺値参照でうけるとリテラルなのにそのアドレスがとれてしまう
かつ書き換え可能
なので右辺値参照にリテラルいれるときは、一旦名前のない領域にコピーされていると理解している
でもこれって通常の値の代入のときも名前のない領域にコピーしてからさらにコピーというセマンティクスなの？
右辺値を参照で束縛すると、その右辺値の寿命は束縛してる参照と同じところまで引き伸ばされる
この点は左辺値参照も右辺値参照も一緒
一見リテラルのアドレスが取れて書き換えられる、ように見えることに疑問を持ってる
言い方変えると
右辺値参照に代入するとき
リテラルが右辺値でなくて、そのコピーが右辺値なのでは？
そこに寿命がどう関係あるのかわからない
アセンブラレベルで言うなら、即値なのかdataセクションにあるのかの違いじゃないの
>オブジェクト性
コピーでも参照でも対してコストがかからんものというかそういうニュアンスなんだが
思った以上に伝わらんもんだな。
わかりやすいようにintと文字列を例に出してもこんなもんかもね。
>>508
C++のリテラルというのは右辺値を生成する式なんだよ
「42」は値42を持つint型の右辺値を生成することを指示するリテラル
「"hello"」は中身が'h','e','l','l','o','\0'なchar[6]への参照を生成することを指示するリテラル
プログラムが実行時に扱うのは「リテラル」じゃなくてリテラルが生成した右辺値だ
その生成された右辺値は当然メモリ上にあっていいし書き換えられてもいい
（その必要がないならコンパイラがそうじゃないように最適化してももちろんいい）
「コピー」だと思うから違和感があるんじゃない？
リテラルなるものの実体が空の上やPCの隙間に隠れてるわけじゃないし、プログラムはそんなものは取り扱えない >>512
リテラルは右辺値でない、が正しい？
それなら半分なっとくだけど
ググるとリテラルは右辺値という説明がでてくる >>512
まだ半分なっとくできないのは、
上にも書いたけどリテラルで普通に代入するときも、
一旦右辺値を作ってから左辺にコピーする、というのかc++のセマンティクス？
なんか無駄すぎて釈然としない 牛からは牛乳が出るけど牛は牛乳じゃないだろ？
そういうこと
リテラルってのは文法要素なの
演算子とかキーワードとかコメントとかそういうものの仲間なの
実行時にはそんなものは出てこない
プログラムが扱えるのは「値」だけで、左辺値とか右辺値というのはその分類
int型の0x2Aという値を生成しろという命令をコンパイラに作ってもらうためにプログラマが書くものが「42」というリテラル
さっきからずっとそこを混同してる
そりゃ、代入の左辺にリテラルを置ける言語なんてまずないから。
コピーのコストを抑えつつ、二重に参照されないように元のオブジェクトを指す変数を無効にしたいってのが
moveに期待される機能。
即値だったり呼び出しの引数にコンストラクタごと放り込まれた場合には
上記のような二重に参照されるようなシチュエーションにはならんのでmove受けする関数が定義されてれば
その関数を呼びましょうってのがc++のmoveの取り扱い。
しかしこんなにもシンタックスが複雑で機能性も新しくてオーバーロードでさらに複雑になってるってのは
やっぱよくないと思うわ。
テンプレートの都合でオーバーロードが必要なのもわかるが明らかにやりすぎ。
会社にもいるわ、そんなどうでもいいことをウンチクばっか垂れて一向に仕事が終わらないやつw
言語を設計するなら、必要かもしれんが大抵は不要
「だからC++スゲー俺スゲー」ってやつじゃないの？それ
>>521がそうだとは思えんが 最近は彼らもRustにマウント奪われて必死なんだよ
理屈がわかってないのに仕事が終わってるのもそれはそれで不気味じゃない？
>>525
moveなんか理解してなくてもだいたいのC++の現場では仕事に支障ないよ >>527
君はC++の30年の歴史を否定するのかい？ templateも使うことは、OKだがtemplateを用いたクラスを作ることは禁止されている場合がおおい
そもそも、設計段階で型が決定しないなんてことは、汎用ライブラリを書く以外はないだろ
いやいや
決まっていてもそれが複数だった場合使うだろ
あと普通にライブラリは作るものじゃ
ていうか、普通に仕事をしていたら「ああここは処理共通だからまとめて・・
・・あとここをこうしとけば拡張にも対応できるし・・まあ客が無茶振りして
きたときの予防にそれなりに汎用性もたせとくか」とかやっているうちに
いつのまにかライブラリができあがってる、これがプロの仕事だ
定数って参照透過性があるよね。
C++はconstexprがあるのだから、関数型プログラミングを超える、定数型プログラミングという新パラダイムを提唱したいと思います。
コンパイル時レイトレーシングとかやってる人もいるけど狂気の産物って感じがして C++ ぽくて良い。
しーぷら一筋30年～、速いの、上手いの、やっすいの～
>>534
＞コンパイル時レイトレーシング
一応訊くけど、ああいうのはレイ当てる3Dオブジェクトのデータは
全てC++のソースに書かないといけないことは分かってる？(モデリングデータをファイルから読んでコンパイル時にレイトレするのは当然不可能)
あの試み自体は面白いと思うけどね・・
実用性や(ソフトウェアの)ユーザーの利益にならないことをもてはやさないで欲しいもんだが プリレンダのゲームは大量にあるしレイトレーシングしとくのもその延長線上じゃない
コンパイル時ファイル入出力がサポートされればいいわけだ
それにレイトレーシングはまあ確かに冗談も含まれてるだろうけどそれだけ複雑で重い処理でも可能だという技術デモは価値があるだろう
画像にフィルタを適用するとかパターンが決まっているエフェクトを生成するだとか色々できて可能性はあると思うよ
汎用的につかってもらうことを目的としているライブラリを除けば
コーディング時に型が決まっていないことなんてありえない
もしあるならそれは設計してないってことじゃん
templateなんて汎用的につかってもらうことを目的としているライブラリを書く場合にしか使わないだろ
後で、intからdoubleになるかもしれないから、なんて言ってるバカいるけど
きっちり設計しろよ
>>538
コンパイル時にやることじゃない
新たなc++の巨大トラップだよ
ますますc++嫌いになった メタプログラミングってコンパイル時に評価してゼロオーバーヘッドとかすごいとは思うけど
学習コストや可読性と釣り合ってるか？
仕事で4月になったらまた新しいメンバーシップ増えるけど
なまじ趣味でc++使ってたやつが一番困る
新しい機能使いたいだけでトータルの生産性考えないんだよね
そんな一部の現場の実情を忖度してたら競争に負けてしまうのではないか？
毎回同じこといってる奴いるよな
このスレには10人くらいしか居ないってネタは挙がってるし
>>545
釣り合う点がどこなのかは人それぞれだから各自が判断してバランスいいところで使えばいい。
チーム開発ならプロジェクトごとに指針を決めれば良いかと。 >>545
やってることの性質にもよる
サーバーサイドなんかで潤沢なリソースを使って長時間動くものだとほとんど意味はないよ
その場合.NETやJavaのような実行時コード生成の方が遥かに柔軟性が高く、オーバーヘッドも実質的にはほとんどない >>536
それ自体はただの余興だけど、
コンパイラのバグを顕在化させる成果を出したりもしてるよ。
処理系の開発チームにとってもまずは問題を発見できなきゃ直せないからさ、
色んな形で使ってみる人だってそれはそれで必要なんだよ。
処理系の質が良くなるのは間接的にユーザの利益にだってなる。 >>539
きっちり設計できている現場ばかりだったら本当によかったのにね。 >>551
まぁその理屈はわからんでもないしメタプログラミングやってるとあの人のブログは勉強になるけどね
ただああいうのはブラックジョークの類であることを忘れると>>537みたいな勘違いした奴が出てくる
>>538
＞画像にフィルタを適用するとかパターンが決まっているエフェクトを生成するだとか
それ、画像もコンパイル時に確定してるデータじゃないとあかんのやで？
(しかもconstexprなcharの配列みたいな、C++のコードに直さないといけない)
重ねて言うけど、面白い試みだけど実用的ではないんだよ、ああいうのをC++的だとかカッコいいとかもてはやすのはC++の衰退を招くだけ
趣味グラマは自分が趣味グラマであって時に実用性からかけ離れてるということを自覚すべき あ、でも
>>538
＞コンパイル時ファイル入出力
これはやり過ぎな気もするけど個人的にはあっても良いとは思うw
ただ、画像のフィルタリングをコンパイル時にやるのとツール作って実行時にやるのとで
前者が便利な場面ってあるのかね？(しかも前者は非常に開発コストかかる >>553
コンパイル時に確定しているデータがあるかもしれないし無いかもしれない
fstreamがコンパイル時に動くようになればいいだけ
そうなれば準備が面倒なプリプロセスも必要ない
研究に対して実用性がうんたらとかわけ分からないことを言うのはよくないなあ
様々なアイデアから自分の都合のいいところをつまんで実用化するのが末端の仕事だろうに
俺が使い道が思いつかないことに熱心になってると界隈が衰退するとかさすがに草生える 静的なものはなんでもコンパイル時に解決するって思想が典型的なハンマー釘病なんだよ
コンパイル時だけが解じゃない
そのうち仕事で特に理由なくむやみに重いconstexprぶちこむやつがでてくるだろう
それでビルド時間5分10分長くなったりするわけだ
ほんとc++はクソ
>>556
問題があるならお前が指摘すればいいだけだし
リリースビルドのときだけコンパイル時計算になるようにすればいいだけ
工夫がたらんなあ >>555
constexpr関数みたいにコンパイル時にできる、実行時にしか出来ない、を「自動で振り分けて問題なく動く仕組み」
の範囲に全て収まるならそうだろうな
後半煽ってきたのでキツめに言わせて頂くが、コンパイル時レイトレはソース公開されてたろ？
あれを実用したゲーム開発の例を一つでも挙げてみろ
有意義な研究ならとっくに実用されてんだよボケ
あるいはボレロ氏の試みに同調して何もかも(ファイル入出力すら)コンパイル時に出来る言語にしよう、なんて動きが委員会に起きてるのか？
お前多分まともにメタプログラミング出来てるレベルじゃないのに調子乗ってるだろ >>558
これだけ複雑な処理も出来るんですよっていうだけの話だからレイトレーシングである必要はない
それができるならこういうこともできるんじゃないか？ってなるのが普通
あとゲームのソースは公開されないから知るかとしか言いようがない
C++20でコンパイル時動的メモリが追加される予定だし、実行時でもコンパイル時でもタイミングが違うだけだからいつでも何でもできていいだろっていう流れは既にできている
標準化委員会がボレロを認知しているかは知らん コンパイラで高度なことが色々できるし、原理も実現も公開されてる、
興味を持って調べれば(ある程度なら)理解だってできるかもしれない。
というのはC++の素晴らしい部分だと思うのよ。
で、調べて知ったことを使って試したい、他の人に紹介したいってのは
これまた自然な気持ちだろう。自分もそういう面があるし。
実際に複数人で協力して作る実用プロジェクトで機能を使うかどうかは、
「コンパイル時間」だの「高度化・汎用化で読みにくくなる」だの、
トレードオフの問題になるけど。
分からないのは、「俺はこれ知ってる、お前は知らないだろ」と
他人より優位に立つ材料としてしか知識を使ってないような
投稿が見受けられることなんだよね。
ことにネット掲示板なんて、見ず知らずの他人同士なんだから、
相手をバカにしたって仕方ない、何の益もないだろうに。
>>559
＞それができるならこういうこともできるんじゃないか？ってなるのが普通
最初の方の主張からずいぶんと縮小したなw
＞あとゲームのソースは公開されないから知るかとしか言いようがない
ググれ
ソースの公開なんかされてなくとも技術の動向くらいあちこちで紹介されてる
＞C++20 いつでも何でもできていいだろっていう流れは既にできている
今調べたら確かにそうみたいだな、俺の認識不足だったし出来ることが増えること自体は悪くないと思う(前にもそう言ったが
ただ、
＞コンパイル時にやるのとツール作って実行時にやるのとで前者が便利な場面ってあるのかね？
この疑問に答えて欲しいもんだけどね
＞俺が使い道が思いつかないことに熱心になってると界隈が衰退するとかさすがに草生える
ならお前は使い道を知ってるんだろ？って話 正直、ファイル(C++ではない)に書かれてる内容に従ってコンパイル時条件分岐とか手軽に出来たら
結構実用性はあると思うよ
ただその一方で、ここでプロとアマチュアのC++に対する意見がひどく乖離してる(このスレ見てたら気づいてないとおかしいが)ことに
全く問題意識が無いのであれば、それは結局自分が偉そうにしたいだけってことだと思うけどね
constexprの拡張とか、そんなに開発現場(アマチュアでもソフト開発者等)から求められてなさそうなことにばかり
最近のC++は注力しすぎじゃないの、ってだけの話なんだけどね
ここでそれを言うと毎回荒れるんだよなぁ
愛知県人注目。遠州地区の技術者も注目。
[急募]
豊川ハローワーク管内の求人で、SEの席に空きがあります。
四月スタートの仕事なので、急いで応募して下さい。報酬は、
月に20万円から60万円。
英語力は必須ではありませんが、『実はTOEICのスコア以上に
英語ができる』と面接では答えて下さい。（英語は入社してから
頑張って下さい。）
ネットワーク関係が得意だと言って下さい。JP1の経験があれば、
なおよし。ECUの経験があれば、さらによし。キャティアのマクロが
書ける人、大歓迎。（これらは、必須ではありません。）
>>557
それがお前の案？
手動じゃんそれ
くそださいとしか
仕事では数十人規模でやってるわけで、そんな人力チェックしたくないわけよ
プルリクぐらいはやってるが全て見きれるわけじゃない
まずはビルド時間の推移とか、内訳を監視するタスクを回すことを考えるだろうが
そういう非生産的な仕事が増えることがクソなんだよ C++の新機能なんて大半の開発現場にはいらんだろ
前いたところは初心者向けの教科書を読めばだいたいわかる基本的な構文しか使ってなかった
constexprもなければテンプレートもラムダ式もなかった
コード書けん奴がコードレビューするからそんなもん使った日にはわかりやすく書けとか怒られた
>>567
できあがった物の性能を少しでも上げようっていう話なんだがそれに価値を見いだせないならどうでもいいよ
つまんねえから口を開かないでくれ まぁconstexprのコンパイル時コストを気にするだけなら多分ifdefでdefine CONSTEXPRとかすればいいだろうけど
メタプログラミングはやっぱコンパイル時間長くなる
個人で開発してても無視出来ないわ・・
>>571
性能上げて比較結果を出してから言うべき ていうか>>560の言ったことを実証するかのような流れだなww >>571
一般に、無駄な拘りに時間かけるのを避けてその分ボトルネック潰しに時間をかけたほうがソフトウェアのパフォーマンスは良くなるよ 関数型同様、定数型プログラミングにもアンチがわいてきましたか。
アンチがわいたってことは、定数型プログラミングが世の中に受け入れられたってことでいいですね？
その機能自体への好悪もあるか知れないけど、
「導入されたからには直ちに覚えて使わないのは罪悪」あるいは
「使わない奴は学習能力の劣る無能、使わないのでなく使えないんだろ」
みたいな、新機能の押し付けが嫌がられてるって部分もあるんでないかな。
>>576
関数型持ち出すやつが、c++のconstexprの持ち上げたらいかんだろ
関数型はそんなキーワードなしに部分評価するだけで実現できんだから Googleの結論
Think twice before using template metaprogramming or other complicated template techniques;
think about whether the average member of your team will be able to understand your code well enough
to maintain it after you switch to another project, or whether a non-C++ programmer or someone casually browsing the code base will be able to understand the error messages or trace the flow of a function they want to call.
https://google.github.io/styleguide/cppguide.html#Template_metaprogramming 【定数型プログラミングの掟】
> 「ブッ殺す」と心の中で思ったならッ!その時スデに行動は終わっているんだッ!
>>580
それ逆効果じゃね
Google社員でも使いこなせない機能を使いこなす俺スゲェwww 自分の知らない概念を勉強するって意味ならlispのマクロでも覚えたほうがはるかに有意義なんだが
そうしないだよね。
なぜならそれじゃ老害にマウントできないから。
まあそういうクソみたいな思想のやつが年取って老害化するんだけど。
>>545
コンパイル時に決定していることしかできませんよ
コンパイル時に3の階乗を計算して、ドヤってるやついるけど、それなら6ってタイプしとけよw コンパイルに時間かかるから、その間暇つぶしに裏でレイトレーシングして遊んでんのかと思った
>>580
「同じプロジェクトで働く他の仲間はアホかもしれない、
あなたの仕事を引き継ぐ奴はボンクラかもしれない、
だから難しい機能を使うのは自重しましょう」って感じか？
一見「あなただけは特別な存在です」と言ってるように見えて、
実は現場の全社員を見下してるような文面だなぁ。
「技巧に走るより素直な書き方をしろ」って趣旨は分かるんだけど。
>>588
参加者の順列で生じるパターンの状態を記録する配列の要素数、
しかも参加者数は変更の可能性あり(コンパイル時には確定する)、
という場合なら contexpr の階乗関数を仕込む意味はありそうね。 constexpr指定するだけのことが技巧的なのか知らなかった
I/Oや動的メモリと関係なさそうなところに脳死で適当に付けておくだけでいいのに
基本的に新機能は分かりやすく書きやすくするためのものなんだけどな
数学への回帰と先祖返りじゃないの
分かり易くなるんじゃない、難しくなるんだよ
template<typename Item>
Item Fool::InsertItem(const Item& item)
{
//なにがしかの処理
item.c_str()...
}
こんなコード見かけると吐き気がするわ
c_str()を持つ型しか使えないじゃん
なんのためにtemplate使ってんだよｗ
何か変か？
c_strを持っているクラスのみを想定しているんじゃないの
本当はSFINAEで消すべきかも知れないけど
>>598
だからコンセプトの導入が悲願とされてるんだよ。 basic_stringの特殊化に限定するなら文字型を受け取るだけでいいと思うんだけど
>>598
constexprでコンパイル時に特定のメソッドがあるか調べられないの？ それは型の情報だから、すでに言われてるようにメタプログラミングでsfinae使って調べるしかない
アレルギーが重症化すると辺境で難癖付けて騒ぎ出したりテンプレート指定すると何故か生産性が落ち出したりするからな
pythonみたいにエラーメッセージ表示してくれるだけで大分マシになると思うんだけどな
そうなんだよね
1500行のエラーメッセージの代わりに「itemのメンバ関数c_str()が見つかりませんでした」ってコンパイラが言ってくれてたら
ここまでテンプレートは嫌われなかった
だからgoのコード生成系のアプローチのがマシってことなんだが馬鹿は脳内でしかビルドしないから通じない訳だ。
>>609
それはC++20でコンセプト入ったら実現されるはず(ライブラリ側で対応する必要あるけど エラーメッセージがわかりにくいなら、VC++を使うべき。
過去のことなんかどうでもいい
未来だけ見て生きていこう
>>613
コンセプトは最近出てきた概念じゃないぞ
C++11が0xとか呼ばれてた頃から言われてた話 >>598
嫌なら実体化しなければ良いんじゃ…
仮にFooのインスタンスを生成したとしても、Foo::InsertItem()を呼ばなければFoo::InsertItem()は実体化されないはず… 今思えばC++0xのコンセプト案はいろいろ酷かったな
あのまま入らなくてよかった
コンセプトマップだとかコンセプトを満たすことを自己申告しなきゃいけないだとか
傍目に見て正直意味わからんかった
Axiomはとてもいいと思ったが、消えたのだな・・・
>>588
フーリエ変換の係数みたいなものは実行時には定数だけれど、事前に計算式で計算しておきたくはなる。
でもまあ普通に考えればビルド構成の問題だわな。
なぜコンパイラに無理やり突っ込むかと言えばまともにビルド構成を考える能力がないからっていうね。 axiomさんは契約アトリビュートとして生まれ変わったのだ
コンパイル時に決定してることしかできないなら、コード書く必要あるか？
1+2しか計算できないんだろ、2+3の結果が欲しかったら、コンパイルし直しｗ
狭義のアルゴリズム（有限ステップで終わる）を記述する分にはそれで十分
無限ループを含む手続きを記述したかったら無限再帰すればええ
と考えればメモリが無限にあればコンパイルが終わるまでに任意の処理ができる
コンパイル時に畳み込んで定数にした方がよいかどうかはコンパイラの最適化で頑張って欲しい話で、
それで足りない、さらなるチューニングが必要なときの記法が統一的だったらうれしいねっていう程度の話じゃないかな。
普段からそんなにコンパイル時計算を意図したりはしないよ。
P言語でC++中間コードを生成するスクリプトを書けばいいじゃない。
swigみたいな。
カスタムコンパイルやカスタムビルドはそのためにある。
ヤック、レック相当をメタプログラミングで実現することができるのではないか。
スピリチュアルな方向性ではなく。
PEG 相当のことを実現しているライブラリとしては Qi があるけど、
Yacc みたいに LALR をやってくれるのは知らないなぁ。
出来るのかな？
>>628
個人的には、メタプログラミングで定数値のパラメータ作るのに構造体でメタプログラミングする必要が無くなったのはconstexprにかわしゃ ごめん間違って送信した、
constexprに感謝してるw
あとビット演算とか整数値の計算する関数もconstexprつけときゃテンプレートパラメータに渡せるし
高速化は二の次だと個人的には思ってる
sprintf_s()と_cuntof(array)がどこの環境でも標準で使えるならchar[]も悪くない選択肢ではある
boost spiritはコンパイルが糞遅いし、何か間違えると何処が原因かさっぱりわからんし、
実用には程遠かったな。テンプレートでここまでできるという一発芸的な。
テンプレートメタプログラミングって元々はアンチパターンとして提出した例だったんだけどね。
本当に愚者というのは度し難いというか。。
CStringをこの世から完全に消し去って欲しい
せめてbasic_stringと互換性のあるインターフェースを持たせてからフェードアウトして欲しかった
CStringT::Format()系関数は、sprintf()系関数を2回呼ぶので冗長。
利用バッファサイズを事前に指定できないことが原因。
>>643
だから天井人がお前ら下々に分かるレベルにしてやるよってことで様々な改良が加えられてるんだよなあ
それでもまだ分からないとなったらどこまでレベルを下げればいいんだってなって頭抱えちゃうよ CStringは、Windows用のC++のクラスライブラリ、MFCの文字列クラス。
>>645
冗長って言われても一度パースしないと必要サイズはわからんからしょうがないだろ
まあ1KB程度のバッファー持って処理中に足りなくなったらパースし直すとかでもいいとは思うが 便利さを求めるならなんかフレームワーク使えよ
軽さを求めるならchar配列でゴリゴリ書けよ
性能も利便性も標準より低いフレームワークさん・・・
>>649
素直にsnprintf()のように最大バッファサイズを指定するオーバーライド関数を追加すべきでしょ。
CStringT::Format()関数を呼び出す側は、あらかじめサイズを予想できる状況にあることが多い。 >>646
天上人のつもりなのがそもそもの問題なんだがな。。
最近の標準委員は明らかにプログラム組んでなさそうな連中が決めてるような感じだし。
c++なんかは顕著だがそういうマウントの取り合いによる新機能拡充が一番現場を疲弊させてるっていうことを
なんでわからんかね。 MFCが出来た頃のstd::stringはそりゃまあ酷いシロモノだったんじゃ
あまりCStringを責める気にはなれん
いくらリリース時に型がすべて決まってるはずと言ったってDRYはそれなりに大事だろ
>>653
標準化委員会の議論とまともに論理的な議論のできない5chを同一レベルで扱うなよ しかし旧石器時代にSTLが作られたことを思うと、オーパーツと言ってよいのではないか。
数学的に洗練されたこの美しさ。
古代人は数学が得意だったのでは。
>>654
まあそれはある
でもstlが普及してからも互換性が全くないまま終了したので負債になってしまったのは悲しい >>652
C言語に毒された老害かよw
欲しけりゃ自分で実装しろよ >>657
そうか？
全然そんなことないと思うぞ
MFCのはもっと酷かったからそれよりマシかなって程度 >>660
簡単だから当然、実装はする。
下手にバッファサイズを測る手間をかけるくらいならバッファサイズを渡せという話。
バッファサイズを渡せば速度が通常のCStringT::Format()より30～40%ほど改善するんだから、公式でも採用してもらいたいという趣旨。 gccとvcでは vsnprintf()の挙動が違う。va_listの内部実装が異なるからだろう。
gccの場合、同じva_listを使ってvsnprintf()を複数回呼び出すと…
>>664
どうせ弄るなら、va_listとか旧世紀の遺物つかわなくても、templateの可変長引数を使って１から作り直した方が良い。 va_listを他の関数に渡した後で、va_startで初期化せずに再使用するのは未定義動作
何が起きても文句は言えないしコンパイラごとに挙動が違うのは当然というものだ
>>668
それはつまり、gccではCStringT::FormatV()相当の実装が困難ということを意味している。
バッファサイズを自分で渡す仕様が最適解ということ。 >>664
そんな旧態依然のインターフェイス欲しけりゃ自分でやれやってことだろ それにつけてもostringstreamの醜さよ。
clang++使ってみたら、std::async使えない・・・
さすが、フリーだな
clang++使ってみたら、std::async使えない・・・
さすが、フリーだな
CStringのくそ設計にいまさら文句言ってもなぁ
そもそもメンバ関数、しかもdestination側と言う時点で使う側の利便性考えていない
遅いしフラグがいっぱいあるし読みにくいし
ostream& T::operator<<(ostream&, const T&)やistream& T::operator>>(ostream&, T&)をTにつき一種類しか定義できないから
万全の汎用性を有しているかというとそうでもないし、
唯一の長所は型安全なところだが、意図通りの出力になるまでどうせトライ＆エラーすることになるのだから
それ以下の工数でprintf()の書式ミスを発見できるわ；；
CStringをdestination側に使うときの書き方はｽｹﾞｰｶﾝﾀﾝ
CString cstr;
cstr = "Hello World!\n";
でおkコピー程度でCstring::Format()を使う必要はﾅｽ、
ソース側に使うときはむしろstd::stringよりｶﾝﾀﾝ
printf("%s\n", cstr);
で通る
まあ個人ｋ的にはprintf("%s\n", (char*)cstr); ぐらいで手を打つが
>>653
ここはマウント取りたいだけのバカが沢山居るけどさすがに標準化委員会は違うだろ
ただソフト開発者や標準・boost以外のライブラリ設計者はほぼ居ないんだろうなとは思うが 標準化委員会はよくも悪くも開発者目線だなあとしか
提案者の用途さえ満たせれば良い的な仕様が多々見られる
最近だとto_charsとfrom_charsなんてまさにそんな感じ
>>656
江添レベルの奴がやってる時点であんまここと変わらんだろ。
初心者に初めからautoで宣言させたコード実行させようとするような馬鹿だぞ。
初心者のためよりも自分のエゴ満たすためってのがあまりに優先されすぎてる。 >>682
そんなわけないが
研究者だけでなく様々な企業のエンジニアも参加している
お前らの好きな組み込み業界や自動車業界も人を派遣してる つい最近まで「トライグラフは現場でバリバリ使いまくってるから無くしちゃダメー！」って必死に訴えてる人達がいっぱい居たのが標準化委員会だよ
初心者にauto使わせるのは悪くないというかむしろそうすべきだろ。
現場が疲弊云々はそんな現場辞めてしまえとしか
標準化委員会はc++バリバリに使っている現場の意見が十分反映されているのだから
文句があるなら委員会に参加すれば良いんだよ
>>690
そうじゃない
688の思想は、Cにも取り入れる方向だろう あれで現場の意向が本当に入ってると思ってる奴がいるのか？
c++の衰退とかデータで見ても信じない連中なのかね。。
まるでどこぞの統計データを今でも信じてる連中みたいだ。
メモリやCPUが安価で高性能になれば、コンパイル言語全般のシェアが下がるのは当然なのでは。
現場にはcとc++が違うことを知らない奴も多いwww
実際現場の意見入っている感じするじゃない？
どちらかと言うと実装側の都合でデグレードされたりすることが多い
コンセプトいい加減入れろよと
エラーメッセージわかりづらいし、SFINAE面倒くさいんだよ
>>688
＞初心者にauto使わせるのは悪くないというかむしろそうすべき
型や参照、ポインタ、修飾とかの違いでコンパイルエラーになるのを経験しないのは危険だと思うけどねぇ
推論された型を勘違いした上にたまたま通ってしまう可能性もあるわけだし
便利なのは否定しないけど静的型付け言語であるC++のパラダイムを変えるような機能ではない >>697
そういうことを言っていいのは出来合いのtypedefを使わないで全ての型名を愚直に書いている奴だけ >>685
この書き込み自体がもうね
江添の考え方に反対するならそう言えば良いのに、エゴとか完全に個人攻撃しちゃっているじゃない 結局ビャーネって何を作ったの？
言語の仕様なんかは磯さんが決めてんでしょ
陰謀論を唱えるような人は、先入観が強すぎて不具合の原因を見つけ出せずに時間を浪費するタイプの人だから、プログラマをやめるべき。
MISRA-C 2004 の本は、トヨタなど大企業の50人が書いた本だけど、
ドワンゴ江添の本は、彼1人で書いたから、超人技！
Linux プログラミング・インタフェース、Michael Kerrisk、2012
この本とともに、神の書と言える！
KADOKAWA が言ってる。
当社はプログラミングの会社ではないけど、
なぜか、プログラマーが多いし、募集もしていますw
>>686 裁判費用をクラウドファウンディングで捻出する予定はありますか ファンクタって1回だけ使うならインスタンス生成する分関数より高コストで繰り返し使うなら生成済みのインスタンスを再利用できるから低コストという認識であってます？
>>701
あの教え方が本当に初心者のためになると思ってんの？
完全に書く側の都合による本にしかなってない。
ああいうメモリ意識の低い本で教えることはc++を使わせる上でマイナスにしかならん。 >>712
なるだろ？
想定している利用者像が違うだけ
始めにauto使わないように慣らされたら、どうでも良い場面で型指定するバカに育って逆に面倒臭いだろ
まあ一番の害悪はnewやdelete、果てはmallocやfree使わせる奴だが
動的多次元配列でnewをループで入れ子にするのとか最悪 昨今のスクリプト言語は大抵autoじゃねえの
そうすりゃ初心者と型システムの都合なんてのはクソくらえ、だ
入門者にゃ型なんて意味無しじゃん
それに初心者にどうやってマイナスかどうか確かめたのか怪しい
ついでに型＆autoとメモリ意識とは違うからな
大体intとかあまり生で使わんよね
少なくともtypedefしておくもんじゃね
このスレ住民は、 auto によってコンパイル時には分からない意図せぬ動作で困った経験ってある？
c++って便利なのは便利なんだが、やっぱ遅いよ
stream,asyncなんか、使い物にならん
いや、コードを書いてるやつがいつまでも成長しない
だからコードが遅くなる
それがC++wwww
>>715
いや、流石にintは生で使うだろ。
intで十分な意味持ってるんだが、
どんなtypedefするんだ？ Visual Studio使ってたらインテリセンスがautoをコンパイル前に展開して表示してくれるけど
テンプレート以外で変数がコンパイル前に決まらないことってあるの？
テンプレートならauto使う必要なくね
>>653 >>686
経験豊富なプログラマが沢山参加しているのが事実なら、船頭多くして
船山に登る状態なのかも知れない。 >>692
実感として、年々汚くて使いにくい仕様が増えている気がする。 >>714
たいていのスクリプト言語は動的型付け
autoと同じと考えてるならレベル低すぎ >>722
仕事で流行ってる流行ってないなんて関係ないだろｗ 流行ってない＝情報がない、人がいない、資産がない＝ゴミ
ビジネスの都合しか考えられないゴミ
JavaとかC#使ってれば
ビジネスの都合でc++って場合が多いだろ
ここに居るような奴等は
>>727
wとかsとか付いたのが無駄に増えて面倒になったな
int32_t とか uint32_t とか uint64_t とかは賛成 >>733
そういう名称の問題だけに限った話ではなくて、結論から言えば、仕様を
多数決で決めてしまうと初心者向けの言語になる。スクリプト言語とかに
近いような。
構造的な問題とか、統一感的な問題とかもあるし、そもそも、C/C++の
良さまで失うような標準仕様だとかも、例えば、boost などの、
stl = standard template library なんかも、ここでは信者が多いかの
用に見えるけど、まるでC/C++とは思想の異なる全く別のスクリプト言語の
ような仕様になっている感じがする。 >>734
STL否定している時点で、そもそもC++の想定しているユーザーからは外れているんじゃね
iostreamならともかく >>735
1998年くらいまでのC++はまあまあ良いと思っていたが、それ以後、別の
言語になってきてる気がする。特にここの人はSTL信者が多いが、
実は、98年くらいまでのC++とは似ても似つかないものだよ。
それを使ったコードには、往年の C の片鱗さえも残ってない。
だから、言語名から C という冠を下ろすべきだ。 信者も何も標準コンテナ使わずに何使うんだよ
自前で書くとかそれこそダメな方向だろう
eastlなんかでも使用感をなるべく標準に近づけているのに
C++98以前のC++が今より良いってどんなマゾだよ
template自体嫌いなんかな
それもうCで良いじゃない
C++ の仕様に STL などというものは存在しない。
かつて STL と呼ばれていたものは完全に C++ の一部になっているし、
仕様の他の項目と区別する方法はない。
C++ 使いが C++ の機能を使うのは当たり前だ。
気に入らないと思うのは自由だし、良くない部分だって実際あるが、
常識的には標準が用意しているライブラリは言語の利用方法を体現するものであって、
言語の基本思想と極端に乖離してるわけないだろ。
標準ライブラリだからといって使う義務はないわけで
最小限のランタイムで動くnative言語というところがc++を使う理由になってるプロジェクトが多いだろう
その目的にそぐわないのが今の標準ライブラリのデザイン
メタプログミングの遊び場とかしている
ただし20年前と比べるのはどうかと思うが
標準ライブラリをどうしても使わなきゃならんってことはないけど、
使わないための積極的な理由がなきゃ標準を選択するよ。
リソースが制限されているところで使わないっつーならそれはそれでいいよ。
それも出来るのが C++ だからな。
結論から言えば、STLはライブラリとしての「センス」が悪い。
POSIX の fopen()系や printf() 系などは使いやすいと思っていたが、
STLにはそれを感じないし、coutも変だったが STLもそれと同じ轍を踏んでる感じ。
>>743
お前さんのレスからは、｢僕の好みじゃないからヤダヤダ｣という程度のことしか見えてこない。 やっぱりネットは駄目だ。
頭の悪いプログラマが支配してる。
>>747
意味不明だな。誰でも入手できるライブラリで、なおかつ、
昔のC/C++より誰でも出来るスクリプト言語よりだというのに。
言ってることが逆さま。 cout よりも printf が相対的に良いという人はたくさんいると思うが、
iostream が特に駄目ってだけで、
C++ 的に見れば printf がセンスいいとはとても言えんぞ……
昔みたいにドヤ顔してboost使う必要がなくなったのはいいことだと思うよ。標準が充実していってさ。
最初からヌエ的な発展しかありえないのはそういうものだと思うし。
ただ、多数決というのは、正しくも良くも無いけどな。
だったら君が最高の言語を作ればいい
設計は君の最高のセンスをふんだんに盛り込んで独裁的にやればいいよ
stlのないC++なんてクリープ入れないコーヒーみたいなもん
>>740
C++ の仕様にSTLがないって本当かいな、と思って調べたら
確かに n3337.pdf (C++11のドラフト?) には STL という単語が出てないね。
STLのセンスが良いか悪いか、使うべきか使わざるべきか、
その辺について意見を出せるほど見識はないんで、事実の報告だけ。
『プログラミング言語C++』第4版に「STLなんちゃら」って章が
いくつか載ってるから、仕様の言葉だと思ってたわ。 プログラミング言語C++に後にSTLとなるテンプレートライブラリ作ってストロストラウップに勧めに来た奴が居たので
ストロストラウップが試したら、彼が信条とする「良いライブラリ10箇条に全部あてはまってこりゃｽｹﾞｰとなったという
エピソードがあったような
なかったような
STLは俗称だし、定義も曖昧
皆そう呼ぶのが便利だからSTLという呼び方してるだけ
HPの研究所で働いてたAlex Stepanovが発案して94年あたりに持ち込んだっぽい
ライブラリじゃなくて、いわゆる「汎用コンテナ(データ構造)ライブラリ」についてBjarneが重要と考えたチェックリストのほぼ全部にパスした
c++の仕様にSTLが無くてもrange-based forのようにSTLが備えてるbegin,endに依存した構文は出てる。
STLつってもどうせvectorとmapくらいしか使っとらんだろ。
まあそれで十分なんだが。
STLという言葉を発することがもうほとんどなくないか？
stdは使うけど、まあどっちも輪郭のはっきりしない言葉だ
STLは洗練されている。
素晴らしいデザイン。
コンセプトが入ったらさらに洗練できると思う。
>>742
リソースが制限されてるというより、最大限のパフォーマンス出す場合な
つまりリソースがリッチかどうかは直接関係ない
AAAのpcゲームとかね
パフォーマンスそこそこでいいならc++なんか使う理由がない
遊び以外 最大限のパフォーマンスを出すために作ったeastlみたいなのも標準の使用感踏襲するくらいには標準の設計は良くできているよ
>>767
移行が楽になるようにむやみにapi変えないのはソフトウェアの定石
それより変わったところ、拡張されてるところに注目しようか C++2zには俺の作ったライブラリが標準搭載されると思う。
ATL（adult T-cell leukemia-lymphoma）は語呂が悪い
std::tuppleはPythonフリークが無理矢理ねじ込んだのではないか
C++11で追加された可変長テンプレートなくして有り得なかったコンテナやし
std::pairと被っとる
tupleなんかどの言語にもあるだろ
現代の言語の基本的概念の一つで当然サポートされるべき
>>759
じゃあ、ストロストラウップの物を見る目が無い。
彼自身のセンスが悪いんだ。 なんちゃらラウップは言いにくいからいつも
ビョーーンさん、と呼んでいる
タプルはなにが嫌といって get<0> とかいうのがものすごく嫌
要素が4個ぐらいになったら1年後ぐらいにコード書き直そうとして
・・えっとこの値取りだすの get<1> だっけ？ get<2> だっけ？とか絶対なるから使わない
いい加減enumにメンバ関数定義させろと。
enum classの時にどうにかすべきだった気もするが。
後は静的なリフレクションも
enumと文字列の相互変換とか殆ど定型コードになるのにいちいち書くのが面倒すぎる。
マクロで書くのも微妙だし
>>779
センスがあるか無いか知らんけど、
すっぽすっぽ先生が是とした以上は C++ 的ではあるはずだろ。
それが駄目なら C++ が駄目だし、駄目なので君は使わなくていいよ。 標準コンテナ使わないらしい人の
抜群のセンスを見てみたいので、コードの一部でも見せて欲しいものだな
Eigenが絶妙に不便なんだけど行列演算を標準でサポートする予定ってあるの？
センスが悪いというだけで具体的にどこがどう悪いか、どんなだったらセンスが良いのか言わないと、説得力ゼロだな。
>>784
定型文ならtemplateで書けないの？ >>792
やりたいことは単にenumの値の識別子とその文字列を対応付けるだけなんだが、templateで書けるの？
enum class Color {
Red,
Green,
Blue
};
inline auto to_string(Color c)
{
switch (c){
case Color::Red:return "Red";
...
}
}
こんな感じのことがしたい マクロ Stringizing Operator (#) を使うしかないのでは。
>>789
×センスが悪い
○自分の趣味合わない
だから説明する必要なし嫌い嫌い言っておけばおk
ちょうど114514回目のstd:get嫌い民も現れたところだ ストラウストラップも例外入れるかどうかあたりまでは
かなり真剣に仕様を考えてた印象だけれどそれ以降はタガが外れた感じだ。
最近はもうどうしようもなくなってる。
>>793
その処理ならmapかunordered_map使うのが良くないだろうか？ なお誰もストラウストラップに意見を出せるほどプログラミング言語の勉強をしていないもよう
>>797
逆変換はunordered_mapだな
文字列化の方はswitch使うのが一番コンパイラがいい感じのコードにしてくれる 関数の引数として vector<int> を参照渡ししたいのですが、これのデフォルト引数を空の vector<int> にする方法ってありますか
std::vector<int> &v = std::vector<int>() じゃないのん
>>786
センスうんぬんを言ったのはおれじゃないけど、
標準ライブラリ使わないという主張に対して、ソースがエレガントかどうかを問うのは目的がわかってない
端的にいうと標準ライブラリのオーバーヘッドが許容できないんだよ
多少記述が汚くなろうがパフォーマンス引き出すのが優先
cとc++のベンチだと結局cの方がいいスコアになってること多いだろ
(全てがそうでないのは知ってる)
そこをcと同等まで引き上げるわけだ だったらC使ってれば
それ以外の選択肢無いんだから
>>806
そこはアセンブラ使えばというところだろ >>804
VC2017だとconstじゃなくてもいけた
てか参照のデフォルト引数ってconst限定だったのか
仕様変わったのかVCだけおかしいのか知らんけど いうまでもなく、ボトルネックでないところは労力はかけない
メンテが楽な手法を使う
それに完全にゼロコストなものは普通に使うさ
標準コンテナでcより遅くなるってどんなパターン？
単方向listで十分なのにlistだと双方向とかそんなやつ？
あんまりlist使わんからよくわからんが
vectorは使い方を余程間違えない限り大抵代替品より速いような
メモリ確保回りはallocator使えばいいし
data使えばただのメモリブロックだよね
>>810
要素の追加時に容量の拡張が必要かどうかのチェックが入ったりするから、オーバーヘッドはゼロではないよ >>812
それpush_back or emplace_back使っているのが悪いのでは
cの同等コード書いてもチェックは必要だろ
チェック要らんことが分かっているならresizeしておけ >>813
便利なものがあれば人間は使ってしまうもんだ
その積み重ねがパフォーマンスの差に繋がる
俺は一般には便利なものを使って時間を節約することでボトルネック解消にかける時間を確保でき、
結果的にパフォーマンスはより高くなると思うけど、そこはスケジュールの制約次第だな Cマスター「C++は配列に追加するときにサイズチェックするから遅い(ｷﾘｯ」
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
こんな雑魚がでかい顔してるからいつまでもセキュリティホールがなくならないんすなあ
Cマスター「要素追加時にサイズチェックするという便利さの積み重ねがパフォーマンスを落とす(ｷﾘｯｷﾘｯ」
やべえ笑い死にしそう
笑い事じゃないけど
プロファイラで調べて本当に問題あるならどうにかするけど
ただわざわざc的に書いても大抵誤差レベルでしか変わらんよね
どちらかと言うとバッファの確保の仕方を工夫した方が効果が大きい
>>810
・以下、要素数が N とする。
・C/C++ の原定義の固定長配列は、要素の代入に1クロックしかかからない。もちろん、
O(1)で、物凄く速い。なお、固定長なので「代入」であり「追加」ではない。
・Listはリストだから1個の要素の追加はO(1)で、要素数に依存せず安定した速度が出るが、
内部で、newされるはずなので、最低でも170クロックほどかかってしまう。
・Vectorは動的配列だから、最悪のケースでは要素の追加にO(N)の時間がかかり固定長配列より遅くなる
と思う（よく知らない）。 >>817
複数の要素を追加するとき、わざわざ事前にまとめてリサイズするか？ということだよ
1要素ずつ処理するのは生ポならかえって面倒になることが多いし、見た目にいかにも非効率そうなコードに見えるから、大抵の人は自然にそうするだろう
一方vectorだとどうだろうね
心理的な問題なの 同じようなことはvectorに限らず一般的に言ええて、
例えばC++はRTTIの便利さ故にCと比較してプログラマが無駄なメモリの確保や破棄を行いやすい傾向がある
逆にCだと無駄に大きなバッファ作りがちだったり、バッファの使いまわしによりスレッドセーフでないコードを書きがちであったりする
VC++2017なんだけど
デストラクタで投げた例外をキャッチできずabortするのはVC++の仕様？
RAIIとラムダを駆使した自作finally内で
例外投げたらキャッチできずabortしてハマったわ
デストラクタ内で例外投げるのが汚いのは知ってたが
そうか、自作finallyもデストラクタ利用してるからダメなのかな
サンクス
デストラクタをnoexcept(false)指定したらcatch出来たわ
てことは自作finallyは念のためnoexcept(false)指定にしたほうが良いのか
それか自作finally内で例外投げるのは完全禁止にするか
悩むわ
まぁでもよく考えたら
例外が発生して自作finallyが実行されてる時に
さらに自作finally内で例外飛ばしたら二重例外になるから危険か
なるほどなるのど
>>820
意味がわからん
そもそもCでも固定長配列の代入は実データのコピーを伴いO(n)だ
アドレスや参照のやり取りならO(1) あーそう言うことか
固定長的に使いたいなら始めにresizeするだけじゃない
便利だからチーム内で使ってしまう人がいることを問題にするより、使わずにいちいち独自コードで処理されて余計遅くなったり、バグ仕込まれたりする方が余程ヤバイだろ
先生、配列の長さにリミットを設ける方法を教えてください
まぁそれでも範囲チェックは入るし、常にヒープ使われるし
それすら問題になるようなクリティカルな場所なら生配列なりarray使えばいいと思うけど
適材適所じゃないかねぇ
>>836は>>834宛
まぁ要素数わかってて末尾に入れてくのはナンセンスやね
速度を気にしない場所ならどうでもいいけど よくあの時代にこのような洗練されたライブラリを設計できたものだと思います。
もしかすると宇宙人にもらったのかも。
配列の長さチェックのオーバーヘッドとかなんかものすごくデジャブ感のある議論だな。
肯定、否定どちらにしてもマウンティングかましたくなる題材なんかね。
標準コンテナで問題になるのはやっぱりヒープだよ
境界チェックとか仮に無断だとしても一定時間で終わる処理
ヒープ使われると最悪システムコールで負荷変動大きすぎる
ちなみにアロケータは要素数で管理できないから面倒
あとvectorで最初にreserveしても最大長越えないチェックが必要で面倒
でこれらを解決するコンテナがboostにあるのでそれを使う
あと標準ライブラリのリンクリストはそもそもの設計が非効率
(クリーンな設計ではあるが)
素朴なcの実装と比べてかなり差がでる
これも代替がboostにある
>>835
末尾追加の話なら、Cでも同じだけコストかかるだろ。
>>840
arrayならstackに積まれる。 >>820
なんか変じゃないですか？
list や vector のときは要素の「追加」なのに、生配列だけ要素の「代入」と設定するのですか？
list や vector で要素の「追加」を考察するのなら、生配列の場合も要素の「追加」を検討してください >>842
arrayは固定長
欲しいのは最大長を事前に確定しつつ、その範囲で可変長で使えるvector
という話ね ここのCマスター様は、現在の配列長と挿入インデックスのチェックしてreallocしてなんていう
パフォーマンスの悪い便利さに甘えた処理などしない
堂々とv[N]に無条件代入を行って超高速O(1)追加を実現するのだ
事前のresizeかreserveでええんとちゃう？
一般的には無いよ
局所的な話を持ち出してああだこうだ言ってるのが今
そして何をするつもりかは誰も知らん
>>829
要素数がN、データの大きさは4バイト、と仮定した場合の話。 >>843
4バイト整数のN要素の配列を仮定しているが、Cの単純な固定長配列だと
4バイト整数はコピーするのが当然。
ところが、Listだと、「追加」するしかない。動的配列である
Vectorも、基本的には「追加」が基本。そうでなければ「動的」と言わない。 vector.data()、basic_string.c_str()はCと同じの配列の連続アドレスを保証する数少ないインターフェースでしょ。
正直stringがゼロ終端を保証したのはちょっとどうかなと思ってる
いや便利なんだけどさ・・
アドレスと一緒にバッファサイズを渡せないAPIが世の中に無数にある。ヌル終端は優しさ。
>>851
なぜかC言語は固定配列でC++だと動的が基本らしい
前提違うのに速度ガーとか言われてもなぁw >>855
ヌル文字をデータとして扱えない、という決定的なウィークポイントが発生しますね…
昔、ツールがヌル文字を扱えない、という点が後から発覚してとても困った経験があります >>851
ようゴCマスター様
マスター様は知らなくてビックリするけど、C++ではvectorやlistは要素数が実行時に決まるときに使うんだ
そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
reallocっていうらしいんだけどさ
使うときは確保済みのバッファの長さをいちいち調べて、足りなかったら再確保して必要に応じて要素を全部コピーするらしいっすよ
もちろんそんな馬鹿げたオーバーヘッドを払う奴はC++かぶれのド素人だけだけどな
真のCプログラマは一度確保した配列の自由なインデックスにコピーすることでvectorの無意味なオーバーヘッドを回避し超高速O(1)を実現するのだ なんかツッコもうと思ったら既に>>813に書いてあった >>857
C++の配列は固定長が基本。
STLやboostは、C++とは異なる。 >>859
>そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
>reallocっていうらしいんだけどさ
Cでは、realloc は推奨されて無い。
Cで、要素数が実行時に決まるような集合を扱いたい場合は、自前で
ポインタでリンクする、リンクリストを使う。
毎回それをやると間違いやすいので、賢い人は、自前でリストライブラリを作って
それを用いて操作する。 Linuxのソースなんだけど
close(0) close(1) close(2)って書いてあるの見つけたのだが
これってなんの効果が期待できるの？
ファイルディスクリプタ？だと思っていてオープン等をした値番号だと思ってたけど、0 1 2に該当するのがなんなのかと
iteratorでstartとendの中に納まってることが保証されてるのに
各要素にアクセスするときにまた範囲チェックとかあると無駄やん
そりゃ書こうと思えばいくらでも危険なコードは書けるけど
安全なときはそういうの省いて高速化出来るのがCの良いところなのに
(レジスタの値が知らない間に壊れても正常に動くようにとか言ってるなら知らん)
>>861
固定とか決めつけてるのを別にしても何を言いたいのかさっぱりわからん >>862
で、そのオレオレ車輪の再発明クソライブラリは
std::vectorやstd::listより何が優れてるの？
範囲チェックしないから高速wなの？ 差異があるとすれば、deep copyだね
決めつけ良くない
>>862
ランタイムでサイズが決まる動的配列にリンクリスト使うのはさすがにダメすぎる >>869
そもそも、C で出来ないことは、コンピュータのアーキテクチャ上、ほぼ
絶対に出来ない事。
だから、Vectorが、効率面でCを上回ることは絶対に有り得ない。 >>869,871
ソートはどうなの？ （・∀・）ﾆﾔﾆﾔ 義務教育でプログラミングとか教えたら
もっと変なの増えそう
python界隈に来ないで欲しい
>>874
こういう金融とかの兵隊養成用だから競合はしないと思う
化石じゃないまだドメイン次第で現役Fortranだってこの間新しい仕様出たし！ってつっかかられるぞ
08をちゃんと実装したコンパイラ出してから言ってくれよって気持ちだが
_____(コボル)
答え COBOL
_____(フォートラン)
答え FORTRAN
これのどこが問題集やねん！
>>880
その言葉を見る限り、あなたは日本人じゃない気がする。
この文脈で、あなたが言いたかったのは、
「来年度からこれが流通するぞ」ではなく
「来年度からこれが常態化するぞ」
という事だったと思うから。 >>871
それ言い出すなら逆もまたしかりだろ
extern "C"すればCで出来てC++に出来ないことはないぞ。 だいたいC++にはasmがあるしな
アセンブラで出来ることは出来るんじゃね
>>881
おまえらが役人からずれてるんだろ。
日本は公務員のための国やぞ。 でも、ターゲットにRubyとC++を選択したのは正解だと思ってるよ。
日本政府は日本人と将来の日本の年金などのための政治を行えばいいのだから、
日本人が作ったものを使うように推進するのは悪いことではない。
余りにも使いにくいもので無い限りは。
だからWordをやめて一太郎を使うようにしたり、Rubyを使うようにしたり
するとすれば、それは英断だよ。
RubyはWindowsでまともに動かないから、Linux採用するのかな。
>>892
自分の環境では、Windowsで普通に動いてると思ってるけど。 教えるなら実用性と手軽さからしてC++、Javascript、python
>>883
えっ配列初期化子がC++でも使えるように？ >>891
国産のを応援するのは判るが
それが利権になってただのクズが集まって来たり
金貰うと進歩が止まったりするのが日本の悪いところ 国産であっても良いものでなければ応援するべきではない
Rubyは滅ぶべき言語トップ10に入る
>>896
書き方同じじゃなくても同様の事が出来るだろ
cで出来ないこと無いって話にたいしてなのだから PythonとRubyだったら、Rubyもそんなに悪くは無いと思う。
Pythonは可読性が悪いように感じる。空白インデントだけでブロックや
関数の終わりを決めてしまうので、内部関数が終わってるかどうか分からず、
人の書いたソースが読みにくくて困ったことがある。
C++er的には
動的型の時点でノーサンキューだろ
そういうのが嫌でC++使ってるんじゃないのか
特にRubyは教祖様が
絶対に型は書きたくない
って駄々こねてるから
これはもう日本のガラパゴス化が一層激しくなるな
pyは読みより書きの方が問題
間違えてインデントけずっても気づかないことが多い
>>901
個人的には型のある言語の方が好きだ。
型があった方が、変な問題にはまる率が下がるので開発が速く進む。
大規模開発には絶対、型が必要。
初心者にも大人気言語だった元祖のBASICも、Aが浮動小数点型、A$が文字列型で、
確か、A% が整数型。配列は DIM A(100) や、DIM B%(10,10) などで、
宣言は省略できる場合が多いが、ちゃんと型はあった。
Rubyなどは、A にあらゆる型が入れられるので、関数呼び出しなどが
かなり怖い。間違っていても問題の切り分けが出来ないので「はまったら」大変。
だから、とても慎重にコードを目で見ないといけなくなる。 >>903
Pythonで、良く分からなかったのが、インデントの空白の個数。
2個でも4個でも好きな量を選べるのだろうか？ >>906
やはりそうだったんだ。だから余計に解読できなかったんだな。
エディタでカラムを数えたり、上まで戻ったりして、やっと認識していた。
でも不安が残った。ブロックが終わってるのかどうか物凄く分かりにくい。 今のPythonはカオスだからな
見易い文法目指していたはずが
内包表記やらラムダやら見づらくする文法が増えて推奨までされている
フレーム作るか否かもわかりづらいことこの上ない
>>851
「実装A, B, C があり、機能 f について、A.f, B.f C.f のそれぞれに、こんなメリデメがあります！」
なら理解できますが、>>820 は、
「A.g, B.f, C.f のそれぞれにこんなメリデメがあります！」
でしょう？それって変じゃないですか？
A.g とかじゃなくて、A.f で比べて欲しいのですが？ >>908
最近の言語全般に言えることだな。
無駄機能入れすぎなんだよ。
クソみたいなシンタックス入れるくらいならライブラリを充実させるほうが正しい。 メリデメっていうやつw
すまんがめっちゃ底辺臭する
>>882
お前さんの言い換えた方の日本語もかなり不自然だよ。他人の言葉尻をとらえてどうこう言えるほど、お前さんも日本語が得意な訳ではないだろう。
そもそも、普通の人はそんなことで日本人かどうか気にしたりしない。 >>858
文字列の途中に格納することは新仕様でもできるでしょ？ double型の変数a、bがあるとして、
a/bが整数かどうか判定するには
標準のコンテナなんて使う理由ある？
遅くて使い物にならん
ストリームなんて実用に耐えれないくらい遅いだろ
ではa/bに最も近い整数はどうやったら出せますのん？
両方の案を採ってC++14ではstd::floor(a / b + 0.5)にｹﾃｰｲ？
C99なら丸め関数あるけど…
>>918
それは自分に問いかける言葉だったんじゃ。 >>930
>>918についてはまだ誰も判定精度のベストを尽くしていない件について：
多分
std::abs((a/b) - ((a/b)の小数以下を丸めた値)) <= std::numeric_limits<double>::min()
あたりがベスト？ 一太郎は自滅したからなぁ
どうしているのかと思えば名簿の話であんなことしていたのかと・・・
上手くやればいくらでも出来たのに勿体無い
>>931
いやこの場合はイプシロンじゃなくバイナリ一致で比較すべき まだ428万なのに一勝で400くらいしか上がらなくなったんだけど中堅名乗ってええか？
lisp は大昔 emacs のカスタマイズするのにしょっちゅう書いてたけど
なんでこんなクソみたいな古代言語を有り難がるやつがいるのかいつも謎だった
普通に C 風の文法のスクリプトでも搭載してくれたほうがよっぽどありがたい
>>939
Emacs Lisp は今でも生き残っている LISP 系の言語の中ではクソな方なので、それで判断されてもな……。
AutoLISP よりはマシだが。 どうしてC言語風のスクリプト言語が無いんだ
どいつもこいつも分かりにくいうえにデバッガも無いもん作りやがって
941
あったけど流行らなかった
pythonの方が役にたつ
>>916
int型にしてdouble型に戻したのと比較するとか、floor関数使ったのと比較する。 >>931
min()以下の非正規化数でも残差があればそれは整数じゃないんだから単純に0との比較でいい。 小数なんかいらん
ビッグインテジャークラスを標準でほしい
>>945
あるけど誰も採用してない
何故かみんなオリジナルの言語を作り始める
相当慣れないとautotoolsとか解読困難だし
なんならこれもperlにすればよかったのに
おかげで出回ってるものもコピペを繰り返した秘伝のタレ状態だわ オリジナル言語といいつつ、
昔からあるautotoolsを持ち出すとか
>>940
では common lisp 準拠の xyzzy を推奨いたしましょう >>957
正直言って、 xyzzy とか lem の方が筋がいいわ。
この時代にダイナミックスコープとか正気の沙汰ではない。
(近頃の Emacs Lisp はレキシカルスコープにも出来るけど。) emacsではdynamicもそれはそれで便利なんだが
エディタだから各関数がコンテキストによって挙動変えるけど、それを引数として渡す訳じゃないからね
dynamicのスタック的な状態変更は便利
lispってまとめられがちだけれど言語としてのくくりで言えばalgol系くらいの意味合いしかない。
schemeとcommon lispだったらc#とjavaのがよっぽど近い。
template<class B,class D>
class B : public D{
//...
};
ってなにがしたいんだろ
>>961
ほんまそれ。
そんでもって現代で LISP って言ったら Common Lisp か Clojure あたりを想定して欲しいって思う。
(俺は Scheme 派だが) まあFORTHとPostScriptの違いくらいかな
>>967
相談じゃないんだろ。スレ違いだから巣に帰れ。 相談スレじゃねえだろ
ひけらかしスレだから合ってるだろ
>>967
ところで以前のウェブサイト (NWSA だとか文字コードだとか平衡木の文書があったやつ) は完全に消えたの？
ブログは残ってるみたいだけど、最終更新はだいぶん前だし。 uint64同士の掛け算でオーバーフローしていないことを確認するには
(long double) a * b <= UINT64_MAX
であってますか？
> (long double) a * b <= UINT64_MAX
変形してこれでいいのでは？
a <= UINT64_MAX / b; // b!=0
>>973
その手がありましたか
ありがとうございます CPUのオーバーフローフラグを見る標準の手段が未だにないのが不満です
mul_highみたいなの位標準化してくれればいいのにね
大抵のアーキテクチャでは命令として存在するのだし
>>971
ああ、あれはやめた。
維持費がかかっていたので。 >>978
コンテンツは面白いので、データが残ってたら Github かどっかに置いてくんない？ >>979
気持ちに添えなくてすまないが、残念ながら、今は公開する予定はない。
>>980
そんなに気にする人がいるとは思ってなかったんだけど、今後は晒さない。 984デフォルトの名無しさん2019/03/31(日) 19:00:54.99
>>954
覇権争いのおこぼれかな。
一応貰っておいた コンストラクタにアウトプット変数をつけるのって邪道ですか？
set<int> を0からnまでの連番でお手軽に初期化する方法ってありますか？
for文でinsertしまくるのが普通ですか？
C++11なら
std::set<int> = {1, 2, 3};
と書ける。
array<int,3>={1,1,1};
初期化子より要素が３ケなのはわかるのに
なんで一々３って記述しなきゃいけないの？
>>985
別につけてもいいけどメソッドとかで返した方が使いやすくね？ onCreateをbindしたいのですが、これはどうすればコンパイル通りますかね…
template<class T>
void test(T&& value){
auto onCreate = std::bind(std::fowrawd<T>(value)->onCreate,std::forward<T>(value),std::placeholders::_1);
}
梅
万葉集巻五 梅花の歌三十二首、并せて序
「初春令月、氣淑風和、梅披鏡前之粉、蘭薫珮後之香」
初春の令月にして氣淑(よ)く風和ぎ梅は鏡前の粉を披き、蘭は珮後(はいご)の香を薫す
>>997
私は解を見つけだが、それを示すにはあまりにも
余白が少なすぎる mmp
lud20190619103341ca
このスレへの固定リンク： http://5chb.net/r/tech/1550772463/ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part141 ->画像>9枚 」を見た人も見ています：
・C++相談室 part152
・C++相談室 part149
・C++相談室 part126
・C++相談室 part155
・C++相談室 part154
・C++相談室 part153
・C++相談室 part150
・C++相談室 part148
・C++相談室 part151
・C++相談室 part137
・C++相談室 part143
・C++相談室 part138
・C++相談室 part157
・C++相談室 part166
・C++相談室 part165
・C++相談室 part164
・C++相談室 part156
・C++相談室 part158
・C++相談室 part163
・C++相談室 part161
・C++相談室 part124
・C++相談室 part159
・C++相談室 part162
・C++相談室 part142
・C++相談室 part133
・C++相談室 part144
・C++相談室 part117
・C++相談室 part135
・C++相談室 part147
・C++相談室 part146
・C++相談室 part140
・C++相談室 part139
・C++相談室 part132
・C++相談室 part137
・C++相談室 part145
・C++相談室 part134
・C++相談室 part130
・C++相談室 part136
・C++相談室 part131
・C++Builder相談室 Part21
・0からの、超初心者C++相談室
・Cygwin + MinGW + GCC 相談室 Part 8
・Cygwin + MinGW + GCC 相談室 Part 3
・C++相談室 part123 [無断転載禁止]©2ch.net
・C++相談室 part129 [無断転載禁止]©2ch.net
・C♯相談室 Part20
・C言語相談室(上級者専用）
・MFC相談室 mfc22d.dll
・Mac G5 中古買入相談室
・C#, C♯, C＃相談室 Part75
・C#, C♯, C＃相談室 Part79
・自営業 悩みごと相談室 40
・C#, C♯, C＃相談室 Part78
・自営業 悩みごと相談室 46
・MFC相談室 mfc23d.dll
・0からの、超初心者C#相談室
・C#, C♯, C＃相談室 Part94
15:34:36 up 65 days, 16:33, 0 users, load average: 10.60, 10.40, 10.27
in 0.037399053573608 sec
@0.037399053573608@0b7 on 062204
|
