C++相談室 part158

**デフォルトの名無しさん** · 2021/11/15(月) 18:49:18.44

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

**デフォルトの名無しさん** · 2022/01/31(月) 20:55:29.83

>>753
auto Sum = [](auto head, auto... rests) { return (head + ... + rests); };

**デフォルトの名無しさん** · 2022/01/31(月) 22:50:37.06

ラッパークラスを通せば似たようなことはできそう。

struct Wrapper_ {
constexpr static auto doit = [](auto... args) { return Sum(args...); };
} wrapper;

int main( int, char ** )
{
std::cout << foo(wrapper.doit,1,2,3) << "\n";
}

**デフォルトの名無しさん** · 2022/02/01(火) 04:38:50.89

クラスは不要だった。
ラムダなら通るみたいだから、 >>758 みたいに元の関数をラムダで書くか、

auto wrapper = [](auto... args) { return Sum(args...); };

みたいなラッパー関数オブジェクト通すかってあたりで足りそう。

// 最初実験してたとき、ラムダ式にしただけだとエラー出てた気がしたんだけど、今やると問題なく通る…

**デフォルトの名無しさん** · 2022/02/01(火) 05:38:09.33

おお、auto... なんてできたのか

**デフォルトの名無しさん** · 2022/02/01(火) 07:53:40.48

>>757にラムダ入れた。
ラムダはオーバーロードできずC++17の畳み込み式が必須で引数なしが表現できないが、選択の手間がない。
#include <iostream>
auto sum() {return 0;}
template<typename Head> auto sum(Head head) {return head;}
template<typename Head, typename... Tails> auto sum(Head head, Tails ...tails) {return head + sum(tails...);}
template<typename Return, typename... Args> Return wrap(Return (*f)(Args...), Args ...args) {return f(args...);}
auto lambda_sum = [](auto head, auto ...tails) {return (head + ... + tails);}; // 追加
auto lambda_wrap = [](auto f, auto ...args) {return f(args...);}; // 追加
int main( int argc, char *argv[] ) {
std::cout << sum() << std::endl; // 追加
std::cout << sum(1) << std::endl; // 追加
std::cout << sum(1,2.1) << std::endl;
std::cout << wrap(static_cast<double(*)(int,double)>(sum), 1,2.1) << std::endl;
std::cout << wrap(sum<int,double>, 1,2.1) << std::endl;
// std::cout << wrap(sum, 1,2.1) << std::endl; // エラー
// lambda版追加
// std::cout << lambda_sum() << std::endl; // エラー
std::cout << lambda_sum(1) << std::endl; // 追加
std::cout << lambda_sum(1,2.1) << std::endl;
std::cout << lambda_wrap(static_cast<double(*)(int,double)>(sum), 1,2.1) << std::endl;
std::cout << lambda_wrap(static_cast<double(*)(int,double)>(lambda_sum), 1,2.1) << std::endl;
std::cout << lambda_wrap(sum<int,double>, 1,2.1) << std::endl;
// std::cout << lambda_wrap(lambda_sum<int,double>, 1,2.1) << std::endl; // not template
// std::cout << lambda_wrap(sum, 1,2.1) << std::endl; // エラー
std::cout << lambda_wrap(lambda_sum, 1,2.1) << std::endl;
return 0;
}

**デフォルトの名無しさん** · 2022/02/01(火) 22:23:26.64

c++では
ｓｚ=120;
char ｄｔ[sz];
このように配列のサイズを変数の可変サイズで指定することはできないんですか？
これを実現する方法は何かありませんか？

**デフォルトの名無しさん** · 2022/02/01(火) 22:43:02.67

自己解決しました
しかし dt[10][d] のように2次元以上はｊａｖａのような動的変動はできないんですね

**デフォルトの名無しさん** · 2022/02/01(火) 23:27:31.22

vector使わんの？

**デフォルトの名無しさん** · 2022/02/01(火) 23:28:28.99

配列使わんし

