Programming」カテゴリーアーカイブ

Clang++ がヘッダを参照できない件

2025.05 現在、Clang++ が iostream を見つけられない。
iostream だけではなく C++ 標準ヘッダが参照できないようで。

まあバグだろうからすぐ修正されるだろう。
で、先日 CommandLineTools の更新通知がきた。
これで修正されて、って同じヤン。

15.4 から 15.5 にアップデートされてはいる。
小数点の無い MacOSX15.sdk は小数点付きへのリンクなのか。
アップデートに追従するみたいだから今後はこっち指定に。

ちなみにルートを Finder で開くには、端末を起動して。

open /

でイケます、GNOME の Linux なら gio open / ですね。
別にホームから command+up してもいいですけど、脱線でした。

そんなこんなで、ビルド毎に -I オプションなんてメンドイぞ。
なのでエイリアスを作ることに、修正されたら消せばいいだけだ。
~/.zshrc を開いて、作ってない人は作成して。

alias clang2="clang++ -I /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/c++/v1"

名前は各自適当に、筆者は clang2 にしました。

普通にビルドできるようになりました。
ヘッダの場所は環境によって違うかもなので各自調べてね。

ついでに、clang 17 や gcc 15 は C++23 もいくつか対応なのね。

#include <print>

/**
 * clang2 -std=c++23 cc23.cpp
 * g++ -std=c++23 cc23.cpp
 */

int main (int argc, char const* argv[]) {
    /**
     * println なら改行付き、いらないなら print
     */
    std::println("最高な{0}は{1}です", "カメラレンズ", "パナライカ");
    return 0;
}

Java と C# のいいとこどりみたいなことしやがって。
でも思うんだ、名前空間の区切りはドットでよくね?

コンパイラの実装状況 – cpprefjp C++日本語リファレンス

凄いサイトがあるもんだ。

C/C++ auto

gcc や Clang でのビルド方法ページを作っている筆者ですが。
ちょっと、いや数年サボっていたら C 23 や C++ 20 が出ていた。
流石に情報が古いので書き換えしようかと、てか調べないと。

C23 (C言語) – Wikipedia

ついに C 言語にも auto キーワードが、今頃知った。
いや C++ の柔軟な奴と違って変数宣言にしか使えないっぽい。
やってみないと断言できないので少し使ってみる。

#include <stdio.h>
#include <stdlib.h> // free
#include <string.h> // strdup

/**
 * gcc -std=c23 c23.c
 * clang -std=c23 c23.c
 */
int calc(int n) {
    return n * n;
}

int
main (int argc, char *argv[]) {
  
    // 静的文字列はイケる
    auto om = "OLYMPUS"  " " "Workspace";
    printf ("%s\n", om);
    // ポインタもイケる
    auto heap = strdup("おならプー");
    printf ("%s\n", heap);
    free(heap);
    // 計算値もイケる
    auto num = 3*5;
    printf ("%d\n", num);
    // 再代入も普通に可能
    num = 30;
    printf ("%d\n", num);
    // 関数の戻り値dでも可能
    auto num2 = calc(8);
    printf ("%d\n", num2);
    // ループがちょっとだけ簡易にできる
    char *l_mount[] = {"Leica", "Panasonic", "SIGMA"};
    auto count = sizeof (l_mount) / sizeof (l_mount[0]);
    for (auto i=0; i<count; i++) {
        printf ("%s\n", l_mount[i]);
    }
    // 配列自体は無理
    //auto num_array = {1, 2, 3};
    return 0;
}

gcc

配列もダメか、あんまり便利じゃないてかコレ意味あるの?
とにかく -std=c23 又は -std=c2x 指定はどちらでも使えました。

#include <iostream>

/**
 * Fedora 42 は普通にイケました
 * g++ -std=c++20 c23.cc
 * 
 * macOS ではエラーになったので、場所指定は人によって違うと思う
 * clang++ -I /Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/c++/v1 -std=c++20 c23.cc
 */

auto
get_half(auto num) {
    return num / 2;
}
 
int
main (int argc, char *argv[]) {
  
    //char *l_mount[] = {"Leica", "Panasonic", "SIGMA"};
    auto l_mount = {"Leica", "Panasonic", "SIGMA"};

    for (auto obj : l_mount) {
        std::cout << obj << std::endl;
    }
    // 簡易オーバーロード
    std::cout << get_half(3) << std::endl;
    std::cout << get_half(3.0) << std::endl;

    return 0;
}

clang

