2022年1月7日金曜日

JNI GetMethodID に指定するタイプ文字列 忘備録

JNI で Java method id を取得する GetMethodID 関数に渡す文字列のドキュメントが見つからないので、忘備録として記す事に

まず、Primitive Type の表

タイプ文字列Primitive Type
V void
Z boolean
B byte
C char
S short
I int
J long
F float
D double


クラスのタイプ文字列は、
 Ljava/lang/String;
というように L で始まり、class URIを書いて ; で閉じる

配列の場合は、
 [I
というように [ で始まり、タイプ文字列を書く
上記の場合 int [] に対応する

関数表記は
()V
([Ljava/lang/String;)I
というように、 ( 引数 ) 返り値 というように表記する
以上

2021年12月27日月曜日

D2メガテンの烙印の失敗がどの程度かモデルで検証してみた。

どうも、あまりにも失敗が目立って酷いので、コードを書いて検証してみることにした。

烙印のステータスアップの成功率 10% に対して40回以上失敗が連続するのは、どの程度で、最高何回ぐらい続くのか?
#include <iostream>
#include <random>
#include <array>
#include <algorithm>
#include <numeric>
#include <vector>

#define TRY_COUNT 10000

using seed_v_t = std::array<std::random_device::result_type, sizeof(std::mt19937)/sizeof(std::random_device::result_type)>;
seed_v_t create_seed_v() {
  std::random_device rnd;
  seed_v_t sed_v;
  std::generate(sed_v.begin(), sed_v.end(), std::ref(rnd));
  return sed_v;
}


std::mt19937 create_random_engine()
{
  const auto sed_v = create_seed_v();
  std::seed_seq seq(sed_v.begin(), sed_v.end());
  return std::mt19937(seq);
}

std::mt19937& random_engine()
{
  static thread_local std::mt19937 engine = create_random_engine();
  return engine;
}

int main() {
  std::mt19937& engine = random_engine();
  std::uniform_int_distribution<int> dist(0, 10);
  std::vector<int> cnts;
  int bingo = 0;
  int cnt = 0;
  for(int i = 0; i < TRY_COUNT; ++i) {
    int val = dist(engine);
    if( val != 0 ) ++cnt;
    else {
      cnts.push_back( cnt );
      cnt = 0;
    }
  }
  int acc = std::accumulate( cnts.begin(), cnts.end(), 0);
  std::cout << std::endl;
  std::cout << "成功回数         = " << cnts.size() << " / " << TRY_COUNT << std::endl;
  std::cout << "平均施行回数     = " << (acc / (double)cnts.size()) << std::endl;
  std::cout << "31回以上連続失敗 = " << std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 30); } ) << std::endl;
  std::cout << "41回以上連続失敗 = " << std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 40); } ) << std::endl;
  std::cout << "51回以上連続失敗 = " << std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 50); } ) << std::endl;
  std::cout << "61回以上連続失敗 = " << std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 60); } ) << std::endl;
  std::cout << "71回以上連続失敗 = " << std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 70); } ) << std::endl;
  std::cout << "最大連続失敗回数 = " << *std::max_element( cnts.begin(), cnts.end() ) << std::endl;
  std::cout << "連続40回以上の失敗に出会う確率 = " << 
    std::count_if( cnts.begin(), cnts.end(), [](int x) { return (x > 40); } ) / (double)cnts.size() * 100.0 << "%" << std::endl;
}

結果は

成功回数         = 922 / 10000
平均施行回数     = 9.83406
31回以上連続失敗 = 50
41回以上連続失敗 = 20
51回以上連続失敗 = 8
61回以上連続失敗 = 3
71回以上連続失敗 = 0
最大連続失敗回数 = 70
連続41回以上の失敗に出会う確率 = 2.1692%

成功回数         = 883 / 10000
平均施行回数     = 10.3001
31回以上連続失敗 = 50
41回以上連続失敗 = 22
51回以上連続失敗 = 7
61回以上連続失敗 = 1
71回以上連続失敗 = 1
最大連続失敗回数 = 81
連続41回以上の失敗に出会う確率 = 2.49151%