**デフォルトの名無しさん** · 2022/02/01(火) 23:30:45.06

>>763
arrayという似たようなやつはあるが
基本的に作法が違う

**デフォルトの名無しさん** · 2022/02/02(水) 10:03:42.12

コンストラクタ・テンプレートでテンプレート実引数を推定させず明示的に与えるのはどう書く？

struct some_class
{
template <class A> some_class(int) {}
};

int main()
{
some_class obj<void>(1); //error
}

**デフォルトの名無しさん** · 2022/02/02(水) 12:11:02.47

>>768
コンストラクタには明示的に型引数を渡せない

**デフォルトの名無しさん** · 2022/02/02(水) 12:36:54.65

そっか。。。残念
thx >>769

**デフォルトの名無しさん** · 2022/02/02(水) 12:56:51.10

ファイルサイズを取得しようとしていろいろサイトを参考にして次のようにしたのですが
std::filesystem::file_size(path)
filesystemのところに赤線が出て使用できません
これらは記述しています
#include <iostream>
#include <fstream>
#include <filesystem>
使っているのはCommunity 2019です
filesystemが使えないのはなぜでしょう？

**デフォルトの名無しさん** · 2022/02/02(水) 13:02:34.63

>>771
filesystemが使えるのはC++17以降

プロジェクトの設定から言語バージョンをC++14(既定)->C++17に

**デフォルトの名無しさん** · 2022/02/02(水) 13:34:32.24

>>771
/std:c++17は指定してる？

**デフォルトの名無しさん** · 2022/02/02(水) 13:43:30.57

ありがとうございます　C++17指定できました

**デフォルトの名無しさん** · 2022/02/03(木) 12:49:10.84

filesystemは、できればC++20モードで使いたい
file_clockまわりがC++17ではｇｄｇｄだから

**デフォルトの名無しさん** · 2022/02/04(金) 13:06:35.94

小文字に変換するプログラムです
string toLowerCase(const string& str)
{
string lower = str;
std::transform(lower.begin(), lower.end(), lower.begin(), std::tolower);
return lower;
}
実行するとstd::transform 一致するオーバーロードする関数が見つかりません、とか
6引数が必要です 4が設定されてます、とか出て
実行できません
これは何が問題なのでしょうか？

**デフォルトの名無しさん** · 2022/02/04(金) 13:07:58.25

tolowerが多重定義関数だからじゃね？

**デフォルトの名無しさん** · 2022/02/04(金) 13:22:13.60

自分では他に定義してないんですがどこで定義されてるんでしょう

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/04(金) 13:28:07.50

>>776
ちょうど >>658 で同じような事例が出ている。
std::tolower は cctype ヘッダと locale ヘッダにそれぞれあって
locale ヘッダのほうが関数テンプレートだし二引数なのでこの場の都合に合わない。
なんらかの方法でどれを使うのか選択する必要があり、
たとえば static_cast などが使える。
ただ、 >>661 が提示しているようにデフォルト引数が追加される可能性があったりもするので
static_cast よりはラムダ式を経由するほうが安心できるスタイルかもね。

#include <iostream>
#include <string>
#include <algorithm>
#include <cctype>

std::string toLowerCase(const std::string& str)
{
std::string lower;
std::transform(std::begin(str), std::end(str), std::back_inserter(lower), static_cast<int(*)(int)>(std::tolower));
return lower;
}

int main(void) {
std::cout << toLowerCase("abcDEfgHi") << std::endl;
}

**デフォルトの名無しさん** · 2022/02/04(金) 13:35:40.02

ありがとうございます　ビルド通ったみたいです

**デフォルトの名無しさん** · 2022/02/04(金) 13:55:24.36

最近のはptr_funやんなくても通んだな

**デフォルトの名無しさん** · 2022/02/05(土) 11:50:25.88

template<yyy T>//yyyはコンセプト
requires !xxx<T>//xxxはコンセプト
void test(const T& a);//yyyのコンセプトを満たしxxxのコンセプトを満たさないものについて処理したい

