C++相談室 part158

■ このスレッドは過去ログ倉庫に格納されています
2021/11/15(月) 18:49:18.44ID:I69rZ/Of
前スレ
C++相談室 part157
https://mevius.5ch.net/test/read.cgi/tech/1628474251/
2021/11/18(木) 02:23:27.66ID:Sx+E3gZ7
>>55
グリフとフォントの違いはいくら調べても、あまり分からなかった。
コードポイントは分かる。
しかし、コードポイントに単にギリシャ文字の「パイ」を割り当てていても、
円周率用におなじみのパイであるとは限らず、実際にWindowsでは、門構え
のような変な文字になってしまってる。
そして、それを回避するのは難しい。
2021/11/18(木) 02:26:19.78ID:Sx+E3gZ7
字体と字形は違うという話もある。
漢字の場合は確かにそうかもしれない。
しかし、数学では最後の形が重要だから、最後の最後の最後の画面上に表示される
グラフィックが、数学の習慣にぴったり一致してなければ駄目。
2021/11/18(木) 07:48:03.24ID:R1PabgqQ
円周率にギリシャ文字のπを充てた数学が悪い、数学は俺々円周率記号を作るべきだった
って言ってる?
2021/11/18(木) 07:57:54.58ID:SHW/gJRC
auto \u03c0 = std::numbers::pi;
2021/11/18(木) 09:43:04.76ID:RYwZiL19
コードは別れてるのだから、あとはデザイナの問題、フォント使用者の問題だろ
外人が作ったフォントの"ゐ"の字が"い"と同じだったからunicodeに"ゐ"の字を安定的に出せるようにしろっていうのはお門違い
2021/11/18(木) 09:55:03.61ID:maTPk2BR
お前らおっぱいの形で何を興奮してるんだ?w
この変態どもめw
2021/11/18(木) 10:01:42.33ID:SHW/gJRC
おっぱいに興奮するのは正常な性欲で変態じゃないぞ
あ、変態から見るとノーマルが変態なのかw
63デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:08:33.41ID:/He/baLS
うちのπは変換選択中は数学記号のπで一覧に出てるんだが変換確定すると門構えのπになるなω
アプリのフォントとIME(FEP)のフォントが違うんだろうなωωω
64デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:10:13.05ID:/He/baLS
秀丸なら数学用のπだし
メモ帳だと門構えのπだったわ
TeX使ったらどうでもよくなるけど
65デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:17:33.47ID:/He/baLS
とりあえず
メイリオは糞π
MS Gothic は 数学用π
MS 明朝は 数学用π
みかちゃん ぎりぎりセーフ
Migu 1M 数学用π
IPAex Gothic 数学用π
IPAex 明朝 数学用π

んーいまのところだめなのメイリオだけだなω
2021/11/18(木) 11:20:46.59ID:RYwZiL19
56はwindowsがって言ってんだから全部ダメなんだろ
67デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:57:56.18ID:/He/baLS
>>56
>それを回避するのは難しい。

えっ?
2021/11/18(木) 17:51:51.89ID:hyycWvP/
using namespace std;
するのとstd名前空間内の各エンティティについて
using std::foo;
するのに違いはありますか?
2021/11/18(木) 21:59:19.03ID:asQz6rBs
はい。前者は std 内全部の名前が修飾なしで使えるようになりますが、後者は指定したものだけになります。
2021/11/18(木) 23:09:08.75ID:tPrhQHc6
明朝体とかゴシック体がフォント
明朝体で書かれた「あ」とゴシック体で書かれた「あ」は異なるグリフの「あ」
文字としては同じ

ということのはずだがユニコードはぐちゃらけてしま
tったど
うしてこなうった!?
2021/11/18(木) 23:11:14.48ID:tPrhQHc6
ググったらJISで「♯」と「#」が異なる文字だからユニコードでも元に戻せるように異なるコードにしているとか
ワケワカメ
一昔前の似たような文字を同じコードにする方針な美しいユニコードはどこいった……?!
2021/11/18(木) 23:12:14.00ID:tPrhQHc6
訂正orz
△:異なるコード
○:異なる文字
2021/11/19(金) 00:01:43.17ID:bln5kEpJ
>>71
シャープとナンバーサインは違う記号で違う意味でしょ。
カタカナの「ロ」と漢字の「口」まで統合されかかったというエピソードもあるんだが、
そういうのが Unicode の美しさだと思うか?