成功回数         = 884 / 10000
平均施行回数     = 10.3032
31回以上連続失敗 = 60
41回以上連続失敗 = 27
51回以上連続失敗 = 11
61回以上連続失敗 = 5
71回以上連続失敗 = 2
最大連続失敗回数 = 84
連続41回以上の失敗に出会う確率 = 3.0543%


成功回数         = 881 / 10000
平均施行回数     = 10.3507
31回以上連続失敗 = 55
41回以上連続失敗 = 20
51回以上連続失敗 = 11
61回以上連続失敗 = 4
71回以上連続失敗 = 1
最大連続失敗回数 = 75
連続41回以上の失敗に出会う確率 = 2.27015%

成功回数         = 934 / 10000
平均施行回数     = 9.67024
31回以上連続失敗 = 46
41回以上連続失敗 = 20
51回以上連続失敗 = 5
61回以上連続失敗 = 0
71回以上連続失敗 = 0
最大連続失敗回数 = 57
連続41回以上の失敗に出会う確率 = 2.14133%

成功回数         = 947 / 10000
平均施行回数     = 9.55649
31回以上連続失敗 = 44
41回以上連続失敗 = 21
51回以上連続失敗 = 11
61回以上連続失敗 = 4
71回以上連続失敗 = 0
最大連続失敗回数 = 70
連続41回以上の失敗に出会う確率 = 2.21753%

ひどいケースは無くはないけど、プレイしていると、これよりは頻繁に40回以上連続失敗に遭遇していると思う。
また、思ったよりも連続失敗する事が多いのだなと思った。
しょっちゅう連続失敗でマッカが無くなるので、連続失敗の上限を設けてほしいです。
ユーザは、この仕様にかなりやる気を削がれていると思います

2022/1/10 追記: よくみたら、0-10じゃなくて、0-9で計算しないとあきませんやん。こうやって考えると d2の烙印の実装、バグっぽくありません?

2021年12月25日土曜日

tp-link の無線LANルータに固定IPの機器を接続する忘備録