C++20のコンセプトのrequires節って!使うと警告出るのでわざわざ否定用のコンセプト作成して対応してるんだけど、もっと簡単な仕組みない？

**デフォルトの名無しさん** · 2022/02/05(土) 11:52:48.48

requires (!xxx<T>)

**デフォルトの名無しさん** · 2022/02/05(土) 12:04:00.17

解決した！ありがとう！

**デフォルトの名無しさん** · 2022/02/05(土) 20:23:31.04

#define FOO() 1

#if FOO
...
#endif

と書いた場合FOOの後ろに()付けるの忘れてるのでコンパイルエラーになって欲しいんですが
実際はFOOは偽に評価されてるみたいです
何が起きてるんでしょうか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/05(土) 20:31:08.99

>>785
#if の条件の部分ではマクロ展開できるものを全部展開したあとに知らない識別子が残ったら 0 と解釈する。

**デフォルトの名無しさん** · 2022/02/05(土) 20:32:57.42

>>785
FOO に () が無いことで展開されず、マクロ展開後に残った識別子として 0 に置き換わってる。
https://timsong-cpp.github.io/cppwp/n4868/cpp.cond#11.sentence-1
> After all replacements ..., all remaining identifiers and keywords,
> except for true and false, are replaced with the pp-number 0, ...

**デフォルトの名無しさん** · 2022/02/06(日) 01:29:50.60

>>785
バカですか？

**デフォルトの名無しさん** · 2022/02/06(日) 01:32:54.82

#if defined(FOO)
...
#endif

**デフォルトの名無しさん** · 2022/02/06(日) 01:34:05.59

Cの基本が出来てないくせにC++を使いこなせると思うなよ

**デフォルトの名無しさん** · 2022/02/06(日) 01:35:00.88

横からだけど知らなかった

**デフォルトの名無しさん** · 2022/02/06(日) 03:28:00.08

>>786
>>787
ありがとうございます
このルールは知りませんでした

**デフォルトの名無しさん** · 2022/02/06(日) 06:46:34.29

こういう馬鹿のためにコンパイラに無駄なルールが必要になるんだなと実感

**デフォルトの名無しさん** · 2022/02/06(日) 06:55:06.64

エラーにならないのは理不尽だな

**デフォルトの名無しさん** · 2022/02/06(日) 08:23:12.41

馬鹿のためにわざわざプリプロセスで構文解析エラーを要求するとか馬鹿の極み

**デフォルトの名無しさん** · 2022/02/06(日) 08:30:29.95

FOOが0になる根拠を与えていないだろ
関連付けられていないものが出てくるのがおかしいと思わないとしたらPG適性低いぞ

**デフォルトの名無しさん** · 2022/02/06(日) 08:53:46.75

唐突に0がどうとか言い出すのはセンス無いわ

**デフォルトの名無しさん** · 2022/02/06(日) 09:07:44.45

初めて知った

**デフォルトの名無しさん** · 2022/02/06(日) 09:24:54.74

>>797
>>786

**デフォルトの名無しさん** · 2022/02/06(日) 09:35:58.81

馬鹿は当たり前のように英語も読めない

**デフォルトの名無しさん** · 2022/02/06(日) 09:36:22.76

なんじゃそりゃ>>799はC++規格委員会が死ね言うたら死ぬんか、

**デフォルトの名無しさん** · 2022/02/06(日) 09:57:50.12

規格書にはなんでそうなっているのか（置換されずに残ったFOOをエラーではなく0にするのか）の理由が書かれていないが
#ifdef defined(FOO) && FOO
として現れる論理式「defined(FOO) && FOO」の解釈を簡単にやりたい（FOOが未定義の場合でも通常の式の解釈ルーチンで処理したい
的なしょーもない理由だったりして……

**デフォルトの名無しさん** · 2022/02/06(日) 09:59:13.49

まつがえたorz
×： #ifdef defined(FOO) && FOO
○： #if defined(FOO) && FOO