C++ の auto はまさかのこんなことまで可能なのにね。
おまえは Python か、偽オーバーロードの中身はどうなっているのやら。
C++ でも stdio な某クソ OS はどうでもいいよね。

それより Clang が iostream を見つけてくれないんですけど。
macOS だけでなく Linux 版も同じみたいだけどバグなのか?
-I で場所指定すれば通るけどもっといい方法がありそうな。

Adw.AlertDialog

本日は休日出勤無しだが雨、野鳥撮影ヤメにしてプログラミングでも。
とりあえず Adw.AlertDialog を試しに書いてみることにした。

#!/usr/bin/env python3

import gi, sys
gi.require_version('Gtk', '4.0')
gi.require_version('Adw', '1')
from gi.repository import Gtk, Adw

class Win(Adw.ApplicationWindow):
    '''
        Gtk.ApplicationWindow is Gtk-CRITICAL
        Widget of type “AdwAlertDialog” already has an accessible role of type “GTK_ACCESSIBLE_ROLE_GENERIC”
    '''
    def __init__(self, a):
        # Set Adwaita Style
        manager = Adw.StyleManager.get_default()
        manager.set_color_scheme(Adw.ColorScheme.DEFAULT)
        # init
        Adw.ApplicationWindow.__init__(self, application=a)
        vbox = Gtk.Box(orientation=Gtk.Orientation.VERTICAL)
        # Header
        title = Adw.WindowTitle(title='test')
        header = Adw.HeaderBar(title_widget=title)
        vbox.append(header)
        for s in ('Simple', 'Yes No', 'Vertical'):
            # Button
            button = Gtk.Button(label=s)
            button.connect('clicked', self.on_button_clicked, s)
            vbox.append(button)
        # self
        self.set_content(vbox)
        self.set_default_size(600, 500)

    def on_button_clicked(self, button, text):
        match text:
            case 'Simple':
                alert = Adw.AlertDialog(body='Same for ESC')
                alert.add_response('close', 'OK')
                alert.present(self)
            case 'Yes No':
                alert = Adw.AlertDialog(body='Close to the Edge')
                # add_responces is no...
                alert.add_response('close', 'No')
                alert.add_response('yes', 'Yes')
                alert.set_response_appearance('yes', Adw.ResponseAppearance.SUGGESTED)
                alert.choose(self, None, self.on_dialog_responce)
            case 'Vertical':
                alert = Adw.AlertDialog(heading='Head', body='body', prefer_wide_layout=True)
                alert.add_response('close', 'Cancel')
                alert.add_response('no', 'Destroy this document')
                alert.add_response('ok', 'Save this document')
                alert.set_response_appearance('ok', Adw.ResponseAppearance.SUGGESTED)
                alert.set_response_appearance('no', Adw.ResponseAppearance.DESTRUCTIVE)
                alert.choose(self, None, self.on_dialog_responce)
            case _:
                alert = Adw.AlertDialog(body='???')
                alert.add_response('close', 'ok')
                alert.present(self)

    def on_dialog_responce(self, alert, res):
        text = alert.choose_finish(res)
        match text:
            case 'ok':
                print('Saved')
            case 'no':
                print('Discarded')
            case 'yes':
                print("You're a fan of Yes")
            case 'close':
                print('Oh my good!')

app = Gtk.Application()
app.connect('activate', lambda a: Win(a).present())
app.run()

GtkAlertDialog

Gtk.ApplicationWindow から呼び出ししても普通に動くんだけど。
Gtk-CRITICAL エラーを stdout に吐くのを気にしなければ、ですけど。
素直に Adw.ApplicationWindow から呼び出したほうが無難。

それと呼び出し Window より Dialog のほうが大きいと Warning になる。
ボタンは基本が横並びで横幅がはみ出しする場合は自動的に縦並びになる。
強制縦並びにしたければ prefer-wide-layout プロパティで可能。

id の文字列は日本語でも使えた、Python だからかもだけど。
外国人も検索で来るかもだからここでは英語にしましたけど。

Adw.MessageDialog 同様に Widget を載せることもできる。
gnome-text-editor で変更破棄すればどんな感じなのかは見れます。

Adw も洗練された Widget という謳い文句らしくなってきましたね。
というのを Kate というダサい Qt のエディタで書いているのがなんとも。
gnome-text-editor に拡張機能付けてくれないかなぁ、見た目はいいのに。
スニペットのショートカット挿入と html のエスケープ機能だけでもいいのに。

PyObjC Tips 更新

そんなこんなで PyObjC Tips 更新しました。
PyObjC Tips – Paepoi