何を以て「似たような文字」とするか文字に対する考え方というのは
それぞれの文化によるによるので既に確立している符号体系を尊重するのは合理的な方針なんだよ。
歴史的経緯を切り捨てられないのは不格好だが逆に言えば既存の不格好さを継承する程度で済む。
2021/11/19(金) 08:12:17.83ID:Lvg3H2b6
>>71
CJK統合漢字の大失敗に懲りたんだろ。
2021/11/19(金) 09:07:31.36ID:jz7MocuB
ここC++のスレだよな?
2021/11/19(金) 10:51:32.62ID:Zjxpzk7M
そうだよスレ違いのUnicode叩きも擁護も出て行け
77デフォルトの名無しさん
垢版 |
2021/11/19(金) 11:12:38.26ID:eyeX0xyM
♯include は動かない方が良い
\ も mac だとやばい \ があるらしいなω
78デフォルトの名無しさん
垢版 |
2021/11/19(金) 11:14:02.03ID:eyeX0xyM
codepadだかideoneだかが
\nを勝手に半角の¥nにしてコンパイル通らなくて可笑しいときがある
2021/11/19(金) 11:30:01.23ID:IBPJGhlA
>>77
素人丸出しだからそのへんでやめとけ
\が(過去の経緯で)本来あるべきグリフで表示されないのはwindows(日本語設定時のみ)のほう
2021/11/19(金) 13:02:30.99ID:bln5kEpJ
JIS X 0201 (7ビット及び8ビットの情報交換用符号化文字集合) による。
JIS X 3010 (プログラミング言語C) の中でもスラッシュとチルダが JIS X 0201 では円記号とオーバーラインに
置き換えられる旨の補足情報が書かれている。

つまり Windows の挙動は日本の (文字コードに関する) 規格を尊重した結果だし、C の JIS 規格でもちゃんと言及している。
とはいえ ISO/IEC 9899 に反する事情があるからこそ日本の規格 (JIS) にするにあたって補足を入れる必要があったわけで、
「本来あるべき」から遠いのは確かに Windows のほうとは言える。
81デフォルトの名無しさん
垢版 |
2021/11/19(金) 14:07:51.51ID:eyeX0xyM
>>79
知ってると思うが
これの話なんだが
http://codepad.org/WsmFWVty
#include <stdio.h>

int main()
{
printf("abc\n");
return 0;
}
82デフォルトの名無しさん
垢版 |
2021/11/19(金) 14:10:16.50ID:eyeX0xyM
>>79
これも一緒ね
https://ideone.com/KyjIyk
どうでも良いけどω
2021/11/19(金) 15:13:48.52ID:gL3kBbt5
どうでもいいのは勘違いしてるお前の話
2021/11/19(金) 17:22:13.91ID:r4tdjD9P
アホすぎる
C++の話しようぜ
85デフォルトの名無しさん
垢版 |
2021/11/19(金) 18:47:23.14ID:P2N6jWZN
WindowsのvisualC++2019でDLLのロードが出来ません
dll defからlibをつくり#pragma comment( lib, "sample" )とやればできた記憶なんですが
64bitのバージョンも全部合わせてあるんですが
10年ぶりにやったら動きません
ボーランドC++だと修飾名が変わってdefを書き換えたりはあったと思うのですが