**デフォルトの名無しさん** · 2022/02/06(日) 10:11:26.46

>>801
唐突じゃないことを示したまで
事実関係をよく確認してからセンス無いとかドヤれってこと

**デフォルトの名無しさん** · 2022/02/06(日) 10:16:43.48

理由はたぶん、規格化以前に存在した実装の動作を規格違反とするのはマズいとか、
その動作に依存して #if FOO としてる既存ソースをエラーとするわけにはいかなかったとか、
そんなところだろうと思う。

マズい動作として検出したければ警告は出せるんだし。

**デフォルトの名無しさん** · 2022/02/06(日) 11:57:03.48

馬鹿がまだ騒いでるのかｗ
こういう変なコードとの対比ｗ
$ g++ -x c++ - <<EOF
auto f = [](){return 2;};
#define f() 1
int main() {
auto i = f();
auto j = f;
return i + j();
}
EOF
$ ./a.out
$ echo $?
3
$

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 12:12:45.00

残った識別子を 0 に解釈する挙動は C89 からの仕様だから C89 の Rationale (根拠) を見たんだけど直接的な言及は見つからない。
https://docs.google.com/viewer?a=v&;pid=explorer&chrome=true&srcid=0BxVCLS4f8Sg5NWZmM2NjZWEtYmExMS00Y2EzLWE3ZTMtNzFmYjYwYzBiOTIw&hl=en_US
ただ、既存のコードに差し障りがないようにということは明記してある (3.8.3) ので、
その時点でそういう挙動が支配的 (かつそれに依存するコードが多かった) のだろうとは察せられる。

規格ってのは統一を図るってのが第一の目的だけど無理な仕様でまとめちゃうと誰もその規格に従わないだけなんで、
現実にそれでやっているってのも (たとえ不格好でも) 十分な理由になるんだよ。

**デフォルトの名無しさん** · 2022/02/06(日) 12:26:28.98

そう書かれるとC89っぽく書かないといかんのか？ｗ
変更部分のみｗ
$ gcc -x c -std=c89 - <<EOF
int f(void){return 2;}
#define f() 1
int main(void) {
int i;
int (*j)();
i = f();
j = &f;
return i + (*j)();
}
EOF

**デフォルトの名無しさん** · 2022/02/06(日) 12:53:10.29

CとC++の規格は既存コードへの忖度の塊で出来てるからな
万人の敵だったgets()を削除するのにどんだけ苦労してるのやら

**デフォルトの名無しさん** · 2022/02/06(日) 13:16:26.39

>>806>>808
スレに乗っかったつもりにしては
#if f
～
#endif
というのが含まれて無いようだが？

**デフォルトの名無しさん** · 2022/02/06(日) 13:22:45.35

>>807
C++規格委員会は無罪なのかもしれんがじゃあなんでC89以前からそうで
そういう挙動が支配的になってしまう事態になってしまったのか、と考えると
やっぱプリプロセッサの最初の設計者がサボって
プリプロセッサ式の途中でのFOOの定義/未定義判定を
define(FOO)を導入する代わりに仕様の方を弄って簡単ハックしてしまったから
のでは……

**デフォルトの名無しさん** · 2022/02/06(日) 13:33:49.71

コードを示しても馬鹿には伝わらない悲しみｗ

**デフォルトの名無しさん** · 2022/02/06(日) 13:37:12.22

>>812
天才にもわかるようにkwsk

**デフォルトの名無しさん** · 2022/02/06(日) 13:39:17.55

天才は自力でなんとか出来るし、他人を信用しないことも多いから、基本的に質問とかする機会がない
アイデアレベルの話のみ

**デフォルトの名無しさん** · 2022/02/06(日) 14:11:31.07

(σﾟωﾟ)σｹﾞｯﾂ
stdioのバッファ使うヤツ殆ど失敗作

**デフォルトの名無しさん** · 2022/02/06(日) 14:22:31.03

#define マクロは単純置換のやつと関数形式のやつがある