macOS には PHP を入れていないので Fedora でページ作成。
面倒だけど Fedora 内とミラーリングするほうが面倒だし。

ところで Kate でも GVFS 接続で macOS 内のファイルが編集できるのね。
コレができるならもう Gedit はいらないよな、削除するか。

と思っていたら見つけた、Gedit の Flathub 版は v47 になっている。
https://gedit-technology.github.io/blog/
rpm では v46 のままだが、もしかしたらと入れてみる。

アイコンが変わった。
ダークテーマ対応、ただし OS 連動ではない。
ローカライズされず英語のまま。
~/.local/share/gedit/plugins に自作プラグインを置いても無視。
Python の fstring や mutch 文の色分けはされないまま。
PHP のヒアドキュメントインデント判別にも未対応なまま。
他の言語は解らないけど多分中身は v46 のまま。

だめだこりゃ、管理人はプログラミングをしていないのか?
今後バージョンが進んでも見た目以外の進化はしなさそう。

PyObjC がトンデモなく遅い

今日は久しぶりに PyObjC で小物を作ろうとした。
いやまあ macOS プログラミングは完全に放置気味でしたね。
ということでまずアップグレードを行なってと。

# pip Upgrade
pip3 install --upgrade pip

# PyObjC Install or Upgrade
pip3 install -U pyobjc

で本題、PyObjC コードの初期化がありえないほど遅い。
NSWindow を作ったら表示されるまで十秒くらい待たされる。
Python 標準モジュールのみのコードなら普通に一瞬だ。
しばらく色々試したらこういうことだった。

#!/usr/bin/env python3

'''
    app.old.py
'''

import time
start = time.time()

from AppKit import *
import objc

class AppMenu(NSMenu):
    def init(self):
        objc.super(AppMenu, self).init()
        item_app  = NSMenuItem.new()
        self.addItem_(item_app)
        menu_app = NSMenu.new()
        item_app.setSubmenu_(menu_app)
        # command+Q で閉じるメニュー
        item_quit = NSMenuItem.new()
        item_quit.initWithTitle_action_keyEquivalent_('Quit App', 'terminate:', 'q')
        menu_app.addItem_(item_quit)
        return self

# NSApp を作る
NSApplication.sharedApplication()
# command+Q で終了するメニューを入れる
NSApp.setMainMenu_(AppMenu.new())
# コレをしないと最前面に出てこない
NSApp.activateIgnoringOtherApps_(True)
# メインループを回さない
#NSApp.run()

# 経過時間 ms
print(f'{time.time() - start} ms')

from を使う今までやっていたコード。

#!/usr/bin/env python3

'''
    aoo.new.py
'''

import time
start = time.time()

import AppKit, objc

class AppMenu(AppKit.NSMenu):
    def init(self):
        objc.super(AppMenu, self).init()
        item_app  = AppKit.NSMenuItem.new()
        self.addItem_(item_app)
        menu_app = AppKit.NSMenu.new()
        item_app.setSubmenu_(menu_app)
        # command+Q で閉じるメニュー
        item_quit = AppKit.NSMenuItem.new()
        item_quit.initWithTitle_action_keyEquivalent_('Quit App', 'terminate:', 'q')
        menu_app.addItem_(item_quit)
        return self

# NSApp を作る
AppKit.NSApplication.sharedApplication()
# command+Q で終了するメニューを入れる
AppKit.NSApp.setMainMenu_(AppMenu.new())
# コレをしないと最前面に出てこない
AppKit.NSApp.activateIgnoringOtherApps_(True)
# メインループを回さないさない
#AppKit.NSApp.run()

# 経過時間 ms
print(f'{time.time() - start} ms')

都度プリフィクスを書く面倒くさいコード。

PyObjC

from で * を使うとトンデモネェ遅さになってしまった。
以前は from でも同じような速度で初期化されていたんですが。
NSApp だけでコレ、NSWindow まで作るとすげぇ悲惨。

Python 3.11 からの高速化の弊害なのかな。
from は全部辿ってキャッシュとかになっていたらまあこうなるよな。
いや PyObjC 側の不具合かもしれないけどプリフィクス化で解決するし。
Cocoa のメソッド名長いんだよな、GTK+ みたくできないのかと。
アスタリスクを使っている人は調べてみたほうがいいかも。

ついでに、objc は import しなくてもよかったのに必須になった。
activateIgnoringOtherApps が動作しない、何故?
ちょっと放置しすぎたな、もう少し調べよう。
秋の渡り鳥が来る前にやらないとまた放置しそうだし。