- MinGW GCC-3.4.5 の g++ において、
std::getline()を実行した直後のstd::basic_istream::tellg()が、テキストモードでは正しい値を返してくれないだけでなく呼び出し時に内部的なファイルポインタをも破壊してしまい、それ以降の入力までおかしくなってしまう（泣）。これについてはすでにいろいろな議論もある… tellg modifying the state of an input file stream とか "get pointer" will be dirfted after invoking tellg() 。後者にはバイナリモードでストリームをオープンすればよい、と書いてあり、確かにそうであることを確認したが、CRLF のファイルをstd::getline()で読んだ文字列末尾に CR が付いてきてしまう。 - MinGW GCC-3.4.5 の g++ において、
read(buf, streamsize)がstreamsizeより長い位置のbuf領域にゴミ値を書き込んでしまうケースがあるらしい。
- （ページなし）Visual Basic 6.0並びにVBAにはC言語の
&&や||に相当する論理演算子（ショートサーキット演算子）が無く、全部が常に評価（実行）されてしまう。IF文のネストで代用するしかない。一方、VB.NETならAndAlsoとOrElseがある。
- 関連：ANSI実装において
isspace(int c)など ctype.h にある「is系関数」に8bit文字（日本語文字列のほか、ISO-8859-1なども該当する）を食わせる可能性があるときはisspace((unsigned char)*wp)としないと、暗黙の型変換でchar型をint型に変換するときの符号の扱いのために潜在バグになる。
これはリリースビルトでは発見が非常に困難で訳の分からない挙動につながるが、デバッグビルドをVS IDE上で実行すると ASSERT が発生してわかる場合がある。VS IDE上で実行しにくい外部利用DLL等を作成する場合は細心の注意を払う必要がある。
abs , max , min を定義しているので C++ STL や std::valarray などとの衝突に注意。これは Windows.h における NOMINMAX と類似の問題。
_splitpath() / _splitpath_s() の罠 [2017/01/21]
- IPA セキュア・プログラミング講座 Windowsパス名の落とし穴にも載っていない深刻な話。
- 置換前
(".+?") - 置換後
_T($1)
fopen() について warning C4996 セキュリティ云々という文句を言ってくるが、 fopen() に限って言えばその実態は、ファイルをロックしないということと、書き込みモードではファイルが存在する場合には強制上書きをせず中断するという選択肢がないということだけである。strcpy() 等のバッファオーバーラン・特権昇格などの関数とは問題の性質が違う。もちろん、読み書き中のファイルに別の内容を差し込んだり内容を消滅させるという状況を作ってファイルポインタを破損させシステムを破壊工作することはできるが、そもそもそういう入力の正当性チェックは別途でやるべきでしょう、という気がする。それに C++ の iostream/fstream はそんなファイルロック機構など持ってないぞ。お節介というか、片手落ちもいいところ。そうであれば、その C4996 エラー（警告）メッセージで推奨すべきなのは C99 と微妙に非互換な実装になっている
fopen_s() ではなく、第３引数以外 fopen() と同一仕様である _fsopen() なんじゃないか？なお、自分のソースコード記述の腕を過信しつつ
fopen() を継続利用するなら次の方法がある。
fopen()の直前の行に#pragma warning(suppress:4996)を書く。fopen()の前後を#pragma warning(push-disable:4996)と#pragma warning(pop)で囲む。
一方、ソースコード中への
#define _CRT_SECURE_NO_WARNINGS 記述、あるいはコマンドラインコンパイラオプション /wd4996 追加によるグローバルな指定は、本当にまずい関数も通してしまう乱暴なやりかたであり、使用にはきっちり吟味のうえ細心の注意が必要な気がする。もちろん、どちらにしても、そういうことをしていることは、ソースコードや Makefile だけでなく、どこか別のドキュメントにも記録をしておくべきであろう。自分だけがプログラミングしている間はよくても、他の初心者にソースコードを渡すときに、こういう「使い倒し」は案外と伝わりにくかったりする。
size_t と int の変換における潜在バグの防止用関数…例えば
int i2=0; int i1=1; putchar(lpszString[i2-i1]); すなわち (size_t)(-1) のように、単なる暗黙静的キャストではとんでもない値に変換されてしまうケースへの備え。（std::string::npos の定義のように意図的な場合は別ですよ）CとFORTRANとの混合言語プログラミング（FORTRAN には size_t はおろか unsigned の概念自体がない）や、Windows での 64bit ビルド (LLP64) の warning C4267 の正当な解決に役立つ。
- まずは純粋Cで、黙って変換可能範囲内に丸め込むバージョン。よほどのことがない限りこれで十分でしょう。
static size_t int_to_size_t(const int n){ return (size_t)(n > 0 ? n : 0); } static int size_t_to_int(const size_t n){ return (int)(n < INT_MAX-1 ? n : INT_MAX-1); } - C++ならば、変換しきれない場合に例外を投げてもよいかもしれない。純粋Cならば代わりに
abort()でしょうか。static size_t int_to_size_t(const int n){ if(n < 0){ throw range_error("conversion failure negative int to size_t"); } return (size_t)n; } static int size_t_to_int(const size_t n){ if(n > INT_MAX-1){ throw range_error("conversion failure too large size_t to int"); } return (int)n; }
cl /MD /LD ExcelDLLTest.cpp user32.lib /link /DEF:ExcelDLLTest.def
検索対象文字列には関数を抜けた後も寿命が保たれる文字列が必要であり、一時オブジェクト文字列を与えてはいけない。
- これはOK
smatch result; string str = " 10: 04:01.2345 ,teststring" regex rex = regex("^\\s*(\\d+)\\s*:\\s*(\\d+)\\s*:\\s*(\\d+\\.?\\d*)\\s*,\\s*([^\\s]+.*)"); if(! regex_search(str, result, rex)){ cout << "error [" << str << "]" << endl; return 1; } for (auto x : result) { cout << "[<" << x << ">]" << ','; } - これはダメ。MS-VC++2013ではコンパイラ警告は一切出ないが、落ちたり、落ちないまでも結果がおかしくなったりする。C++14ではコンパイルエラーになるとのこと。
smatch result; string str = " 10: 04:01.2345 ,teststring" regex rex = regex("^\\s*(\\d+)\\s*:\\s*(\\d+)\\s*:\\s*(\\d+\\.?\\d*)\\s*,\\s*([^\\s]+.*)"); if(! regex_search(string(str), result, rex)){ cout << "error [" << str << "]" << endl; return 1; } for (auto x : result) { cout << "[<" << x << ">]" << ','; } - これもダメ。
なんでだろ？？smatch result; string str = " 10: 04:01.2345 ,teststring" regex rex = regex("^\\s*(\\d+)\\s*:\\s*(\\d+)\\s*:\\s*(\\d+\\.?\\d*)\\s*,\\s*([^\\s]+.*)"); if(! regex_search((str + "abcde"), result, rex)){ cout << "error [" << str << "]" << endl; return 1; } for (auto x : result) { cout << "[<" << x << ">]" << ','; }
→smatch という typedef はマッチ要素を指す一種のイテレータであるのだそうだ。 成程、result はメモリ領域が確保された実体文字列ではなく、各要素を指すポインタの配列と言い換えられる。regex_search() に一時オブジェクトを渡すと、regex_search() が終わった時点でその一時オブジェクトの寿命は尽きるから、result の各要素が何を指すかは未定義になってしまう。これでは何が起きても文句は言えない。納得。
→事柄はcpprefjpにちゃんと載っていました。ただしMS-VC++では対応バージョンが不明とある。この実験から、cpprefjpでいうところの (4) はVC2013では =deleted されていないということがわかった。C++11の範囲内だと引数の型が暗黙型変換で合致するものがあるので、コンパイラ警告は一切出ないのだ。なるほどなあ。
- VBAにおけるカレントディレクトリ変更は既に実施してある状態にて。(ChDrive ActiveWorkbook.Path , ChDir ActiveWorkbook.Path)
- 当該DLLをPATHを通してあるフォルダにコピーしてもよい。
- その場合であって、その当該DLLからさらに別の下位DLLを呼び出している場合、その別の下位DLLをコピーする必要があるか否かは、その当該DLLにおいてセキュリティー対策として SetDllDirectory("") を呼び出してあるか否かに依存し、やっていない場合はその別の下位DLLをExcel VBAにおけるカレントディレクトリに置いてあってもよいようだ。
こんなのがあった。https://qiita.com/mmYYmmdd/items/fc1d3cce6a39771c0f36 すげー！ この例において
p = AddDllDirectory(StrConv(ActiveWorkbook.Path, vbUnicode)) とすることで解決。
[2018/02/03]
- 既に閉じられたストリームについてメンバ関数 close() を実行すると、エラービットが立ってしまう。具体的には、fail() が真を返す。また、既にエラービットが立っている状態で exceptions() で例外の設定を行うとその瞬間に例外が投げられる（エッジトリガーではなくレベルトリガーである）。
#include <iostream> #include <fstream> #include <sstream> using namespace std; int main(int argc, char *argv[]) { fstream ofs; ofs.close(); cout << "ofs.good()" << ofs.good() << endl; cout << "ofs.eof()" << ofs.eof() << endl; cout << "ofs.fail()" << ofs.fail() << endl; cout << "ofs.bad()" << ofs.bad() << endl; cout << "ofs.is_open()" << ofs.is_open() << endl; ofs.open("abcde.in",std::ios_base::out); cout << "ofs.good()" << ofs.good() << endl; cout << "ofs.eof()" << ofs.eof() << endl; cout << "ofs.fail()" << ofs.fail() << endl; cout << "ofs.bad()" << ofs.bad() << endl; cout << "ofs.is_open()" << ofs.is_open() << endl; ofs.close(); cout << "ofs.good()" << ofs.good() << endl; cout << "ofs.eof()" << ofs.eof() << endl; cout << "ofs.fail()" << ofs.fail() << endl; cout << "ofs.bad()" << ofs.bad() << endl; cout << "ofs.is_open()" << ofs.is_open() << endl; ofs.close(); cout << "ofs.good()" << ofs.good() << endl; cout << "ofs.eof()" << ofs.eof() << endl; cout << "ofs.fail()" << ofs.fail() << endl; cout << "ofs.bad()" << ofs.bad() << endl; cout << "ofs.is_open()" << ofs.is_open() << endl; try{ ofs.exceptions(std::ios_base::failbit | std::ios_base::badbit); ofs.close(); cout << "ofs.good()" << ofs.good() << endl; cout << "ofs.eof()" << ofs.eof() << endl; cout << "ofs.fail()" << ofs.fail() << endl; cout << "ofs.bad()" << ofs.bad() << endl; cout << "ofs.is_open()" << ofs.is_open() << endl; ofs << "a" << endl; } catch(exception& e){ cout << "err" << e.what() << endl; } catch(...){ cout << "err" << endl; } return 0; }
#include <iostream> #include <limits> #include <string> using namespace std; |
文章中に相互参照で章番号などを引用しているものがいつのまにか「0」になってしまうお困りごとがあったので。なお 同じ事象の報告例は他にもある 。自分の場合は、ある章・節の見出しに関する相互参照を設定した後、ページ内容記述の都合で章・節の見出しを改ページで次のページに送る場合に「0」になってしまう現象が発生している。修正方法は現状、相互参照の設定をやり直すしかないようです。明らかに Word のバグだと思います。
実装には Stack Overflow のこの記事 が大変参考になりました。ほとんどそのまま流用しています。
Sub ExamineWordCrossReferenceFields()
' based on https://stackoverflow.com/questions/24951526/get-all-cross-references-in-word-with-vba
Dim objDoc As Document
Dim objFld As Field
Dim i As Long
Dim sresult As String
Set objDoc = ActiveDocument
' Loop through fields in the ActiveDocument
For Each objFld In objDoc.Fields
' If the field is a cross-ref, do something to it.
If objFld.Type = wdFieldRef Then
sresult = sresult + objFld.Code + ",[" + objFld.Result + "]" + vbCrLf
objFld.DoClick
MsgBox "check it!"
End If
Next objFld
MsgBox sresult
End Sub
|
Sub ExamineWordCrossReferenceFields()
' based on https://stackoverflow.com/questions/24951526/get-all-cross-references-in-word-with-vba
Dim objDoc As Document
Dim objFld As Field
Dim i As Long
Dim sresult As String
Set objDoc = ActiveDocument
' Loop through fields in the ActiveDocument
For Each objFld In objDoc.Fields
' If the field is a cross-ref, do something to it.
If objFld.Type = wdFieldRef Then
sresult = sresult + objFld.Code + "＝【" + objFld.Result + "】" + vbCrLf
End If
Next objFld
If "" = sresult Then
MsgBox "相互参照はありません。", vbOKOnly Or vbInformation, ActiveDocument.FullName
Exit Sub
End If
sresult = "以下の一覧を個別確認しますか？" + vbCrLf + sresult
If vbCancel = MsgBox(sresult, vbOKCancel Or vbQuestion, ActiveDocument.FullName) Then
Exit Sub
End If
' Loop through fields in the ActiveDocument
For Each objFld In objDoc.Fields
' If the field is a cross-ref, do something to it.
If objFld.Type = wdFieldRef Then
objFld.DoClick
Application.ScreenRefresh ' 表示倍率によりレンダリングが遅れるようなので
objFld.DoClick ' もう一度そこへ飛ぶ
If vbCancel = MsgBox( _
objFld.Code & "＝【" & objFld.Result & "】", _
vbOKCancel, _
ActiveDocument.FullName _
) Then
Exit For
End If
End If
Next objFld
End Sub
|
https://apc.hatenablog.jp/entry/2019/04/21/131855 （APC的雑記 - はてなブログ） にある方法が使えるが、游明朝の例しか上がってないので、いくつか試してみました。
要はフォントの MS-Windows 内部名がわかれば、それを名指しすることはおおむね可能のようです。
ちなみに、本家：https://matplotlib.org/stable/gallery/text_labels_and_annotations/font_family_rc_sgskip.html
|
- https://qiita.com/yniji/items/3fac25c2ffa316990d0c
- https://qiita.com/yniji/items/2f0fbe0a52e3e067c23c
- https://gammasoft.jp/blog/matplotlib-japanese-fonts/
https://www.yutaka-note.com/entry/matplotlib_axis （YutaKaのPython教室） ※メモが分散するのも困るので、ここに一緒に引用してしまいます。
以下のコードは、数学的には同じものを求めようとしているが、2進コンピューターでは同じ答えが出てこない、という単純な例。
|
（この方法では Audacity 自体のコンパイルは結局うまくいかなかったのだが）Audacity の ASIO 対応コンパイルで Visual Studio Community をダウンロードするのが面倒で、下記引用元サイトの情報を参考にしつつ、既にある Visual Studio 2017 Express を使おうとしたが、Express には 64bit の Native コンパイラが入っていないため、そのままの手順だと
ConanException: VS non-existing installation: Visual Studio 15 というエラーが出てしまい、libmp3lame で止まってしまう。「VS 2017 用 x86_x64 Cross Tools コマンド プロンプト」を起動し、そこに CMake-GUI のショートカットを放り込んで起動すれば、環境変数を取り込んで認識してくれた。
しかし、この方法では結局 Audacity 自体のコンパイルはうまくいかなかった。なんでも wxWidgets のソース内に GNU GPL が wxT マクロでべたテキストで取り込まれているところが 64 KB を超えていて 2017 Express では扱えないのだとか。
上記の通り 2017 では Audacity のコンパイルが完了できないため、観念して 2022 Community を導入。インストーラー（Visual Studio Installer）の手順を普通にやったにもかかわらず、なぜか CMake から 2022 Community のコンパイラが正しく認識されない上、2022 の IDE 上からコンソールアプリの新規プロジェクトを選んで Hello World をテストビルドしようとすると「エラー E1696 ソースファイルが開けません」と言われてビルドできない事象に見舞われた（ctype.h とか stdio.h とかの C/C++ 標準ヘッダーが多数）。
CMake のログでは ucrtd.lib が見つからないということだが、そのログに書かれたコンパイル・リンクのコマンドラインを手動で動かすと問題ないという、訳の分からない挙動。
where コマンドでヘッダーやライブラリを探してみたら、なんと、2022 Community と同時導入したはずの最新 SDK 一式が本来 Program Files 配下に配置されるべきところ Program Files (x86) 配下へ入ってしまっていた。これはおそらく、2013 Express や 2017 Express （いずれも 32bit なので x86 配下に入る）が先に存在している状態で 2022 をインストールしたことの弊害なのかもしれない。100%「おま環」な気がするが、しかたがないのでシンボリックリンクを貼って 64bit の 2022 Community からも x86 配下にあるインクルードファイルやライブラリが見えるようにしたら、あっさり解決した。なんでこんなことせなあかんねん💢。
cd "C:\Program Files\Windows Kits\10"mklink /D Include "C:\Program Files (x86)\Windows Kits\10\Include"mklink /D bin "C:\Program Files (x86)\Windows Kits\10\bin"mklink /D Lib "C:\Program Files (x86)\Windows Kits\10\Lib"
この例 でハマった。例えば 300 という文字列のあるウインドウ（エディットボックスとか）に対して GetWindowTextLength() を実行すると、その戻り値は ANSI でも Unicode でも 3 になる。この「文字数」の文字列を格納する先を malloc で確保するときの注意。
- これはダメ…バッファオーバーランする。 GetWindowTextLength() の戻り値も GetWindowText() の第3引数も「文字数」であるのに対して、malloc の引数はあくまで「バイト数」なのです。
LPTSTR strText = (LPTSTR)malloc(GetWindowTextLength(hWnd_foobar) + 2); GetWindowText(hWnd_foobar , strText , GetWindowTextLength(hWnd_foobar) ); …何かの処理… free(strText);
- これなら OK。
LPTSTR strText = (LPTSTR)malloc(sizeof(TCHAR) * (GetWindowTextLength(hWnd_foobar) + 2) ); GetWindowText(hWnd_foobar , strText , GetWindowTextLength(hWnd_foobar) + 2); …何かの処理… free(strText);
- むしろ、「要素数と１要素当たりサイズを明示的に指定」する calloc のほうが、ゼロクリアの時間はかかるにしても、ソースコードの可読性が良いかもしれない。
LPTSTR strText = (LPTSTR)calloc(GetWindowTextLength(hWnd_foobar) + 2, sizeof(TCHAR) ); GetWindowText(hWnd_foobar , strText , GetWindowTextLength(hWnd_foobar) + 2); …何かの処理… free(strText);
0xCD ではない値になってる）があったかどうかを調べたら見つかった」、ということなんだろう。実行中（実際に書き込んでいる間）にはそこまでの監視をするのは流石に無理ということなのかな。