#define A(a,b)
A();A(1);A(1,2,3);A(1,);A(,2);A;

結構めちゃくちゃなことやってもプリプロセスはエラー吐かない

引数足りないとか関数形式マクロの括弧がないのは意図しない使い方だろうからエラーにしてもらいたい気持ちはわかるが

というか<<802で言及されてるけど#if UNDEFINEDも非推奨にしてほしいわ
#define DEBUG
#define DEBUG 1
#define DEBUG 0
//#define DEBUG (undefined)
これらの全部のケースに対応できてねーし
#if DEBUG+0 とか書けとでも？

**デフォルトの名無しさん** · 2022/02/06(日) 15:06:24.27

俺のコードのg++やgccをcppに変えればプリプロセスの結果が出るよｗオプション引数に-Eを付けても可ｗ
別に不思議でも何でもない結果が表示されるｗ
$ cpp -x c++ - <<EOF
#define A(a,b) expanded
A();
A(1);
A(1,2,3);
A(1,);
A(,2);
A;
EOF
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"

<stdin>:2:3: error: macro "A" requires 2 arguments, but only 1 given
<stdin>:1: note: macro "A" defined here
A;
<stdin>:3:4: error: macro "A" requires 2 arguments, but only 1 given
<stdin>:1: note: macro "A" defined here
A;
<stdin>:4:8: error: macro "A" passed 3 arguments, but takes just 2
<stdin>:1: note: macro "A" defined here
A;
expanded;
expanded;
A;
$

**デフォルトの名無しさん** · 2022/02/06(日) 16:46:37.28

インクルードガード書くときも単に
#define FOO_HPP
とするのと
#define FOO_HPP 1
と1にするのがあるがどちらが良いとかあるんだろうか

後者の方がconstexpr if文などのC++の言語機能と組み合わせて使えるというメリットがありそうだが

**デフォルトの名無しさん** · 2022/02/06(日) 16:54:43.06

今から新規に書くなら #pragma once 一択

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 17:09:14.27

>>818
私自身は前者にしてる。
インクルードしたことを示すためのフラグとしてのマクロが必要なら
(そういう事例に遭遇したことはないが) ガード用とは別にマクロ定義すると思う。

ガードのために定義したものをガード以外の目的で使うというのがちょっと汚く感じるから。
だけど分けちゃうと管理が二重になるのが嫌だと思う人もいるだろうし、
思想によるんじゃないの。

私は規格厨なので #pragma once は使わない。
まあ gcc と clang と msvc で使えるから事実上は問題にならないけど。

**デフォルトの名無しさん** · 2022/02/06(日) 17:25:15.43

>>820
ありがとう
納得できる理由です

インクルードガード以外のフラグも同様にしてますか？
標準のNDEBUGのように

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 17:46:04.51

>>821
NDEBUG は「デバッグモードとそうでないモードを切り替える」というのがその用途なので
それに沿うと思ったら分けずに NDEBUG を使うことはあるよ。
でも「NDEBUG の用途は assert の有効・無効の切り替えなので他に使うべきでない」と認識している人がいてもおかしくない。

規格に書いてあるのはこの場合はこうだという規則だけなので
抽象的な部分での意味の捉え方は人によってかなり幅がある。
そのあたりは文脈を察して常識的判断でやっていくしかないし、
チームでやってるなら話し合うしかしょうがない。

このへんはそんなにスッパリと判断基準を設けられるようなもんではないと思う。

**デフォルトの名無しさん** · 2022/02/06(日) 19:09:51.99

MS発祥のモノが嫌われてるだけとも思うｗ

**デフォルトの名無しさん** · 2022/02/06(日) 19:46:48.16

>>822
質問の意図がわかりにくくてすみません
自前でフラグ書くなら
>>818の前者と後者どちらを使うのかが知りたかった

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 20:08:36.06

