C++ の ORM を物色中。
bun
ソースコード:GitHub
メモ:boost と SOCI というのが必要。
bun 自体は Mac で動かすには修正が必要。それよか SOCI はなかなか良いプロジェクト。

ウマ娘関連のネタが多いでしょうか
C++ の ORM を物色中。
ソースコード:GitHub
メモ:boost と SOCI というのが必要。
bun 自体は Mac で動かすには修正が必要。それよか SOCI はなかなか良いプロジェクト。
今回は @autoreleasepool の話。
と言っても、私はこれに関して大して詳しくない。
『オートリリースプールの使い方と基本』という素晴らしくよくまとまった記事があるので、そちらを参照してください。
オートリリースプールは通常、裏で自動的に生成・破棄されているので、基本的には意識しないで autorelease が利用できるようになっています。
ただし、無造作に独立して動いている訳ではないので、処理を長くキープし続けるような場面では、意図的にオートリリースプールを解放してあげないと、解放待ちのインスタンスでメモリが溢れてしまう危険性があります。
という解説の後に、以下のようなサンプルコードが提示されている。
// 長いループの中でオートリリースプールを生成することで、解放待ちのインスタンスが溜まってしまうのを防ぎます。
while (!isCancelled)
{
@autoreleasepool
{
// この中で生成された autorelease なインスタンスは…
self.label.text = [NSString stringWithFormat:@"Step: %d", self.step];
}
// 次のループ処理に入る前に release されます。
}
Xcode で Objective-C のプロジェクトを生成されると、もれなく

と @autoreleasepool{} がついてくるが、なるほど、こういう理屈だったわけですか。
プログラミング言語の復習などは、文法などから入るのが自然なのだろうが、少々ダルいので、JakartaEE の時と同様、データベース – ORM に手をつける。
Objective-C (Swift でもそうだが)の ORM といえば、coreData なのだが、ここでも GUI は使わずにコマンドラインから扱う。(GUI での使用例はこちら)
なお、「なんで、GUI を使わないで、コマンドラインのサンプルで済ませるんですか?」とリアルでも訊かれることがあるが、たぶん、育った環境w
それに加えて swift を勉強していた時に、コマンドラインのサンプルのみからなる教科書を使ったんだが、これがけっこう効果的だったから、という個人的な体験。
それで、いきなりだが、完成されたコードを示す。
少々、古い書き方だが、動くことは動く。
NSPersistenceContainer を使いたい方は頑張って書き直してください。
#import <Foundation/Foundation.h>
#import <CoreData/CoreData.h>
#import "Person+CoreDataClass.h"
/*
以下の定義は不要だが、念のため.
というか、あると Person が二つあることになるのでエラー出ます。
@interface Person : NSObject {
NSString *name;
}
@property(nonatomic)NSString *name;
@end
// Person クラスの実装
@implementation Person : NSObject
@synthesize name;
@end
*/
int main(int argc, const char * argv[]) {
NSString *modelPath = [[NSBundle mainBundle] pathForResource:@"Model"ofType:@"momd"];
NSURL *modelURL = [NSURL fileURLWithPath:modelPath];
NSManagedObjectModel *managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];
NSArray* paths = NSSearchPathForDirectoriesInDomains(
NSDocumentDirectory, NSUserDomainMask, YES);
NSString* dir = [paths objectAtIndex:0];
NSString* dbPath = [dir stringByAppendingPathComponent:@"sqlite.db"];
NSURL *url = [NSURL fileURLWithPath:dbPath];
NSError *error = nil;
NSPersistentStoreCoordinator* coordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:managedObjectModel];
if (![coordinator
addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:url
options:nil
error:&error]) {
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
abort();
}
NSManagedObjectContext *managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[managedObjectContext setPersistentStoreCoordinator:coordinator];
Person *person = [NSEntityDescription insertNewObjectForEntityForName:@"Person"
inManagedObjectContext:managedObjectContext];
person.name = @"akiba";
NSError* error2 =nil;
[managedObjectContext save:&error2];
return 0;
}
何としてもワンファイルで済ませたかったが、流石に coreData だとそうもいかない。
多分、ネットを彷徨してこの記事に辿り着いた人ならわかると思うが、coreData を使う場合は、「モデルからコードを生成する」という操作がどうしても必要だから。
なお、後述する Xcode 上での操作を完了させ、ビルドすると「書類」フォルダ直下に以下のようなデータベースが作成される。