> error LNK2019: 未解決の外部シンボル sqlite3_open
8685
垢版 |
2021/11/19(金) 18:53:32.17ID:P2N6jWZN
自己解決しました
dumpbin.exe /exports コマンドでdefファイルを作成した場合、
EXPORTS の記述がなかったからでした
2021/11/20(土) 00:18:32.03ID:KMJ1ohr2
>>81
エスケープを円で覚えてるからそんな間抜けな間違いするんだよ
ブログラマならエディタの設定変えとけ
2021/11/20(土) 04:22:38.39ID:VRiN34hT
>>81
馬鹿過ぎて
89デフォルトの名無しさん
垢版 |
2021/11/20(土) 11:48:10.21ID:DTIeq0Vp
>>87
ブログラマってなにかの隠語?
2021/11/20(土) 12:05:58.69ID:T1SqYaku
ナニナニ
    彡⌒ ミ ナニナニ
   (´・ω・`) 彡⌒ミ
,彡⌒ 彡⌒ ミ (・ω・`) また文字コードの話?
(´・ω(´・ω・`) ⌒ ミノ⌒ミ
  u_| ̄ ̄||´・ω・`)ω・`) マター?
 /旦|――||// /|と ノ
 | ̄ ̄ ̄ ̄ ̄| ̄| . |-u
 |_____|三|/
2021/11/20(土) 19:11:01.64ID:F5vrtFYR
>>90
プログラマ=ハゲと思われるからそのAAやめろよ(´・ω・`)
2021/11/21(日) 03:33:39.04ID:yh1CvOcy
実際C++プログラマはハゲが多いんだから別にいいだろう
教祖からしてハゲなんだし
2021/11/21(日) 08:40:03.48ID:uokK0Aao
そうそう、教祖がゲーハー
これはデカい
2021/11/21(日) 17:11:36.41ID:BwaLJwgU
Greek PhiはU+03A6(大文字)・U+03C6(小文字)・U+03D5(数学用シンボル)
Empty setはU+2205
全く別のコードポイントが割り当てられてるし、>>19の資料でも全く別の文字として議論されてるけど
何を見て何がどう区別されてないと思った?
2021/11/21(日) 20:56:14.20ID:MSJBJTi1
プログラミング言語の世代論というのがあって、
第一世代は CPU のアーキテクチャべったりの機械語、
第二世代は機械語が解る人間向きの低級言語、
第三世代は自然言語寄りの高級言語、
第四世代は目的型言語、
…… で、いわゆる「第五世代」は、コンピュータの都合じゃなくて
人間の都合に合わせようよ、というコンセプトになった。
「じゃあ、どのあたりから始めるか」という話は
ありそうに思う。
2021/11/21(日) 22:09:51.70ID:jS7RYefb
>>79
素人丸出しとか言ってるが
実際macだと設定によってはバックスラッシュと同じ扱いにならない\が
普通にキー叩いたら出るんだぞ
2021/11/21(日) 22:16:19.52ID:32ll5fa9
エスケープが円だと思ってるから間違えるんだろ
2021/11/21(日) 22:42:33.87ID:zasxIKRm
普段からU+005Cのグリフがバックスラッシュになってるフォントしか使わないから円記号に違和感しかない

そりゃ個人の自由だけどプログラミングしてるなら少しフォントにこだわってもいいと思う
2021/11/22(月) 11:36:57.09ID:/m9OFYAK
日時を数値に変換する良い感じの関数教えてくださいよ
2021/11/22(月) 11:53:19.81ID:NpEcC+CD
std::chrono
2021/11/22(月) 12:07:40.30ID:axkd8Lua
おどろき最小の法則と言えば
https://onihusube.hatenaぶろぐ.com/entry/2020/04/03/211442
2021/11/22(月) 12:12:11.62ID:buYIHjVZ
人を下に見られる程精通してる人って正直羨ましいわ
知れば知るほどまだまだ知らない事が沢山あるなぁと勉強不足を実感してしまう

知らないから人をバカに出来るんだよなー