tp-link の無線LANルータにプリンタをLAN接続しようと思ったら、予想外の仕様で時間と取られたので、その忘備録。
ネットワークの知識がないと、かなり辛い。
プリンタに 192.168.1.253/255.255.255.0 のIPv4アドレスを設定し、無線LANルータとLAN接続したが、通信がうまくいかない。
grayhole:~ user$ ping 192.168.1.253
PING 192.168.1.253 (192.168.1.253): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
まず、下記画面のようにプリンタに設定したIPアドレスが、IPアドレス プールの範囲内に存在しないと、繋がらない変テコ仕様。
このままでは、無線LANルータのDHCPサーバにより、192.168.1.253が他の機器に割り当てられてしまう可能性があるので、上図のアドレス予約に192.168.1.253を追加しなければならない。
次のコマンド(arp -a)を実行します。
grayhole:~ user$ arp -a
...
? (192.168.1.1) at b0:a7:b9:62:9e:e0 on en0 ifscope [ethernet]
? (192.168.1.123) at 0:92:21:33:2d:91 on en0 ifscope [ethernet]
? (192.168.1.132) at a4:5e:32:2f:7f:20 on en0 ifscope [ethernet]
? (192.168.1.221) at 1a:32:ad:33:6e:33 on en0 ifscope permanent [ethernet]
? (192.168.1.253) at 8:0:37:cf:8e:26 on en0 ifscope [ethernet]
? (192.168.1.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
...
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
gr
192.168.1.253 の行に着目し、8:0:37:cf:83:26 がMACアドレスというやつなので、2桁づつの数字 08:00:37:cf:83:26に置き換えて、アドレス予約に追加します。
以上

2021年12月15日水曜日

android darkmode の theme でハマった忘備録

layout.xml において、テキスト色や背景色は、darkmode のテーマに沿って変更されるので問題無いのですが、リストのアイテムが選択された時の挙動をカスタマイズしている所で、罠におちました。
こんなセレクター list_item_color.xml を用意して
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">

  <item android:state_pressed="true"  android:drawable="@color/press" />
  
  <item android:state_checked="true"  android:drawable="@color/check" />

  <item android:state_selected="true" android:drawable="@color/white" />

  <item android:state_focused="true"  android:drawable="@color/red" />
  
  <item android:drawable="@color/black" />
 </selector>
リストアイテムとして foo_list_item.xml
<?xml version="1.0" encoding="utf-8"?>
<com.example.Util.CheckableLinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/list_item_color"
    android:orientation="horizontal" >

    <CheckBox
        android:id="@+id/pnt_check"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_margin="5dp"
        android:paddingRight="5dp"
        android:text="@string/foo_name" />

    <TextView
        android:id="@+id/id_value"
        android:layout_width="0dp"
        android:layout_height="match_parent"
        android:layout_margin="5dp"
        android:layout_weight="1"
        android:gravity="center_vertical"
        android:textAppearance="?android:attr/textAppearanceMedium" />

    <ImageView
        android:id="@+id/detail_button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:layout_margin="5dp"
        android:focusable="false"
        android:src="@drawable/ic_action_right_dark" />

</com.example.Util.CheckableLinearLayout>
としていました。
ところが、リスト項目の背景に list_item_color.xml の item android:drawable の色 @color/black が使用され、
フォント色は何も指定していないけど、CheckableLinearLayout で制御されているためか、@color/black が使用されてしまいました。
これでは、黒背景に黒文字のため、画面が真っ黒で何も見えません。
リストを選択をすると、背景が違う色になるため、かろうじて黒文字が見える状態です。
list_item_color.xml は、テーマの影響を受けません。
よって、背景色は item android:drawable 固定です。よって正解は、
<?xml version="1.0" encoding="utf-8"?>
<com.example.Util.CheckableLinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/list_item_color"
    android:orientation="horizontal" >

    <CheckBox
        android:id="@+id/pnt_check"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_margin="5dp"
        android:paddingRight="5dp"
        android:buttonTint="@color/white"
        android:textColor="@color/white"
        android:text="@string/foo_name" />

    <TextView
        android:id="@+id/id_value"
        android:layout_width="0dp"
        android:layout_height="match_parent"
        android:layout_margin="5dp"
        android:layout_weight="1"
        android:gravity="center_vertical"
        android:textColor="@color/white"
        android:textAppearance="?android:attr/textAppearanceMedium" />

    <ImageView
        android:id="@+id/detail_button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:layout_margin="5dp"
        android:focusable="false"
        android:src="@drawable/ic_action_right" />
    <!--
        _theme を指定すべきではない。
        android:src="@drawable/ic_action_right_dark" />
-->

</com.example.Util.CheckableLinearLayout>
と、チェックボックスの色と、テキスト色を固定で指定する事でした。
また、@drawable/ic_action_right_dark は darkmode の色なので、_dark を除いた @drawable/ic_action_right にすべきでした。
ただし、ここでは背景色が黒固定なので @color/white を指定すべきかもしれません。

2021年12月6日月曜日

WixFirewallExtension 忘備録

Windows Install Wix で Firewall を追加しようとした時に、いろいろ躓いたので忘備録

コマンドラインからでも、以下のようにすればFirewallを制御できるので
netsh advfirewall firewall add rule name="test" dir="in" action="allow" program="c:\Proguram Files\Foo\x.exe" description="test description" enable="yes" profile="any"
カスタム・アクションを定義してやれば、要件はクリアしそうである。
<CustomAction Id="CA_01_BYPASSFIREWALL" ExeCommand='netsh advfirewall firewall add ...' Directory="Foo" Execute="deferred" Impersonate="no" Return="check" />
<CustomAction Id="CA_02_REMOVEFIREWALL" ExeCommand='netsh advfirewall firewall del ...' Directory="Foo" Execute="deferred" Impersonate="no" Return="check" />
<InstallExecuteSequence>
  <Custom Action="CA_02_REMOVEFIREWALL" Before="InstallFinalize">REMOVE="ALL"</Custom>
  <Custom Action="CA_01_BYPASSFIREWALL" Before="InstallFinalize">not (REMOVE="ALL")</Custom>
</InstallExecuteSequence>
上記は試してません

WixFirewallExtension を使用すると、ファイヤーウォールを制御できます。
プロジェクトのソリューション・エクスプローラのReferencesを右クリックして、「参照の追加」を選択し、Program Files\Wix Toolset v3.11\bin\WixFirewallExtension.dll を追加します。
Product.wxsに FirewallExtension の namespace を追加します。
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:fw="http://schemas.microsoft.com/wix/FirewallExtension">
x64 のコンポーネントだと FirewallExtension が x86 コンポーネントのため、怒られてしまいます。
そのため、x86 のプログラム・フォルダにFirewallのコンポーネントを追加します。
      <Directory Id="ProgramFilesFolder" Name="ProgramFiles86Folder">
        <!-- Firewall -->
        <Component Id="grpcFirewallException" Guid="2B6866D0-0F1F-4579-84A7-87CDE9F57640" KeyPath="yes">
          <fw:FirewallException Id="anyFirewallException" Program="[INSTALLFOLDER]x.exe" Description="BYPASS:x.exe network port" Name="Foo Firewall Exception" Scope="any" />
        </Component>
      </Directory>
      
      
      ...
      <Fragment>
        <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
          ...
          <ComponentRef Id="anyFirewallException"/>
        </ComponentGroup>
      </Fragment>
としてやればOKです。

2021年10月6日水曜日

go で grpc の proto ファイルから生成されたソースをローカル利用する 備忘録

ウィンドウズ環境にて grpc の protoc から go のソースを生成してビルドするまでに、えらいハマったので、その備忘録。
まず、grpc の go チュートリアルを読みましたが、唐突に source_relative という未定義の単語が出てきたり、キーワードが、どこの項目と連動しているのか理解できなくて、ちんぷんかんぷんでした。また、生成されたパッケージを利用する方法がわからず、エラー頻出で、体力消耗しました。普段からgoに親しんでいる人にとっては簡単な事なんでしょうけど、普段goを使わない自分には的確な情報にたどり着く手段が少なくて、正解にたどり着くまでに3日ほど浪費しました。
以下のディレクトリ構成で作業をしている前提で話を進めます。
C:/Projects/Hello/
         bin/                           ... インストールで追加される exe のディレクトリ
         pkg/                           ... 追加されたパッケージのディレクトリ
         proto/hello.proto              ... proto 定義
         my.hello/hello.proto           ... proto 定義(仕様変更により自動生成されるのと同じ場所に置く必要あり)
         my.hello/hello.pb.go           ... 自動生成される proto の go ソース
         my.hello/hello_grpc.pb.go   ... 自動生成される grpc の go ソース
         client.go                      ... クライアント・アプリケーションの go ソース
         go.mod                         ...  go mod init で生成される go.mod ファイル
         go.sum                         ...  go mod init で生成される go.sum ファイル
         goenv.bat           ... go を使うための環境設定バッチファイル

参考として goenv.bat の中身
@echo off
set GOROOT=D:\go
echo 'set GO install directory : %GOROOT%'

rem 
rem GOPATH は非推奨なので使用しません
rem 
rem set GOPATH=D:\somewhere
rem echo 'set Build directory : %GOPATH%'

rem
rem とりあえず、x86 をターゲットとします
rem 
echo 'set GOARCH win32 application'
set GOARCH=386

echo 'set GOARCH : %GOARCH%'

rem
rem プロキシーを利用している環境では、プロキシーを設定する必要があります
rem
rem set http_proxy=192.168.0.254:8080
rem set https_proxy=%http_proxy%

rem echo 'set proxy settings : %http_proxy%'

rem 
rem vcpkg により、protobuf をインストールしているため、そちらを流用しています
rem   d:\vcpkg\installed\x64-windows\tools\protobuf 
rem  が、それに該当します。この下に protoc.exe が配置されています。
rem 
set path=%PATH%;%GOROOT%\bin;d:\vcpkg\installed\x64-windows\tools\protobuf

さて、コマンド・プロンプトで、
C:/Projects/Hello ディレクトリ下に移動して作業を行います。
最初に go mod init コマンドを実行し、go.mod ファイルを生成します
C:\Projects\Hello> go mod init test-client
test-client.exe を作成する下地の準備ができました。
次に必要なgrpcのパッケージ類をインストールします
C:\Projects\Hello> go get -u -v google.golang.org/grpc
C:\Projects\Hello> go get -u -v google.golang.org/protobuf/proto
C:\Projects\Hello> go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
C:\Projects\Hello> go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

C:\Projects\Hello\bin 下に protoc-gen-go.exe, protoc-gen-go-grpc.exe が展開されているので
環境変数 PATH に上記 exe が存在するディレクトリを追加します。
C:\Projects\Hello\bin\windows_386 下に exe が展開されていた場合の PATH の追加例は下記
C:\Projects\Hello> set PATH=%PATH%;C:\Projects\Hello\bin\windows_386
パスの追加を怠ると、protoc コマンド実行時に原因不明のエラーに悩まされます。
*.proto の書き方が悪いのか、protoc-gen-go.exe が見つからない事によるエラーなのか
切り分けが容易ではなくなるので、必ず PATH を設定しましょう。

補足:現在は非推奨であるが、GOPATH=c:\gopub というように GOPATHを指定していた場合には
C:\gopub\bin 下に protoc-gen-go.exe, protoc-gen-go-grpc.exe が展開されているかもしれません。
グローバルにインストールした場合は、もしかしたら、%USERPROFILE%\go\bin ディレクトリ下に展開されているかもしれません。
GOPATHが書き込み禁止の Program Files ディレクトリだった場合も、%USERPROFILE%\go\bin に展開されると思われます。

C:\Projects\Hello\proto\hello.proto から
C:\Projects\Hello\ のディレクトリ下に hello_grpc.pb.go 等のソースを展開したいので
下記コマンドを実行します。

仕様が変更されました。
option go_package="[パッケージのパス];[パッケージ名]"
とした上で、proto ファイルは、パッケージのパスに置く事が必須となりました。
option go_package="my.hello;my_hello" と指定した上で
下記コマンドを実行します。
仕様が変更されていました。hello_grpc.pb.go は、hello.pb.go を含まなくなりました。
なので、2つ出力する必要があります。
C:\Projects\Hello> protoc --go-grpc_out=./ my.hello/hello.proto
C:\Projects\Hello> protoc --go_out=./ my.hello/hello.proto

参考として hello.proto の一部抜粋を記載します
syntax = "proto3";

option java_multiple_files = true;
option java_package = "my.hello";
option java_outer_classname = "Hello";

// 仕様が変更されたので設定に注意!
option go_package="my.hello;my_hello";

package hello;

service Hello {

  rpc SayHello (SendRequest) returns (SendResponse) {}

}

message SendRequest {
  string msg = 1;
}
  
message SendResponse {
  string msg = 1;
}
そうすると、
C:\Projects\Hello\my.hello というディレクトリ[パッケージのパス]下に
hello.pb.go ([protoの拡張子を抜いたファイル名].pb.go) というソースが生成されます。

更に仕様が変更されて、下記は解消されました。
仕様変更により下記は、どうなったか知りません
参考として、下記コマンドを実行すると hello.grpc.pb.go も生成されます

C:\Projects\Hello> protoc --go_out=plugins=grpc:./ --go-grpc_out=./ proto/hello.proto

しかしながら、hello.grpc.pb.go で定義されている内容は hello.pb.go に定義されているため
hello.grpc.pb.go を出力してしまうと、再定義のエラーが発生します。
従って、こちらは出力しません。
C++のソースを生成する場合は、対応する両方のファイルが必要だったので、言語間でインターフェイスの統一が取れていないと感じました。


出力されたパッケージをローカルパッケージとして利用するために下記コマンドを実行する必要があります。
C:\Projects\Hello> go mod edit --require my.hello@v0.0.0-local --replace my.hello@v0.0.0-local=./my.hello
コマンド中の v0.0.0 はバージョン情報です。公開して管理するわけではないので、version 0.0.0 の指定をしています。
コマンド中の -local は、ローカルパッケージだよというオマジナイです。
コマンド中で指定するパッケージ名は、あくまで protoファイル中で指定した option go_package="my.hello" を指定します。
go のソースに展開された時にパッケージ名が my_hello へ変更されていたとしても、元の名前を指定します。

このコマンドを実行すると、go.mod ファイルへ
   require () 節中に my.hello v0.0.0-local の行が追加され、
   replace () 節中に my.hello v0.0.0-local => ./my.hello の行が追加されます。
これにより、my.hello が外部モジュールから、ローカルの ./my.hello ディレクトリへとマッピング検索されるようになります。

仕様が変更されました
go ソース内での go_package は、proto ファイルで "my.hello" を指定していますが
"my_hello" という . を _ に置換した名前に変換される仕様となっています。
尚、proto ファイルで指定した package の名前は、go では利用されません。

これでようやく、client.go ファイルに
 import (
   myhello "my.hello"
 )
と書いて、インポートが可能になります。
名前が紛らわしいので、import 時にエイリアス指定("myhello")しておきましょう。パッケージ名に振り回されなくて済みます。
風が吹いたから、雨が降ったから、というような理由で、仕様がコロコロと変更されます。エイリアス指定しておくのが吉だと思います。
大事なことだから、もう一度書きます。
風が吹いたから、雨が降ったから、というような理由で、仕様がコロコロと変更されます。エイリアス指定しておくのが吉だと思います。

go build するのには、もう一手間が必要です。
C:\Projects\Hello> cd my.hello
C:\Projects\Hello\my.hello> go mod init my_hello
C:\Projects\Hello\my.hello> go mod tidy
C:\Projects\Hello\my.hello> cd ..
これで、protoc から生成された go パッケージが利用できるようになり、go build が可能になりました。

整理すると import myhello "my.hello" は、
   go.mod の require の my.hello v0.0.0-local で参照され、
   go.mod の replace 指定によりローカルの ./my.hello に置き換えられ
   ローカルディレクトリ ./my.hello のソース my_hello パッケージが読み込まれ、
   my_hello を myhello というエイリアスにより参照する事ができる、
という流れになります。

疲れた。ほんとに疲れた。

2021/12/07 追記:書いたとたんに仕様がどんどん変わっていく。疲れる。ほんとに疲れる。コンパイルする毎に仕様が変わっていてコンパイルできる状態にもっていくのに、時間を取られる。素晴らしいツールには違いないが、毎回コンパイルできる状態にもっていくのに時間的リソースの消費を余儀なくされるため、生産性の高いツールという位置づけから生産性の低いツールというレッテルを貼りたくなる。ツールを書いているやつは、「API design for C++」を読めや!!!!と、ぼやきたくなる。
Read "API design for C++"
please!
コマンド実行したら、android studio の gradle コマンド同様に、オプション変更の予告があります。そのうち、この内容も変更される事でしょう。
2021/12/08 追記: なんか、修正に次ぐ修正に次ぐ修正で、書いてる事の整合性が崩れてる…。もう疲れたので、お家帰りたい

2021年9月22日水曜日

enable_shared_from_this と継承 忘備録

マルチスレッド・プログラミングで、継承されたオブジェクトの破棄タイミングが難しく、enable_shared_from_this を使う事にした。 ただ、共通インタフェイスを持たせたくて継承させたので、素のままの enable_shared_from_this では不味そうなので、正しく動作させるための用法を忘備録として書き留める事にした。
#include <iostream>
#include <cassert>
#include <memory>

class Base : public std::enable_shared_from_this<Base> {
protected:

  template <typename T>
  std::shared_ptr<T> shared_from(T* derived) {
    assert(this == derived);
    return std::static_pointer_cast<T>(shared_from_this());
  }

  int n_;
public:
  Base(int n) : n_(n) { std::cout << "Base()" << std::endl; }
  virtual ~Base() { std::cout << "~Base(" << n_ << ")" << std::endl; }
};

class Delived : public Base {
public:

  auto shared_from_this() { return shared_from(this); }


  Delived(int m) : Base(m) {
    std::cout << "Delived()" << std::endl;
  }
  
  virtual ~Delived() {
    std::cout << "~Delived()" << std::endl;
  }

};


void main() {

  std::shared_ptr<Base> test1;
  {
  {
    auto pbase = std::make_shared<Base>(1);
    auto pderived = std::make_shared<Delived>(2);

    test1 = pbase->shared_from_this();
    std::shared_ptr<Delived> test2 = pderived->shared_from_this();
  }
  std::cout << "end" << std::endl;
  }

}
実行すると
Base()     // pbase のコンストラクタ
Base()          // pderived の Base コンストラクタ
Delived()       // pderived のコンストラクタ
~Delived()      // スコープを抜けて test2が破棄され pbaseの参照カウントが0になり破棄
~Base(2)
end             // スコープを抜ける
~Base(1)        // test1が破棄され pderivedの参照カウントが0になり破棄