>>824
基本的には前者。
フラグとしてのマクロで分岐するときは #if よりも #ifdef (または defined) を使うようにしてる。
マクロは型を付けられないからそうすることで ON/OFF のどちらかであって内容に意味はない
ことを明示してる感じを出したいと思ってる。

**デフォルトの名無しさん** · 2022/02/06(日) 20:55:43.12

>>825
改めての回答ありがとうございます

こういう一見どちらでも良いものであっても裏の考えや意図が聞けて面白かったです

**デフォルトの名無しさん** · 2022/02/07(月) 06:01:51.26

#pragma onceを標準に採用すればええのに
これだけ需要あるのに長年ずっと放置状態
何がそんなに問題なんだろう

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/07(月) 09:54:39.71

現行仕様での理屈の立て方としては #include の効果でコードに一体化してから内容の解釈が始まるので
インクルードに干渉する余地がない。
現実にやってるんだから出来るのは間違いないんだけど理屈を根本から変えることになるし、
モジュールが上手くいけばどうでもよくなることに手間をかけたくないんじゃないかな。

**デフォルトの名無しさん** · 2022/02/07(月) 11:19:39.20

シンボリックリンクで別のパスになってたりとか、同じ内容の別ファイルとか、ファイル名違う中身同じファイルとか、日付だけ違う別ディレクトリの同じ内容のファイルとか
そんなの考えたくないよなーｗ

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/07(月) 11:53:54.22

名前と実体をどう対応付けるかは今でも処理系定義なのでそこらへんはあまり問題にならないと思う。

**デフォルトの名無しさん** · 2022/02/07(月) 11:56:53.41

そこで#pragma onceはヘッダファイルそのものをインクルード済とみなすのではなくて
定義されている内容を定義済みと記憶するのが妥当な動作
なんだけど以下のような場合に困るという、
"a.h"
struct Foo {

"b.h"
　　int m_x;
　　double m_y;
};

"c.cpp"
#include "a.h"
#include "b.h"

やっぱモジュールにしたら同じような実装で完全な解決になるのだから待った方が、

**デフォルトの名無しさん** · 2022/02/07(月) 12:22:03.46

現行の
#ifdef _FOO_H_
#define _FOO_H_
....
#endif
はヘッダファイルをインクルード済みか否かではなく
マクロ_FOO_H_が定義済みか否かを問題にしているのである意味モジュールに近い
#pragma onceは現行のマイクロソフトのやつはヘッダファイルをインクルード済みか否かを問題にしているので
何をもって同一のヘッダファイルとみなすのかという解釈の揺らぎの影響を受けてしまうまインクルードの挙動が、

**デフォルトの名無しさん** · 2022/02/07(月) 12:25:19.77

>>830
だからどう転ぼうと中身で決められる昔ながらの方法の方が結果が明確ということｗ

ちなみにgccは
シンボリックリンク→ガード
同じ内容・日付・名前、別ディレクトリの別ファイル→ガード
同じ内容・名前、別日付、ディレクトリの別ファイル→インクルード
同じ内容・日付、別名前、ディレクトリの別ファイル→インクルード
みたい

**デフォルトの名無しさん** · 2022/02/07(月) 12:42:43.58

MSの手抜き仕様まで合わせる必要なし

**デフォルトの名無しさん** · 2022/02/07(月) 12:56:32.61

でもCに代わってC++が広まったのはMSのおかげじゃん

**デフォルトの名無しさん** · 2022/02/07(月) 13:10:46.99

ビット数多めのハッシュにしとけば
例えば衝突確率340澗分の１とかにできるよな

**デフォルトの名無しさん** · 2022/02/09(水) 12:59:20.15

64bit osでポインタ型を4byteにするにはどうすればいいんですか？
8byteだとちょっと大きすぎる気がします

**デフォルトの名無しさん** · 2022/02/09(水) 13:03:37.90

なぜ大きすぎると思ったのかが分からないが、64bitのアドレス空間を表すのに8 byteは必要だよ

**デフォルトの名無しさん** · 2022/02/09(水) 13:08:06.15