むしろ人を下にみないと精神状態が不安定なんでしょ
2021/11/22(月) 12:23:22.14ID:NpEcC+CD
ダニングクルーガーね
2021/11/22(月) 13:29:19.96ID:SX8MGonp
Windows App SDK入れてみたがエラーが多くまだ使えない
2021/11/22(月) 19:04:02.58ID:aHjY0LXr
ヘッダファイルで変数の宣言するとき、引数付きのコンストラクタ使おうとするとコンパイルエラー出るんですけどこの書き方って良くないんですか?
2021/11/22(月) 19:08:25.29ID:f9+TjGGq
>>105
ヘッダだからエラー、というわけではないです
ヘッダじゃない普通の cpp に書いてもエラーなのでは?
具体的にソースを示してください
2021/11/22(月) 20:43:52.70ID:aHjY0LXr
>>106
// NG ヘッダにそのまま書こうとすると型指定子が必要ですとエラーが出る
private:
MenberLibClasse obj ("piyopiyo");

// OK ヘッダには引数なしで宣言した後、cppでobjをメンバに持つクラスのコンストラクタの初期化子リストを使うと何故か通る
private:
MenberLibClasse obj;
Class() :obj ("piyopiyo") { }

挙動把握しきれないんですけどライブラリ側の問題でしょうか??
2021/11/22(月) 20:50:48.90ID:f9+TjGGq
>>107
NG のときのエラーの内容は?
エラーメッセージを貼ってください、正直、よくわかりません
2021/11/22(月) 20:56:23.56ID:0LbM6y2O
>>107
宣言の位置でメンバを初期化できるのはC++11からだけど、それが原因かな?
2021/11/22(月) 20:59:28.54ID:UBpGrDL8
書くとしたらこうやろ
private:
MenberLibClasse obj = "piyopiyo";
2021/11/22(月) 21:02:09.68ID:jXuEZ/Sz
丸括弧はダメだよ
イコールか波括弧でなきゃ
2021/11/22(月) 21:04:04.13ID:jXuEZ/Sz
型指定子が必要って言われるのは
関数宣言と見られていて
仮引数の場所にリテラルがあるってことだ
113デフォルトの名無しさん
垢版 |
2021/11/22(月) 21:13:00.22ID:aHjY0LXr
>>111
イコールはダメで波括弧に変えたらコンパイルできました
2021/11/22(月) 21:30:02.05ID:ahYOm2Qx
private:
MenberLibClasse obj{"piyopiyo"};
2021/11/22(月) 23:03:46.80ID:gucWMAFN
>>99
using namespace std::chrono;

// 現在時刻を取得
system_clock::time_point tp = system_clock::now();

// 現在時刻のミリ秒部分を取得
auto msec = duration_cast<milliseconds>(tp.time_since_epoch()).count() % 1000;

みたいなことをやると良い最後のまmillisecondでもsecondでもnanosecondでも逝ける

こないだ死ぬほどやり倒すた、

しかしずんねんながら現状MSVCのstd::chrono::zoned_timeが未実装のため、

システム時刻関連処理についてstd::chronoの利用を断念すた、orz
2021/11/22(月) 23:16:45.51ID:gucWMAFN
なおtime_point同士で引き算もできる
結果を具体的時間単位の時間表現にするのは同じくduration_cast<T>()
2021/11/23(火) 10:20:15.57ID:wZOweAJh
ostringstream の precision の上限がなぜか 255 に設定されているようで
mpreal big("1000桁規模の浮動小数点数");
ostringstream ss;
ss.precision(1000);
ss << big;
とすると ss に 255 文字程度しか入らないのです
cout.precision(1000);
cout << big;
だと 1000桁出ます
ostringstream の precision の上限をもっと大きくする方法はありますか?
2021/11/23(火) 10:22:20.09ID:wZOweAJh
ああ
勘違いかも
もうちょっと調べて質問します
2021/11/23(火) 10:28:59.05ID:wZOweAJh
とりあえず判ったのは
ss.rdbuf() の default の上限値が 255 らしい
2021/11/23(火) 10:53:38.11ID:v39GCTAR
だっせ
そんな上限、規格票に書いてあるのか?
2021/11/23(火) 11:40:46.26ID:Vfqk4Xs7
>>115
>MSVCのstd::chrono::zoned_timeが未実装

