3.1 Basic Logging and Tracing
通常，用ACE_DEBUG, ACE_ERROR
, and ACE_TRACE这三个宏来输出诊断信息
Three macros are commonly used to display diagnostic output from your code: ACE_DEBUG
, ACE_ERROR
, and ACE_TRACE
.
头两个的参数和实现的操作基本相同
The arguments to the first two are the same; their operation is nearly identical, so for our purposes now, we'll treat them the same. They both take a severity indicator as one of the arguments, so you can display any message using either;
然而，ACE_DEBUG通常用来输出自己的调试信息；ACE_ERROR用来输出警告和错误
however, the convention is to use ACE_DEBUG
for your own debugging statements and ACE_ERROR
for warnings and errors. The use of these macros is the same:
ACE_DEBUG ((severity, formatting-args
));
ACE_ERROR ((severity, formatting-args
));
The severity
parameter specifies the severity level of your message.
最常用的就是LM_DEBUG和LM_ERROR
The most common levels are LM_DEBUG
and LM_ERROR
. All the valid severity values are listed in
Table 3.1
.
The formatting-args
parameter is a printf()
-like
set of format conversion operators and formatting arguments for insertion into the output. The complete set of formatting directives is described in
Table 3.2
. One might wonder why printf()
-like formatting was chosen instead of the more natural—to C++ coders—C++ iostream-style formatting. In some cases, it would have been easier to correctly log certain types of information with type-safe insertion operators. However, an important factor in the logging facility's design is the ability to effectively "no-op" the logging statements at compile time. Note that the ACE_DEBUG
and ACE_ERROR
invocations require two sets of parentheses. The outer set delimits the single macro argument. This single argument comprises all the arguments, and their enclosing parentheses, needed for a method call. If the preprocessor macro ACE_NDEBUG
is defined, the ACE_DEBUG
macro will expand to a blank line, ignoring the content of the inner set of parentheses. Achieving this same optimization with insertion operators would have resulted in a rather odd usage:
ACE_DEBUG ((debug_info << "Hi Mom" << endl));
Table 3.1. ACE_Log_Msg
Logging Severity Levels
Severity Level
Meaning
|
LM_TRACE
|
Messages indicating function-calling sequence
|
|
LM_DEBUG
|
Debugging information
|
|
LM_INFO
|
Messages that contain information normally of use only when debugging a program
|
|
LM_NOTICE
|
Conditions that are not error conditions but that may require special handling
|
|
LM_WARNING
|
Warning messages
|
|
LM_ERROR
|
Error messages
|
|
LM_CRITICAL
|
Critical conditions, such as hard device errors
|
|
LM_ALERT
|
A condition that should be corrected immediately, such as a corrupted system database
|
|
LM_EMERGENCY
|
A panic condition, normally broadcast to all users
|
Similarly, many of the formatting tokens, such as %I
, would have been awkward to implement and overly verbose to use:
ACE_DEBUG((debug_info<<ACE_Log_Msg::nested_indent<<"Hi Mom"<<endl));
One could argue away the compile-time optimization by causing ACE_NDEBUG
to put the debug output stream object into a no-op mode. That may be sufficient for some platforms, but for others, such as embedded real-time systems, you really do
want the code to simply not exist.
Unlike ACE_DEBUG
and ACE_ERROR
, which cause output where the macro is placed, ACE_TRACE
causes one line of debug information to be printed at the point of the ACE_TRACE
statement and another when its enclosing scope is exited. Therefore, placing an ACE_TRACE
statement at the beginning of a function or method provides a trace of when that function or method is entered and exited. The ACE_TRACE
macro accepts a single character string rather than a set of formatting directives. Because C++ doesn't have a handy way to dump a stack trace, this can be very useful indeed.
Let's take a look at a simple application:
#include "ace/Log_Msg.h"
void foo (void);
int ACE_TMAIN (int, ACE_TCHAR *[])
{
ACE_TRACE(ACE_TEXT ("main"));
ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHi Mom\n")));
foo();
ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IGoodnight\n")));
return 0;
}
void foo (void)
{
ACE_TRACE (ACE_TEXT ("foo"));
ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHowdy Pardner\n")));
}
Our first step is always to include the Log_Msg.h
header file. It defines many helpful macros, including ACE_DEBUG
and ACE_ERROR
, to make your life easier. The full set of output-producing macros is listed in
Table 3.3
.
You can use ACE_DEBUG
to print just about any arbitrary string you want, and the many format directives listed in
Table 3.2
can also be modified with printf()
-style modifiers for length, precision, and fill adjustments. (See a printf()
reference for details on the modifiers.) In the preceding example, we've used %I
so that the ACE_DEBUG
messages are nicely indented along with the ACE_TRACE
messages.
If you compile and execute the preceding code, you should get something like this:
(1024) calling main in file `Simple1.cpp' on line 7
Hi Mom
(1024) calling foo in file `Simple1.cpp' on line 18
Howdy Pardner
(1024) leaving foo
Goodnight
(1024) leaving main
Table 3.2. ACE Logging Format Directives
Code
Argument Type
Displays
|
A
|
ACE_timer_t
|
Floating-point number; long decimal number if platform doesn't support floating point
|
|
a
|
—
|
Aborts the program after displaying output
|
|
c
|
char
|
Single character
|
|
C
|
char*
|
Character string (narrow characters)
|
|
i,d
|
int
|
Decimal number
|
|
I
|
—
|
Indents output according to the nesting depth, obtained from ACE_Trace::get_nesting_indent()
|
|
e,E,f,F,g,G
|
double
|
Double-precision floating-point number
|
|
l
|
—
|
Line number where logging macro appears
|
|
M
|
—
|
Text form of the message severity level
|
|
m
|
—
|
Message corresponding to errno
value, as done by strerror()
, for example
|
|
N
|
—
|
File name where logging macro appears
|
|
n
|
—
|
Program name given to ACE_Log_Msg::open()
|
|
o
|
int
|
Octal number
|
|
P
|
—
|
Current process ID
|
|
p
|
ACE_TCHAR*
|
Specified character string, followed by the appropriate errno
message, that is, as done by perror()
|
|
Q
|
ACE_UINT64
|
Decimal number
|
|
r
|
void (*)()
|
Nothing; calls the specified function
|
|
R
|
int
|
Decimal number
|
|
S
|
int
|
Signal name of the numbered signal
|
|
s
|
ACE_TCHAR*
|
Character string: narrow or wide, according to ACE_TCHAR
type
|
|
T
|
—
|
Current time as hour:minute:sec.usec
|
|
D
|
—
|
Timestamp as month/day/year hour:minute:sec.usec
|
|
t
|
—
|
Calling thread's ID (1 if single threaded)
|
|
u
|
int
|
Unsigned decimal number
|
|
w
|
font-family: times new ro
分享到：
Global site tag (gtag.js) - Google Analytics
| |
相关推荐
OpenDDS是一个开源的DDS实现，它依赖于ACE（Adaptive Communication Environment）和TAO（The Adaptive ORB）框架。下面是根据标题和描述中的内容，详细解释这些关键知识点： 1. **ACE+TAO框架**： ACE是一个C++库...
OpenDDS是基于DDS（Data Distribution Service）标准的开源实现，它依赖于ACE（Adaptive Communication Environment）和TAO（The Adaptive Communication Environment）框架。在本文中，我们将详细探讨如何在Linux...
1.版本：matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
MMC整流器技术解析：基于Matlab的双闭环控制策略与环流抑制性能研究,Matlab下的MMC整流器技术文档：18个子模块，双闭环控制稳定直流电压，环流抑制与最近电平逼近调制，优化桥臂电流波形，高效并网运行。,MMC整流器（Matlab），技术文档 1.MMC工作在整流侧，子模块个数N＝18，直流侧电压Udc＝25.2kV，交流侧电压6.6kV 2.控制器采用双闭环控制，外环控制直流电压，采用PI调节器，电流内环采用PI＋前馈解耦； 3.环流抑制采用PI控制，能够抑制环流二倍频分量； 4.采用最近电平逼近调制（NLM）， 5.均压排序：电容电压排序采用冒泡排序，判断桥臂电流方向确定投入切除； 结果： 1.输出的直流电压能够稳定在25.2kV； 2.有功功率，无功功率稳态时波形稳定，有功功率为3.2MW，无功稳定在0Var； 3.网侧电压电流波形均为对称的三相电压和三相电流波形，网侧电流THD＝1.47％<2％，符合并网要求； 4.环流抑制后桥臂电流的波形得到改善，桥臂电流THD由9.57％降至1.93％，环流波形也可以看到得到抑制； 5.电容电压能够稳定变化 ,工作点关键词：MMC
Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪：基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪：基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构，Simulink建模，MPPT最大功率点追踪，扰动观察法采用功率反馈方式，若ΔP>0，说明电压调整的方向正确，可以继续按原方向进行“干扰”；若ΔP<0，说明电压调整的方向错误，需要对“干扰”的方向进行改变。 ,Boost升压;光伏并网结构;Simulink建模;MPPT最大功率点追踪;扰动观察法;功率反馈;电压调整方向。,光伏并网结构中Boost升压MPPT控制策略的Simulink建模与功率反馈扰动观察法
STM32F103C8T6 USB寄存器开发详解(12)-键盘设备
科技活动人员数专指直接从事科技活动以及专门从事科技活动管理和为科技活动提供直接服务的人员数量
Matlab Simulink仿真探究Flyback反激式开关电源性能表现与优化策略,Matlab Simulink仿真探究Flyback反激式开关电源的工作机制,Matlab Simulimk仿真，Flyback反激式开关电源仿真 ,Matlab; Simulink仿真; Flyback反激式; 开关电源仿真,Matlab Simulink在Flyback反激式开关电源仿真中的应用
基于Comsol的埋地电缆电磁加热计算模型：深度解析温度场与电磁场分布学习资料与服务,COMSOL埋地电缆电磁加热计算模型：温度场与电磁场分布的解析与学习资源,comsol 埋地电缆电磁加热计算模型，可以得到埋地电缆温度场及电磁场分布，提供学习资料和服务， ,comsol;埋地电缆电磁加热计算模型;温度场分布;电磁场分布;学习资料;服务,Comsol埋地电缆电磁加热模型：温度场与电磁场分布学习资料及服务
1、文件内容：ibus-table-chinese-yong-1.4.6-3.el7.rpm以及相关依赖 2、文件形式：tar.gz压缩包 3、安装指令： #Step1、解压 tar -zxvf /mnt/data/output/ibus-table-chinese-yong-1.4.6-3.el7.tar.gz #Step2、进入解压后的目录，执行安装 sudo rpm -ivh *.rpm 4、更多资源/技术支持：公众号禅静编程坊
基于51单片机protues仿真的汽车智能灯光控制系统设计（仿真图、源代码） 一、设计项目 根据本次设计的要求，设计出一款基于51单片机的自动切换远近光灯的设计。 技术条件与说明： 1. 设计硬件部分，中央处理器采用了STC89C51RC单片机； 2. 使用两个灯珠代表远近光灯，感光部分采用了光敏电阻，因为光敏电阻输出的是电压模拟信号，单片机不能直接处理模拟信号，所以经过ADC0832进行转化成数字信号； 3. 显示部分采用了LCD1602液晶，还增加按键部分电路，可以选择手自动切换远近光灯； 4. 用超声模块进行检测距离；
altermanager的企业微信告警服务
MyAgent测试版本在线下载
Comsol技术：可调BIC应用的二氧化钒VO2材料探索,Comsol模拟二氧化钒VO2的可调BIC特性研究,Comsol二氧化钒VO2可调BIC。 ,Comsol; 二氧化钒VO2; 可调BIC,Comsol二氧化钒VO2材料：可调BIC技术的关键应用
C++学生成绩管理系统源码
基于Matlab与Cplex的激励型需求响应模式：负荷转移与电价响应的差异化目标函数解析,基于Matlab与CPLEX的激励型需求响应负荷转移策略探索,激励型需求响应 matlab +cplex 激励型需求响应采用激励型需求响应方式对负荷进行转移，和电价响应模式不同，具体的目标函数如下 ,激励型需求响应; matlab + cplex; 负荷转移; 目标函数。,Matlab与Cplex结合的激励型需求响应模型及其负荷转移策略
scratch介绍（scratch说明）.zip
内容概要：本文全面介绍了深度学习模型的概念、工作机制和发展历程，详细探讨了神经网络的构建和训练过程，包括反向传播算法和梯度下降方法。文中还列举了深度学习在图像识别、自然语言处理、医疗和金融等多个领域的应用实例，并讨论了当前面临的挑战，如数据依赖、计算资源需求、可解释性和对抗攻击等问题。最后，文章展望了未来的发展趋势，如与量子计算和区块链的融合，以及在更多领域的应用前景。 适合人群：对该领域有兴趣的技术人员、研究人员和学者，尤其适合那些希望深入了解深度学习原理和技术细节的读者。 使用场景及目标：①理解深度学习模型的基本原理和结构；②了解深度学习模型的具体应用案例；③掌握应对当前技术挑战的方向。 阅读建议：文章内容详尽丰富，读者应在阅读过程中注意理解各个关键技术的概念和原理，尤其是神经网络的构成及训练过程。同时也建议对比不同模型的特点及其在具体应用中的表现。
该文档提供了一个关于供应链管理系统开发的详细指南，重点介绍了项目安排、技术实现和框架搭建的相关内容。 文档分为以下几个关键部分： 项目安排：主要步骤包括搭建框架（1天），基础数据模块和权限管理（4天），以及应收应付和销售管理（5天）。 供应链概念：供应链系统的核心流程是通过采购商品放入仓库，并在销售时从仓库提取商品，涉及三个主要订单：采购订单、销售订单和调拨订单。 大数据的应用：介绍了数据挖掘、ETL（数据抽取）和BI（商业智能）在供应链管理中的应用。 技术实现：讲述了DAO（数据访问对象）的重用、服务层的重用、以及前端JS的继承机制、jQuery插件开发等技术细节。 系统框架搭建：包括Maven环境的配置、Web工程的创建、持久化类和映射文件的编写，以及Spring配置文件的实现。 DAO的需求和功能：供应链管理系统的各个模块都涉及分页查询、条件查询、删除、增加、修改操作等需求。 泛型的应用：通过示例说明了在Java语言中如何使用泛型来实现模块化和可扩展性。 文档非常技术导向，适合开发人员参考，用于构建供应链管理系统的架构和功能模块。