今日の五条川。
夏にヒマワリ畑だった大口某所がコスモス畑になっていました。
大量の秋桜と秋の五条川桜並木、狙ったような洒落ができる。
カメラ女子も沢山、一眼で花を撮っている女性ってなんかいいですね。
いや若い娘も定番だったオリンパスペンの人もいないけど。
よしよし今回もセイヨウミツバチがきてくれた。
欲を言えば日本ミツバチが来て欲しいけどここらにいない。
さて花はこれくらいにして。
その近くではカワラヒワの群が住み着いているようで。
ってなんか一匹だけ違うのがいるぞ。
あれ？どう見てもジョウビタキのメスなんですけど。
もう来ているのか、あぁ冬が来るって感じ。
以下画質は悪いけど。
ハクセキレイ、いつもはスルーするけど。
セグロセキレイ、ほぼ同じ所にってあれ？
キセキレイまで、おまえら縄張り争いしないのか！
ついでみカワセミ、川底にいるのって目面しい。
てかおまえ歩けたのか、初めて歩いているのを見た。
以上ほぼ同じ場所で、こんなこともあるんだなって。
もうしばらく夜勤が決まる、変則勤務は頭が回らないね。
プログラミング関係は連休までおやすみ。
日曜日にいつもの五条川でパナライカを背負って野鳥探し。
で、大口のメガドンキユニー（長い）近くにある向日葵畑が目についた。
多分だけど、一度帰宅してデジイチを持って再訪したみたいな人達がワンサカ。
その時筆者は LUMIX G 25mm も持っていた、ということで撮影会に参加。
あれ？なんか違う。
彼岸花の時もそうだった、実物は凄く綺麗なのに写真にするとつまらない。
42.5mm も持ってきたほうが良かった？いやココはもっと広角で撮りたいかも？？
もしかして 25mm も割高みたいなパナライカを選んでいたら迷わなかった、かも。
迷ったけど早々に野鳥探しへ戻る、何もいなかったけど。
リベンジしたいけどなんか我が LUMIX では綺麗に撮れる気がしない。
そうだ NIKON を使おう、たまにはコッチも使ってやらないと。
ということで夜勤明けに D3400 を持ってリベンジしてみた。
うんなんかシックリきた、キットズームの広角端なのにイイ感じ。
4:3 ではなく 3:2 だからなのか、絵作りの差なのか。
野鳥は断然 LUMIX なんだけど、それはレンズの差だし。
単焦点も NIKON のほうがやっぱりイイな。
APS-C の入門レンズでこんだけ撮れれば十分ですよ。
クマバチがいたので f2.2 まで開けてコラボを。
背景はボカしすぎたかなって感じだけど悪く無いかも。
てかハチが逃げる前に撮らなきゃなので絞りを選んでいる暇無い。
マジで思う、カメラも信者にならず色々使ってみたほうがいいな。
さて出勤の準備でもするか。
今回はトリミング無し。
-scaled を URL から外すとフルサイズ画像になります。
今日の大口町。
ヒバリさん、ストーップストップひばり君（古い）
高く飛んでピーチクパーチクするのは威嚇だと思っていた。
アレ求愛だったのね、鳥の世界はよくワカラン。
カワセミ君、ひっさしぶり。
いやココ水を張った田んぼだよ、魚いないよ？
調べたらカエルやザリガニも食うのか、へー知らなんだ。
キジの夫婦、ちょっとブレた。
てかここらにマジでいるんだな、初めて見つけたよ。
こんなにデカくて目立つビジュアルなのにね。
ここ最近休日は小牧山に行っていたんだけど。
コマドリ等のさえずりは聴こえるけど姿は見えず。。。。。
が続いていたのでキジ発見は嬉しい。
unary_function は C++11 から非推奨だったのね。
functional – cpprefjp C++日本語リファレンス
std::cout を覚えただけで C++ を簡単みたく書く初心者ブログが多いよね。
筆者の Tips ページはそいつらが見たら絶望するように STL を使っていたり。
なのでワケワカメの代表 unary_function が使えないのは困ったなぁ。
と思ったけどコメントアウトしただけで動くじゃん。
それと auto で便利になったとかも見かける。
いや、class で this を戻すのに auto 指定できるレベルでないとそれほど。
…できるジャン！
// stl.cc
#include <iostream>
#include <vector>
#include <algorithm>
/**
* Fedora 33
* g++ stl.cc
*
* macOS Big Sur
* clang++ -std=c++14 stl.cc
*/
/*
* みんな大好き C++ のテンプレート
* C++11 より unary_function は非推奨
* なんだけど、継承する必要が無くなっただけだったり
*/
template <class T>
struct outputfunc { // : public std::unary_function<T, void> {
void operator()(T obj) {
std::cout << obj << " ♪♪♪ ";
}
};
class App {
public:
App() {
std::vector<std::string> vec = {"SUZUKIの", "バイクは", "カッコイイ"};
// 関数オブジェクトにしたけど今は範囲ベース for のほうがいい
std::for_each(vec.begin(), vec.end(), outputfunc<std::string>());
}
~App() {
std::cout << std::endl << "今日も元気でね！" << std::endl;
}
static auto init() {
// auto で this を戻せる
return new App();
}
};
int
main(int argc, char* argv[]) {
// イヂワルな初期化
auto app = App::init();
delete app;
return 0;
}
macOS ではオプションが必要なのね、c++17 指定でもいい。
for も Python と同じようにできるし、使わない間に随分進化していた。
後は :: と -> が全部ドットになれば、って今更無理だろうな。
たまにしか C++ を触らないとどうしてもソコがね。
C 言語って C99 の後に C11 というのがあるんだね。
gets を排除なんてどのコンパイラもやらないだろうな。
gets_s なんて Clang も gcc も使えないぞ、cc.exe ただ一つじゃねーの？
しかし gets で検索するとみんな色々書いているけど。。。
GNU Readline ってそんなに無名なんだろうか？
標準入力では一番の選択肢だと思うんだけど、まあ人それぞれ。
char16_t と char32_t 型か、今までどおり wchar_t で問題ないような。
UTF-16 と UTF-32(UCS-4) が混在する場合なんてありえる？
てか
#include <uchar.h>
が macOS では CLang でも gcc でもエラーなんだけど？
macos – OS Xでuchar.hが見つからない – スタック・オーバーフロー
古い質問だけど今もそうなの？
Fedora の gcc だと普通にコンパイルできるんですけど。
U の接頭子ならイケたのでそっちでやってみる。
#include <stdio.h>
int main (int argc, char const* argv[]) {
printf("wchar size: %lu byte\n", sizeof(L'a'));
printf("UTF-32(UCS-4) size: %lu byte\n", sizeof(U'a'));
return 0;
}
うん、Fedora の gcc も macOS の Clang もオプション無しでイケる。
全部 UTF-32 なのよね、NSString が UTF-16 なのが少し困る。
あっ混在あった、ってそれ相互利用なんてしないと思うけど。