TZ=JST-9
とか描いてあってもだめかな
2021/11/23(火) 11:52:24.16ID:wZOweAJh
>>120
ss.rdbuf()->in_avail()
2021/11/23(火) 13:42:01.58ID:X+sq98An
再現しそうな最小限のコードだけ描いて
mingw + gcc でコンパイル&実行したら期待通りの動作をしたが
VC だとやっぱり上限があるっぽい動きになってる
rdbuf() 使いつつ seek() すれば大丈夫かも知れないが
自分の使い方が間違ってるだけだと思いたい
2021/11/23(火) 13:44:07.61ID:X+sq98An
とりあえず mpreal は関係なかった
VC 側の問題らしいのでもう少し掘ってみる
2021/11/23(火) 14:39:06.53ID:X+sq98An
VC 側 rdbuf()->pubseekpos() 併用で解決
2021/11/23(火) 15:22:40.52ID:V3fVQTwt
クラスのメンバ変数が全部intとかdoubleとかで足し算掛け算ができるものの場合に、
クラスの足し算掛け算を各メンバ変数の足し算掛け算として定義したいのですが
operator +とかoperator *のオーバーロードでメンバ変数について一個ずつ書いていく以外の方法ありますか?

今やろうとしていることでメンバ変数が多いので、いちいち列挙せずに済むなら便利だなと思ったのですが
2021/11/23(火) 15:49:25.55ID:57zkg5+u
>>126
valarrayじやね?
2021/11/23(火) 16:47:46.55ID:za9QU+hA
>>117
VC の in_avail() が間違った値を返してるんだなこれ
2021/11/23(火) 17:12:53.52ID:V3fVQTwt
>>127
ありがとうございます、使ってみます
2021/11/23(火) 17:34:18.50ID:VSfhJ4CF
>>126
現在の C++ はリフレクション系の機能が弱くてクラスからデータメンバを列挙するというようなことは出来ない。
「全てのメンバに対してやってくれ」というようなことはできない。
ただ、対象となるメンバを取り出すものさえ用意すればそれを様々な演算に適用することは可能だと思う。
つまり、メンバの列挙を一度で済ませる (なんども列挙しなくてよい) ことは出来るかもしれないってことね。

とはいえそれはそれで割とクソめんどうくせぇメタプログラミングの下準備が要るので
いっそ列挙しまくったほうが簡単かもしれん。
2021/11/23(火) 17:57:00.33ID:UgBkVfMX
Q_OBJECT とかだとメンバの列挙出来たっけ
2021/11/23(火) 23:10:58.29ID:G9Rlesey
>>121
駄目なんじゃないかと思う
std::chronoはtime_pointを抽象化してタイムゾーンの異なる時刻間の差分を自動で取り扱いたい(そういう思想な)はずで、
ということはローカルタイムを扱う手段としてzoned_timeは無くてはならないピースとみなさざるおえない

どうしてもというならstd::chrono::system_timeを経由して古き良きtime_tとtime_pointの相互変換ができるから、
time_tまで降りてローカルタイムにしてtime_pointに戻す手はあるが、それをすると
同じtime_pointクラスで表される2種類のシリアル時間がプログラム内に生じてしまうから、
std::chronoの上記思想(時刻の差分や比較を自動で安全に取り扱いたい)が破壊される

ライブラリ仕様の理想が高邁すぎるか実装側の怠慢によって大事な用途において糞ライブラリになってしまっている例
2021/11/23(火) 23:41:07.98ID:mX+uwseB
何が出来ないと言っているのかまるで分からん
出来る部分と出来ない部分の切り分けがいるんでないの?
2021/11/24(水) 00:03:21.95ID:EdXujyLt
time_point(事実上UTC)とローカルタイムの相互変換がstd::chronoが思想的に目指しているほど安全にはできない
zoned_timeが実装されない限り

time_point(事実上UTC)同士の比較や差分はzoned_timeが実装されてないバージョンでも安全にできる
2021/11/24(水) 00:18:07.67ID:HKyZluCV
そんなアバウトな情報いらん
2021/11/24(水) 00:31:14.95ID:EdXujyLt
えっと、>>135はUTCとローカルタイムの変換ってわかります?
2021/11/24(水) 00:39:36.48ID:EdXujyLt
std::chronoで現在時刻を取得する一番自然な方法は、
 system_clock::time_point now = system_clock::now();