>>837
貧乏くさすぎ

**デフォルトの名無しさん** · 2022/02/09(水) 13:19:23.53

64bit WindowsOSなら32bitアプリにすればok

**デフォルトの名無しさん** · 2022/02/09(水) 13:40:55.45

例えば64bitの場合アドレスの上位4byteを一意に決めといて下位4byteを4byteの変数に格納しておくってやり方なんてはどうですか？
それで復元時には
(上位4byte << 32) & 下位4byteっていうふうに変換するってふうになると思うんですが
まず最初に上位4byteが一致した連続したメモリ領域から決まってメモリを確保するなんてことはできるのでしょうか？

**デフォルトの名無しさん** · 2022/02/09(水) 13:52:00.55

必要なメモリをvector<X>で確保しておいて32bit以下のindex値でアクセスすることにすれば？

ポインタのサイズが大きすぎるなんて理由でやる人はいないと思うけど

**デフォルトの名無しさん** · 2022/02/09(水) 13:52:47.57

long long ago... タイニー、スモール、コンパクト、ミディアム、ラージ、ヒュージつーのがあってだな

**デフォルトの名無しさん** · 2022/02/09(水) 14:26:32.14

>>842
そうすることにします
ありがとうございました

**デフォルトの名無しさん** · 2022/02/09(水) 14:34:15.15

関数ポインタかなんかが8バイトに収まってなくて混乱したことがあったっけ

**デフォルトの名無しさん** · 2022/02/09(水) 14:37:12.22

昔は16bitポインタと32bitポインタをLPとPで使い分けてたって戦争で死んだおじいちゃんに聞いた

**デフォルトの名無しさん** · 2022/02/09(水) 17:17:57.87

segment:offset時代か・・・

**デフォルトの名無しさん** · 2022/02/09(水) 18:17:45.02

アセンブラの相対ショートジャンプは8ビット

**デフォルトの名無しさん** · 2022/02/09(水) 22:34:51.11

ウィンドーズならINT_PTR使っとけばおkオール無問題
C++の標準規格でどうなっているのかわ知らん

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/09(水) 23:19:57.51

規格上は std::intptr_t というものがある。
ただし関数ポインタやメンバ関数ポインタを格納できるとは限らない。
また、省略可能 (optional) であると明記されているので無くても規格準拠たりうる。

関数ポインタ同士 (メンバ関数ポインタは含まない) はお互いに変換可能であり
元の型にキャストしたら元の値と等しくなることは保証されるので
任意の型の関数ポインタを格納したいのであれば void* や intptr_t を使うよりは
適当な型の関数ポインタに入れるほうが規格に沿う。

メンバ関数ポインタは型通りに扱う以外はほとんど何の保証もないのだけれど
無理に変換して扱いたい場合も特に思いつかないのでどうでもいい。

**デフォルトの名無しさん** · 2022/02/10(木) 02:00:13.27

>>843
far/near を直接指定すれはすむ話、メモリモデルなんてどうでもいい

**デフォルトの名無しさん** · 2022/02/10(木) 19:32:52.48

effective C++って現行のC++と比べてどのあたりが古いんですか？
代表的なところとかだけでも教えてくれると嬉しいです

**デフォルトの名無しさん** · 2022/02/10(木) 19:38:59.22

全て

**デフォルトの名無しさん** · 2022/02/10(木) 20:00:39.81

出版1998年やんけ
こんなもん使うぐらいならC言語やった方がマシなレベル

**デフォルトの名無しさん** · 2022/02/10(木) 20:11:39.77

>>854
一応第3版は原書が2005年に書かれています…

**デフォルトの名無しさん** · 2022/02/10(木) 20:20:25.92

続編のeffective modern c++も古いけど、
こっちは隕石落下後の本だから読んでおいたほうがいいよ

**デフォルトの名無しさん** · 2022/02/10(木) 21:18:10.31

隕石落下後ってなんすか？
あとC++の勉強するならこの本読め、みたいなのって他にもありますか？