如何通过结构体成员地址获取父地址

有如下结构体: 12345678struct Test { int a; // .... // 还有若干成员 // ... int y; int z;}; 在只知道成员变量y地址的情况下,如何获取到结构体的首地址?

C++语言

不同操作系统所集成的字体

如果界面所指定的字体在用户系统上未安装,则会自动降级到系统默认字体,这样会导致界面显示异常或达不到预期效果。 对于特殊字体我们通常会集成到软件安装包内,但对于汉字这样的语言,它的文字比较多,因此字体文件比较大,如果集成到安装包内会导致安装包体积变大,所以对于类似中文这样字符比较多的语言字体,我们通常会选择系统自带的字体。 而不同操作系统(如Windows和macOS)所自带的字体不一样,甚至同一操作系统不同的版本(如Windows 7和Windows 11)自带的字体也不一样,因此在选择采用什么字体前,需要弄清我们应用程序支持的操作系统所自带的字体都有哪些,才能更好的做选择。 操作系统的新版本通常只会新增字体,不会移除老的字体。

编程基础

基于共享内存的跨平台RPC框架 - Veigar

1. 背景在项目开发中时常会遇到需要多个进程间交互/通信的场景,进程间通信(IPC)的方式有很多,比如文件、注册表、网络、管道、共享内存等。 对于简单的交互场景,我们可以随意选择一种合适的方式,如 Google Chrome 使用的是管道的方式。 但在交互场景复杂的情况下,远程过程调用(RPC)的方式则会更新便捷。 目前开源的、功能相对完善的 C++ RPC 框架都是基于网络方式实现的,这种方式存在服务端和客户端的概念,两端相互调用需要各方都启动一个端口监听服务,既然需要监听端口,那就会存在端口被占用的问题,特别是在 Windows 上还会存在端口假可用的问题,端口虽然监听成功,但客户端仍然无法连接的情况。 我一直想找到一个基于共享内存实现的、跨平台的 C++ RPC 框架,但遗憾的是一直没能结缘,于是我决定烹饪一个。

Power By Me

Node插件开发(2)-不同的调用方式

本文主要介绍如何在 Node-API 中实现不同的类型的接口,如: 同步调用 基于 Napi::AsyncWorker 的异步调用,通过回调函数返回 异步调用,返回 Promise 基于 Napi::ThreadSafeFunction 的异步调用,通过回调函数返回

Electron

ABI兼容性

ABI 是 Application Binary Interface 的缩写,当我们以二进制形式(非源码形式)发布我们的动态库时,就需要关心ABI兼容(也称二进制兼容)。 对于静态库,更新静态库始终都需要该库的使用方重新编译,因此不存在ABI兼容的说法。

C++语言

Node插件开发(1)-快速入门

在使用Electron开发客户端时,如果现有Node模块所提供的功能无法满足需求,我们可以使用C++开发自定义的Node模块,也称插件(addon)。 Node.js插件的扩展名为.node,是二进制文件,其本质上是动态链接库重命名而来,在Windows平台是.dll文件,Linux/Unix平台是.so文件。

Electron

产品级的Electron项目模板

写在前面已经有了那么多的 Electron 项目模板,为什么还要再造一个?是重复造轮子吗? 我相信大多数人选择使用 Electron 开发客户端时,或多或少都看上了 Web 开发的高效率,但Web开发人员在客户端和系统编程方面的经验相对缺乏,又加上 Electron 和前端框架(如 Vue )结合起来也不是那么的轻而易举,开发人员大多会选择基于模板来快速上手搭建Electron项目。 目前,Electron 的模板项目已经有很多,比较流行的有electron-vite、electron-vite-vue等。在这些模板中,有的功能过于完善,代码太复杂,远远超过了很多 Electron 客户端项目本身的代码量,需要花很多时间来熟悉模板,不适合新手快速上手和修改,一旦出现问题也难以维护;有的模板又年久失修,使用的技术早已被淘汰,也不适合用来开发线上产品,而且这些模板都有一个通病,都是在用Web开发的思维来开发客户端。 基于上述原因,我开发了这个 Electron 项目模板,在开发过程中,我一直遵循稳定、易于维护的初衷。 项目地址:https://github.com/winsoft666/electron-vue3-boilerplate

Power By Me

🐉2024龙行龘龘

写下这一行预示着2024年的工作开始了,加油! 物来顺应,未来不迎。 当时不杂,既过不恋。

杂念
123422