しっかり永続化されてますね。
3レコードあるのは、3回ランさせたからw
なお、カラムはすべて Z から始まってますが、この接頭子が付く理由は誰もわかってません。
このソースコードの解説もしたいところなのだが、まずは動かすための手順を説明していく。
基本的に
モデルの作成→コードの生成
と進む。
プロジェクト作成時に use coreData にチェックを入れておけば、モデルを記述するファイルは自動でできるのだが、コマンドラインを選んだ場合は、このオプションは選べないので、自分で追加する。
適当なグループでファイルを追加。

上の画面で coreData -> Data Model を選ぶ。
すると選んだグループなどに Model.xcdatamodeled が追加されるので、次はこれを編集。

Entity がテーブル、attribute がカラムになるので、これを意識して .xcmodeled ファイルを編集。
最初はテーブル一つ、カラム一つから始めるといいと思う。
もちろん、複数のテーブルを作成、カラム同士を One To や Many To などで結びつけるという ORM らしい使い方もできるのだが、ここでやってしまうと混乱するだけなのでここではスキップ。
なお、以前の Xcode には、関係性(relationship)をグラフィカルに表示する機能もあったのだが、現在では無くなっているようだ。
モデルが定義できたので、次はモデルを使ってコードを生成する。
menu -> editor -> Create NSManagedObject Subclasses…
を選ぶ。
なお、この時、画面右の生成する言語で swift か obj-c かを指定する。

デフォだと swift が指定されているので、obj-c の時はもちろん Objective-C で。
すると一つの entity に対し4ファイルが生成される。
Person という entity があった場合は
Person+coreDataClass.h
Person+coreDataClass.m
Person+coreDataProperties.h
Person+coreDataProperties.h
の4つ。
+がなんとも特徴的。
このファイルの生成も3通りのやり方がある(Xcode14 では、一つしかないです)のだが、エンティティ一つ程度であれば、深く検討する必要はないでしょう。とりあえず生成して、ビルド時に微調整でいいと思います。
操作的には以上で完了です。
単純に save しているだけなので、一回走らせるたびに、sqlite.db に name = “akiba” のレコードが追加されていきます。
初学者がまず気にしておく点は、永続化すべきクラスは NSObject を継承しているのではなく、NSManagedObject を継承している点。
だから、インスタンスを生成するときも
Person *person = [[Person alooc] init];
とするのではなく
Person *person = [NSEntityDescription insertNewObjectForEntityForName:@"Person"
inManagedObjectContext:managedObjectContext];
とします。
また、通常のオブジェクトとは違っているので、データベース操作時には
NSManagedObjectContext
や
NSPersistentStoreCoordinator
の実体(オブジェクト)が必要という理屈です。
ところで、「coreData objective-c」あたりで検索をかけるとこんな記事がかなり上位にヒットしますが、初学者でこの記事読んで coreData を実際に使えるようになるかというと難しいんではないでしょうか。
記事自体が悪いということではなくて、それだけ情報が少ないってことです。
Xcode14 上で上記の手順でビルドしてもエラーが出るようです。
Multiple commands produce...
という。
はて?
上の場合は、main.m 以外をコンパイル対象から取り除けば、エラーは消えるんですが、なんか気持ち悪いですね。
今回は、「とりあえず CoreData を使う」ということに主眼を置いたが、使い込むとなると、例えば、検索条件をもっと詳細に設定したいという要求が出てくると思う。
検索設定に使う。
『CoreData を用いてデータ管理を行う』初学者向け
『NSPredicate 全構文解説』マニアック
などなど。
ただの忘備録的な日記です。
数年愛用していた I/O データのルーターが逝ったため、とりあえず最寄りの家電量販店で同メーカーのミッドゾーン?くらいのルーターを購入。
しかし、これが。。。
業務的な案件は別にして、LAN 内の特定のマシンの IP を固定して使いたい場合、DHCP 固定割当という機能を使うのが一番楽だと思う。
私は(少なくとも自宅では)ずっとこのやり方で通してきたのだが、購入した I/Oデータの WiFi ルータに搭載されていなかった。
いや、でも、これだとネットワークプリンタの類にデータ送れなくないか?
解せぬ。
逆にエレコムのものは全ての機種に搭載されていた。
結局、交換してもらった。
値段は少々落ちたので、通信の安定性などに影響出るかと思ったが、エレコムの方がめちゃくちゃ安定している。
I/O データ、バッファロー、エレコムあたりの企業がどういう基準で競争しているのかわからんが、これだけ品質に差があるともう今後しばらくは I/O データの製品は買えない。
今年のカプ杯は、中京芝1200m 。
高松宮記念モチーフの久々の短距離チャンミとなった。
結果を先に書いておくと、サークルの主要なメンバーは全員グレード A の決勝進出。
サークルのメンバーのほとんどが社会人で構成され、育成もそんなに頑張ったわけではないのに(なにしろ時間がない)、これは凄いんでないかい?
特に、ゲーム関係のチャット部屋で盛り上がっていたのは、某氏の育成した差バンブーメモリー。
今回のチャンミは、迫る影(直線一気)が加速スキルとしてかなり有効とみられていたため、脚質的には
先行>追い込み>逃げ>>>>差し
とされていた。
だから、後方脚質勢は、追い込み運用が多かったと思う。
バンブー自体もたまに遭遇したが、ほとんどが追い込みだったと記憶している。
なんで、差で、しかもさほど強キャラとはされていないバンブーで勝率いいのかみんな不思議に思い、かつ驚愕していたわけだ。
では、なぜ差バンブーで勝てていたのか?
この観点からトレーナーさんの発言をまとめる。
バンブー自体は、正月ガチャでお迎えできた時から、コミカルな感じに好感を持っていた。
試しに育成すると意外に固有が出やすい。
エースはドロワーフジキセキに決めていたが、その直前にたまたま賢さネイチャを完凸にできたので、これを活かして差を1個体は育成しようと考えていた。
バンブーは魔改造しなくても短距離走れるので、キャラ選択はさほど迷わなかった。
ただし、初期に育成した個体は弱かった。
強行策積んだ追い込みに中盤では追い越されていた。
固有スキルはそこそこは強いが、スピードがノッた追い込みを差し返せるほどではない。
そこで、中盤位置あげスキルを意識して取るようにした。
位置取り押し上げは有効だが、これだけだと弱いので、正月サトノダイヤモンド固有を必ず継承させた。
あとは試行回数。
他の2個体はほとんど育成も考えず、開催期間中もほぼバンブーだけ育成した。
この育成方針は参考になるところがいくつもある。
短距離だったとはいえ、ようつべやツィあたりで言われている常識的な育成方法が絶対ではないことをよく表している。
決勝でもこのトレーナー、あっといわせるレース展開に持ち込んだんだが、動画あげてくれないかな?
Mac での ORM といったら coreData だが、obj-c のコマンドラインアプリプロジェクトで coreData を使おうとするとなぜか swift のファイルが生成されてしまう。
ここは勘違い。codegen するとき、以下の箇所で objective-C を指定する。

