/*
A single file header-only live reload solution for C, written in C++:
NOTE: The only file that matters in this repository is cr.h
.
This file contains the documentation in markdown, the license, the implementation and the public api. All other files in this repository are supporting files and can be safely ignored.
You can download and install cr using the vcpkg dependency manager:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install cr
The cr port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.
A (thin) host application executable will make use of cr
to manage
live-reloading of the real application in the form of dynamic loadable binary, a host would be something like:
#define CR_HOST // required in the host only and before including cr.h #include "../cr.h" int main(int argc, char *argv[]) { // the host application should initalize a plugin with a context, a plugin cr_plugin ctx; // the full path to the live-reloadable application cr_plugin_open(ctx, "c:/path/to/build/game.dll"); // call the update function at any frequency matters to you, this will give // the real application a chance to run while (!cr_plugin_update(ctx)) { // do anything you need to do on host side (ie. windowing and input stuff?) } // at the end do not forget to cleanup the plugin context cr_plugin_close(ctx); return 0; }
While the guest (real application), would be like:
CR_EXPORT int cr_main(struct cr_plugin *ctx, enum cr_op operation) { assert(ctx); switch (operation) { case CR_LOAD: return on_load(...); // loading back from a reload case CR_UNLOAD: return on_unload(...); // preparing to a new reload case CR_CLOSE: ...; // the plugin will close and not reload anymore } // CR_STEP return on_update(...); }
CR_INITIAL_FAILURE
. If the initial plugin crashes, the host must determine the next path, and we will not reload
the broken plugin.cr_plugin_load
in favor to cr_plugin_open
for consistency with cr_plugin_close
. See issue #49.CR_BAD_IMAGE
in case the binary file is stil not ready even if its timestamp changed. This could happen if generating the file (compiler or copying) was slow.CR_BAD_IMAGE
). Now the version is decremented one time in the crash handler and then another time during the rollback and then be bumped again. A rollback due an incomplete image will not incorrectly rollback two versions, it will continue at the same version retrying the load until the image is valid (copy or compiler finished writing to it). This may impact current uses of cr
if the version
info is used during CR_UNLOAD
as it will now be a different value.Two simple samples can be found in the samples
directory.
The first is one is a simple console application that demonstrate some basic static states working between instances and basic crash handling tests. Print to output is used to show what is happening.
The second one demonstrates how to live-reload an opengl application using Dear ImGui. Some state lives in the host side while most of the code is in the guest side.
The samples and tests uses the fips build system. It requires Python and CMake.
$ ./fips build # will generate and build all artifacts
$ ./fips run crTest # To run tests
$ ./fips run imgui_host # To run imgui sample
# open a new console, then modify imgui_guest.cpp
$ ./fips make imgui_guest # to build and force imgui sample live reload
int (*cr_main)(struct cr_plugin *ctx, enum cr_op operation)
This is the function pointer to the dynamic loadable binary entry point function.
Arguments
ctx
pointer to a context that will be passed from host
to the guest
containing valuable information about the current loaded version, failure reason and user data. For more info see cr_plugin
.operation
which operation is being executed, see cr_op
.Return
CR_USER
. 0 or a positive value that will be passed to the
host
process.bool cr_plugin_open(cr_plugin &ctx, const char *fullpath)
Loads and initialize the plugin.
Arguments
ctx
a context that will manage the plugin internal data and user data.fullpath
full path with filename to the loadable binary for the plugin or
NULL
.Return
true
in case of success, false
otherwise.void cr_set_temporary_path(cr_plugin& ctx, const std::string &path)
Sets temporary path to which temporary copies of plugin will be placed. Should be called
immediately after cr_plugin_open()
. If temporary
path is not set, temporary copies of
the file will be copied to the same directory where the original file is located.
Arguments
ctx
a context that will manage the plugin internal data and user data.path
a full path to an existing directory which will be used for storing temporary plugin copies.int cr_plugin_update(cr_plugin &ctx, bool reloadCheck = true)
This function will call the plugin cr_main
function. It should be called as
frequently as the core logic/application needs.
Arguments
ctx
the current plugin context data.reloadCheck
optional: do a disk check (stat()) to see if the dynamic library needs a reload.Return
cr_main
.void cr_plugin_close(cr_plugin &ctx)
Cleanup internal states once the plugin is not required anymore.
Arguments
ctx
the current plugin context data.cr_op
Enum indicating the kind of step that is being executed by the host
:
CR_LOAD
A load caused by reload is being executed, can be used to restore any
saved internal state.CR_STEP
An application update, this is the normal and most frequent operation;CR_UNLOAD
An unload for reloading the plugin will be executed, giving the
application one chance to store any required data;CR_CLOSE
Used when closing the plugin, This works like CR_UNLOAD
but no CR_LOAD
should be expected afterwards;cr_plugin
The plugin instance context struct.
p
opaque pointer for internal cr data;userdata
may be used by the user to pass information between reloads;version
incremetal number for each succeded reload, starting at 1 for the
first load. The version will change during a crash handling process;failure
used by the crash protection system, will hold the last failure error
code that caused a rollback. See cr_failure
for more info on possible values;cr_failure
If a crash in the loadable binary happens, the crash handler will indicate the reason of the crash with one of these:
CR_NONE
No error;CR_SEGFAULT
Segmentation fault. SIGSEGV
on Linux/OSX or
EXCEPTION_ACCESS_VIOLATION
on Windows;CR_ILLEGAL
In case of illegal instruction. SIGILL
on Linux/OSX or
EXCEPTION_ILLEGAL_INSTRUCTION
on Windows;CR_ABORT
Abort, SIGBRT
on Linux/OSX, not used on Windows;CR_MISALIGN
Bus error, SIGBUS
on Linux/OSX or EXCEPTION_DATATYPE_MISALIGNMENT
on Windows;CR_BOUNDS
Is EXCEPTION_ARRAY_BOUNDS_EXCEEDED
, Windows only;CR_STACKOVERFLOW
Is EXCEPTION_STACK_OVERFLOW
, Windows only;CR_STATE_INVALIDATED
Static CR_STATE
management safety failure;CR_BAD_IMAGE
The plugin is not a valid image (i.e. the compiler may still
writing it);CR_OTHER
Other signal, Linux only;CR_USER
User error (for negative values returned from cr_main
);CR_HOST
defineThis define should be used before including the cr.h
in the host
, if CR_HOST
is not defined, cr.h
will work as a public API header file to be used in the
guest
implementation.
Optionally CR_HOST
may also be defined to one of the following values as a way
to configure the safety
operation mode for automatic static state management
(CR_STATE
):
CR_SAFEST
Will validate address and size of the state data sections during
reloads, if anything changes the load will rollback;CR_SAFE
Will validate only the size of the state section, this mean that the
address of the statics may change (and it is best to avoid holding any pointer
to static stuff);CR_UNSAFE
Will validate nothing but that the size of section fits, may not
be necessarelly exact (growing is acceptable but shrinking isn't), this is the
default behavior;CR_DISABLE
Completely disable automatic static state management;CR_STATE
macroUsed to tag a global or local static variable to be saved and restored during a reload.
Usage
static bool CR_STATE bInitialized = false;
You can define these macros before including cr.h in host (CR_HOST) to customize cr.h memory allocations and other behaviours:
CR_MAIN_FUNC
: changes 'cr_main' symbol to user-defined function name. default: #define CR_MAIN_FUNC "cr_main"CR_ASSERT
: override assert. default: #define CA_ASSERT(e) assert(e)CR_REALLOC
: override libc's realloc. default: #define CR_REALLOC(ptr, size) ::realloc(ptr, size)CR_MALLOC
: override libc's malloc. default: #define CR_MALLOC(size) ::malloc(size)CR_FREE
: override libc's free. default: #define CR_FREE(ptr) ::free(ptr)CR_DEBUG
: outputs debug messages in CR_ERROR, CR_LOG and CR_TRACECR_ERROR
: logs debug messages to stderr. default (CR_DEBUG only): #define CR_ERROR(...) fprintf(stderr, VA_ARGS)CR_LOG
: logs debug messages. default (CR_DEBUG only): #define CR_LOG(...) fprintf(stdout, VA_ARGS)CR_TRACE
: prints function calls. default (CR_DEBUG only): #define CR_TRACE(...) fprintf(stdout, "CR_TRACE: %s\n", FUNCTION)A: Read about why I made this here.
A: Make sure both your application host and your dll are using the dynamic run-time (/MD or /MDd) as any data allocated in the heap must be freed with the same allocator instance, by sharing the run-time between guest and host you will guarantee the same allocator is being used.
A: Yes. This should work without issues on Windows. On Linux and OSX there may be issues with crash handling
If you had to load the dll before cr
for any reason, Visual Studio may still hold a lock to the PDB. You may be having this issue and the solution is here.
First, be sure that your build system is not interfering by somewhat still linking to your shared library. There are so many things that can go wrong and you need to be sure only cr
will deal with your shared library. On linux, for more info on how to find what is happening, check this issue.
cr
is C
reloader and dealing with C it assume simple things will mostly work.
The problem is how the linker will decide do rearrange things accordingly the amount of changes you do in the code. For incremental and localized changes I never had any issues, in general I hardly had any issues at all by writing normal C code. Now, when things start to become more complex and bordering C++, it becomes riskier. If you need do complex things, I suggest checking RCCPP and reading this PDF and my original blog post about cr
here.
With all these information you'll be able to decide which is better to your use case.
cr
SponsorsFor sponsoring the port of cr
to the MacOSX.
We welcome ALL contributions, there is no minor things to contribute with, even one letter typo fixes are welcome.
The only things we require is to test thoroughly, maintain code style and keeping documentation up-to-date.
Also, accepting and agreeing to release any contribution under the same license.
The MIT License (MIT)
Copyright (c) 2017 Danny Angelo Carminati Grein
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/ #ifndef __CR_H__ #define __CR_H__ // // Global OS specific defines/customizations // #if defined(_WIN32) #define CR_WINDOWS #define CR_PLUGIN(name) "" name ".dll" #elif defined(__linux__) #define CR_LINUX #define CR_PLUGIN(name) "lib" name ".so" #elif defined(__APPLE__) #define CR_OSX #define CR_PLUGIN(name) "lib" name ".dylib" #else #error "Unknown/unsupported platform, please open an issue if you think this \ platform should be supported." #endif // CR_WINDOWS || CR_LINUX || CR_OSX // // Global compiler specific defines/customizations // #if defined(_MSC_VER) #if defined(__cplusplus) #define CR_EXPORT extern "C" __declspec(dllexport) #define CR_IMPORT extern "C" __declspec(dllimport) #else #define CR_EXPORT __declspec(dllexport) #define CR_IMPORT __declspec(dllimport) #endif #endif
字节跳动发布的AI编程神器IDE
Trae是一种自适应的集成开发环境(IDE),通过自动化和多元协作改变开发流程。利用Trae,团队能够更快速、精确地编写和部署代码,从而提高编程效率和项目交付速度。Trae具备上下文感知和代码自动完成功能,是提升开发效率的理想工具。
全能AI智能助手,随时解答生活与工作的多样问题
问小白,由元石科技研发的AI智能助手,快速准确地解答各种生活和工作问题,包括但不限于搜索、规划和社交互动, 帮助用户在日常生活中提高效率,轻松管理个人事务。
实时语音翻译/同声传译工具
Transly是一个多场景的AI大语言模型驱动的同声传译、专业翻译助手,它拥有超精准的音频识别翻译能力,几乎零延迟的使用体验和支持多国语言可以让你带它走遍全球,无论你是留学生、商务人士、韩剧美剧爱好者,还是出国游玩、多国会议、跨国追星等等 ,都可以满足你所有需要同传的场景需求,线上线下通用,扫除语言障碍,让全世界的语言交流不再有国界。
一键生成PPT和Word,让学习生活更轻松
讯飞智文是一个利用 AI 技术的项目,能够帮助用户生成 PPT 以及各类文档。无论是商业领域的市场分析报告、年度目标制定,还是学生群体的职业生涯规划、实习避坑指南,亦或是活动策划、旅游攻略等内容,它都能提供支持,帮助用户精准表达,轻松呈现各种信息。
深度推理能力全新升级,全面对标OpenAI o1
科大讯飞的星火大模型,支持语言理解、知识问答和文本创作等多功能,适用于多种文件和业务场景,提升办公和日常生活的效率。讯飞星火是一个提供丰富智能服务的平台,涵盖科技资讯、图像创作、写作 辅助、编程解答、科研文献解读等功能,能为不同需求的用户提供便捷高效的帮助,助力用户轻松获取信息、解决问题,满足多样化使用场景。
一种基于大语言模型的高效单流解耦语音令牌文本到语音合成模型
Spark-TTS 是一个基于 PyTorch 的开源文本到语音合成项目,由多个知名机构联合参与。该项目提供了高效的 LLM(大语言模型)驱动的语音合成方案,支持语音克隆和语音创建功能,可通过命令行界面(CLI)和 Web UI 两种方式使用。用户可以根据需求调整语音的性别、音高、速度等参数,生成高质量的语音。该项目适用于多种场景,如有声读物制作、智能语音助手开发等。
AI助力,做PPT更简单!
咔片是一款轻量化在线演示设计工具,借助 AI 技术,实现从内容生成到智能设计的一站式 PPT 制作服务。 支持多种文档格式导入生成 PPT,提供海量模板、智能美化、素材替换等功能,适用于销售、教师、学生等各类人群,能高效制作出高品质 PPT,满足不同场景演示需求。
选题、配图、成文,一站式创作,让内容运营更高效
讯飞绘文,一个AI集成平台,支持写作、选题、配图、排版和发布。高效生成适用于各类媒体的定制内容,加速品牌传播,提升内容营销效果。