I've encountered the following problem pattern frequently over the years:
多年来我经常遇到以下问题模式:
-
I'm writing complex code for a package comprised of a standalone application and also a library version of the core that people can use from inside other apps.
我正在编写一个包含独立应用程序的软件包的复杂代码,以及人们可以在其他应用程序中使用的核心库版本。
-
Both our own app and presumably ones that users create with the core library are likely to be run both in batch mode (off-line, scripted, remote, and/or from command line), as well as interactively.
我们自己的应用程序和可能是用户使用核心库创建的应用程序都可能以批处理模式(离线,脚本,远程和/或命令行)以及交互方式运行。
-
The library/app takes complex and large runtime input and there may be a variety of error-like outputs including severe error messages, input syntax warnings, status messages, and run statistics. Note that these are all incidental outputs, not the primary purpose of the application which would be displayed or saved elsewhere and using different methods.
库/ app需要复杂的大型运行时输入,并且可能存在各种类似错误的输出,包括严重错误消息,输入语法警告,状态消息和运行统计信息。请注意,这些都是附带输出,而不是应用程序的主要目的,它将在其他地方显示或保存并使用不同的方法。
-
Some of these (probably only the very severe ones) might require a dialog box if run interactively; but it needs to log without stalling for user input if run in batch mode; and if run as a library the client program obviously wants to intercept and/or examine the errors as they occur.
如果以交互方式运行,其中一些(可能只是非常严重的那些)可能需要一个对话框;但如果以批处理模式运行,它需要记录而不会停止用户输入;如果作为库运行,客户端程序显然希望在发生错误时拦截和/或检查错误。
-
It all needs to be cross-platform: Linux, Windows, OSX. And we want the solution to not be weird on any platform. For example, output to stderr is fine for Linux, but won't work on Windows when linked to a GUI app.
这一切都需要跨平台:Linux,Windows,OSX。我们希望解决方案在任何平台上都不奇怪。例如,输出到stderr适用于Linux,但在链接到GUI应用程序时无法在Windows上运行。
-
Client programs of the library may create multiple instances of the main class, and it would be nice if the client app could distinguish a separate error stream with each instance.
库的客户端程序可以创建主类的多个实例,如果客户端应用程序可以区分每个实例的单独错误流,那将是很好的。
-
Let's assume everybody agrees it's good enough for the library methods to log errors via a simple call (error code and/or severity, then printf-like arguments giving an error message). The contentious part is how this is recorded or retrieved by the client app.
让我们假设每个人都同意这对于库方法通过简单的调用(错误代码和/或严重性,然后是类似printf的参数给出错误消息)来记录错误是足够好的。有争议的部分是客户端应用程序如何记录或检索它。
I've done this many times over the years, and am never fully satisfied with the solution. Furthermore, it's the kind of subproblem that's actually not very important to users (they want to see the error log if something goes wrong, but they don't really care about our technique for implementing it), but the topic gets the programmers fired up and they invariably waste inordinate time on this detail and are never quite happy.
多年来我已经多次这样做了,我对这个解决方案从未完全满意。此外,它是那种对用户来说实际上并不重要的子问题(如果出现问题他们希望看到错误日志,但他们并不真正关心我们实现它的技术),但该主题让程序员激起了他们总是在这个细节上浪费过多的时间,从来都不开心。
Anybody have any wisdom for how to integrate this functionality into a C++ API, or is there an accepted paradigm or a good open source solution (not GPL, please, I'd like a solution I can use in commercial closed apps as well as OSS projects)?
任何人都有任何关于如何将此功能集成到C ++ API中的智慧,或者是否存在可接受的范例或良好的开源解决方案(请不要使用GPL,我想要一个可以在商业封闭式应用程序和OSS中使用的解决方案项目)?
2 个解决方案
#1
1
We use Apache's Log4cxx for logging which isn't perfect, but provides a lot of infrastructure and a consistent approach across projects. I believe it is cross-platform, though we only use it on Windows.
我们使用Apache的Log4cxx进行日志记录并不完美,但它提供了大量的基础架构和跨项目的一致方法。我相信它是跨平台的,尽管我们只在Windows上使用它。
It provides for run time configuration via an ini file which allows you to control how the log file is output, and you could write your own appenders if you want specific behaviour (e.g. an error dialog under the UI).
它通过ini文件提供运行时配置,允许您控制日志文件的输出方式,如果您需要特定的行为(例如UI下的错误对话框),您可以编写自己的appender。
If clients of your library also adopt it then it would integrate their logging output into the same log file(s).
如果您的库的客户端也采用它,那么它会将其日志记录输出集成到相同的日志文件中。
Differentiation between instances of the main class could be supported using the nested diagnostic context (NDC) feature.
可以使用嵌套诊断上下文(NDC)功能支持主类实例之间的区分。
#2
1
Log4Cxx should work for you. You need to implement a provider that allows the library user to catch the log output in callbacks. The library would export a function to install the callbacks. That function should, behind the scenes, reconfigure log4cxxx to get rid of all appenders and set up the "custom" appender.
Log4Cxx应该适合你。您需要实现一个允许库用户捕获回调中的日志输出的提供程序。该库将导出一个函数来安装回调。该功能应该在幕后重新配置log4cxxx以摆脱所有appender并设置“自定义”appender。
Of course, the library user has an option to not install the callbacks and use log4cxx as is.
当然,库用户可以选择不安装回调并按原样使用log4cxx。
#1
1
We use Apache's Log4cxx for logging which isn't perfect, but provides a lot of infrastructure and a consistent approach across projects. I believe it is cross-platform, though we only use it on Windows.
我们使用Apache的Log4cxx进行日志记录并不完美,但它提供了大量的基础架构和跨项目的一致方法。我相信它是跨平台的,尽管我们只在Windows上使用它。
It provides for run time configuration via an ini file which allows you to control how the log file is output, and you could write your own appenders if you want specific behaviour (e.g. an error dialog under the UI).
它通过ini文件提供运行时配置,允许您控制日志文件的输出方式,如果您需要特定的行为(例如UI下的错误对话框),您可以编写自己的appender。
If clients of your library also adopt it then it would integrate their logging output into the same log file(s).
如果您的库的客户端也采用它,那么它会将其日志记录输出集成到相同的日志文件中。
Differentiation between instances of the main class could be supported using the nested diagnostic context (NDC) feature.
可以使用嵌套诊断上下文(NDC)功能支持主类实例之间的区分。
#2
1
Log4Cxx should work for you. You need to implement a provider that allows the library user to catch the log output in callbacks. The library would export a function to install the callbacks. That function should, behind the scenes, reconfigure log4cxxx to get rid of all appenders and set up the "custom" appender.
Log4Cxx应该适合你。您需要实现一个允许库用户捕获回调中的日志输出的提供程序。该库将导出一个函数来安装回调。该功能应该在幕后重新配置log4cxxx以摆脱所有appender并设置“自定义”appender。
Of course, the library user has an option to not install the callbacks and use log4cxx as is.
当然,库用户可以选择不安装回调并按原样使用log4cxx。