無謀にも自インスタンスからフォロー。しかしこの子挙動がおかしいの……
そしてプレビューのみで満足していてこれの投稿を完了したのがフォロ返しされた後 (´・ω・`)

ありがとうございます。

単純に

++yoh2;

のつもりでしたのでそこまで深く考えていませんでした。そうかそうい捉え方もあるのか……

理由はminetさんの意見の通りです。
C++の世界には、RAIIの概念を利用した、宣言しかないけど省略してはマズいクラスインスタンスがごろごろしているわけで。
単純なクラスならオプティマイザが効くかもしれませんが、ある程度複雑になるとコンパイラはそういった連中と区別付かなくなるのではないかと思い始めた次第です。
年齢なんていかにもな整数型なら関係ないのですがどうせなら統一していこうかと。

自分のところ(x86とppc)で動けばいいや、というプログラムの場合、アライメントを気にせず読み込んでhtonlなどでバイトオーダー調整なんぞやってたもんで。memcpyすらタイプを面倒がってました。

フリーダムだという保証があるのかフリーダムだと思い込んでいただけなのか、そこが問題なわけで。
ロクに調べないうちに日記を書いたので、もう少し調べてからにした方がよかったかもしれませんが。
といっても 、過去にvoid * と関数へのポインタ の相互変換を認める追加ルール (※) を探しても見付けられなかった程度の調査力なので、きちんと調べても調べ切れるかどうか。

※ C99以降 (それ以前は知らん) では、関数へのポインタは他の関数へのポインタへの変換以外は規定されていないので、追加ルールがないとvoid *との相互変換は未定義。そしてこれが未定義になるとdlsymの存在意義に関わってくるのでどこかで追加ルールを設定しているはず。

しかし、もしアライメントが揃っていないアドレスへのアクセスがダメとの結果が出たら過去に書いたIPヘッダとかISO9660とかのパーサが……
奇数アドレスからの複数バイトフィールドとか、4で割り切れないアドレスからの4バイトフィールドとかあるし。

逆参照した場合の挙動が処理系定義 or 未定義と覚え違いをしていました。ポインタの時点でそうなんですね。
が、同じ 6.3.2.3 Pointers の 5 で

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap reprensentation.

とありますので、char *経由ではなくintptr_t経由ならOKのように思えました。またはポインタ経由でもgccで保証があればいいわけですが未調査です。
※ 「previously specified」は、nullポインタと0についての話 (2で規定) のことだと思います。

また、アライメントについての話は、C11で 6.2.8 Alignment of objects という節が追加されています。
ただ、アライメントのサイズがどうなるかという話のみで、アライメントされていない場合のアクセスはどうなるかまでは書かれていません。
なお、C11で追加された _Alignof の結果は、char: 1、short: 2、int: 4、long: 8、float: 4、double: 8 (gcc-4.7.2, x86_64 -- 4.6.3では_Alignof未サポート) でした。sizeofと一致しますね。

調べるべきことが残っている上に増えてもいますが、とりあえずはここまで。