前回の記事が評判良かったので、続編。
そのとき提示したサンプルコードは、実は、もうちょっと obj-c っぽく書ける。
以下のようになる。
#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>
#import <stdio.h>
// Person クラスの宣言
@interface Person : NSObject
@property(nonatomic)NSString *name;//ここが変わった!
- (void)printName;
@end
// Person クラスの実装
@implementation Person : NSObject
- (void)printName {
printf("My name is %s \n", [_name UTF8String]);//_ がついていることに注意
}
@end
// 実行プログラム
int main(void) {
id person;
person = [[Person alloc] init];
[person setName:@"akiba"];
[person printName];
return 0;
}
一見して気がつくのは、@property なるディレクティブが出現していることだろう。
そのかわり setName というメソッドが消えた。
想像つくかと思うが、フィールド変数のセッター&ゲッター定義は @property で代用がきく。
なお、nonatomic はスレッドセーフでは「ない」ことを明示するオプション。こんなところでスレッドセーフにしても意味がないので、明示した。(指定しないと atomic になる)
また、@property で生成されるフィールド変数 は先頭に _ がつく。
ここまでくると、何とも obj-c っぽい。
逆に、ここら辺を理解せずに obj-c のコードを読むと、「なんだ、これ?」になると思う。
ところで、アクセサ(セッター・ゲッター)によるカプセル化はオブジェクト指向言語の特徴の一つだろうが、obj-c ではここでもまたディレクティブで対応する方法をとっている。
ここまで徹底しているとなんか清々しいですね(笑)。