他にもtime_tからの変換という方法があるが、いまさらtime_t使え言うぐらいならstd::chrono使わずにtime_tだけ使うは;;;

で、nowはどう見てもUTCであるから、日本時間を知りたければ、
上記time_point nowが日本時間の何年何月何日の何時何分何秒なのかを出力できねばならない
std::chronoの中にはzoned_timeを使わずにそれをやる手段が見当たらない
2021/11/24(水) 00:44:19.87ID:jtZYcQVF
C++20より前のchronoはタイムゾーンのこと知らんからな…
2021/11/24(水) 01:06:29.20ID:HKyZluCV
>>99で聞かれてるのは「日時を数値に変換」だろ?
前提も条件も全部曖昧で、自然とか思想とか思い込みばかり
何を使うと何が出来て何が出来ないを全く説明してない
2021/11/24(水) 01:21:45.20ID:Jllasahs
chronoはローカルタイムを扱えない、と言ってると思うよ
2021/11/24(水) 02:40:02.07ID:xFDMAHHD
http://pbs.twimg.com/media/EUH_eMWUwAAgsV4.jpg
https://pbs.twimg.com/media/D4p7dNfUwAAa34y.jpg
2021/11/24(水) 03:00:57.55ID:P1gN11rG
ローカル時刻かUTCか以前の問題として、そもそもどんなフォーマットで数値に変換するのか
それが不明だったから誰も回答しなかったのだろうに

あとドキュメント信じる限りじゃzoned_timeはVS2019 16.10から使えるってよ
2021/11/24(水) 03:04:53.60ID:Q5JPayEq
C++は糞
std::は糞ばかり
boost最強
まで読んだ
144デフォルトの名無しさん
垢版 |
2021/11/24(水) 03:08:01.30ID:Q5JPayEq
>>142
>>100 が悪い
2021/11/24(水) 04:22:29.20ID:xFDMAHHD
じゃ、もうtime_t使っとけ
2021/11/24(水) 05:14:05.40ID:ZtAViqSQ
「良い感じの関数」なんて今流行りwのAIとか使わんと無理でしょ
2021/11/24(水) 07:01:18.14ID:xQvD3wWY
確かにchronoは今一だね
filesystemはthread, iomanipとの連携が悪すぎ
使いにくいったらありゃしない
2021/11/24(水) 07:01:39.82ID:xQvD3wWY
- filesystemは
+ tilesystemや
2021/11/24(水) 08:47:11.69ID:xQvD3wWY
auto p = (void*)[]{};
これが通らないんだけど
stateless-lambdaは関数と見なせない?
2021/11/24(水) 09:11:02.53ID:083KFMkM
auto p = (void*)(void (*)())[]{};
2021/11/24(水) 09:17:04.13ID:xFDMAHHD
auto p = []()->void*{};
もう少し学習しろ
2021/11/24(水) 10:46:50.00ID:kXzWnsgO
何がしたいんか知らんけど
auto p = [](){};
auto p = []()->void*{};
auto p = []()->void{};
本人の意図が判らんことには絶対に正解に辿り着けない質問大杉
2021/11/24(水) 11:11:35.49ID:xQvD3wWY
void func1(void*);
void func2(){}
func1(func2);
のようなことをしようとしてて怒られるから
func1((void*)func2);
にしてた

で、func2で名前空間を汚染したくないから
stateless-lambda使おうと思った
2021/11/24(水) 11:25:51.06ID:nY9AsqgQ
関数 (関数ポインタ) を void* で受ける雑なことをしといて名前空間を汚すのは気にするのか。
まあフレームワークとかの側でそうなってたら仕方ない場合もあるけど……。
2021/11/24(水) 11:28:11.15ID:P1gN11rG
variant的なことを昔ながらの方法でやっているのかもしれない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況