关于ACE_InputCDR和ACE_OutputCDR读写数据时的经验[原创*必读！]

peakzhang

by 动物园墙垮
我今天测试发现ACE_InputCDR和ACE_OutputCDR并不是那么简单。
如果稍微不注意就会出现一些奇怪的字节错位的情况。

在这里我总结一下使用的规则：

2.          ACE_OutputCDR out(mb);
3.          out  << ?? ;     //这种方法简称out
4.          例一：
5.          如果out 了一个short再out一个long
6.          out << (ACE_CDR::UShort)1;
7.          out << (ACE_CDR:ong)2;
8.          ACE_LOG_MSG->log_hexdump( LM_DEBUG , mb->base() , out.length() , "t");
10.          字节将成为如下排列(16进制)            xx xx ?? ?? xx xx xx xx
11.          其中，问号部分即是因为在long写入时进行的按long长度对齐。该数据是无意义的
12.          
13.          例二：
14.          如果out了一个char再out一个 short
15.          字节将成为如下排列            xx  ??  xx xx
16.          其中，问号部分即是因为在short写入时进行的按short长度对齐。该数据是无意义的
17.          
18.          
19.          例三：
20.          如果out了一个short再out一个char
21.          字节将成为如下排列            xx  xx    xx
22.          这里输入的char不会造成对齐问题，因为char只有一个字节（都是倍数）
23.          
24.          例四：
25.          如果out了一个short再out一个char 再out 一个 long
26.          字节将成为如下排列            xx  xx  xx  ??  xx  xx  xx  xx
27.          

复制代码

         按照以上可总结出，每out一个类型的数据时，输出流将自动按照这个输入类型的长度序对齐，如果没有对齐，则自动填充。
     导致读数据时产生非常多的问题。（你不见CNPV1中都是强转成ACE_CDR::ULong吗？这下知道了吧）。

解决方案有两种：
方案一：全部一种类型吧！比如全部用ACE_CDR::ULong

    不过这种方法通常不适合实际的应用。让偶动物园墙垮来帮大家解决这个心结。:) 西西，请看下一方案。


方案二：

大家都会觉得这玩意被做出来怎么就不好用呢？没道理吧。我也觉得没道理，所以为了证实ACE开发者都是大牛，偶就把ACE的代码挖出来给大家看看，
看看这里到底有着什么样的玄机？

我们就拿ACE_ULong来开刀：

大家翻开CDR_Stream.inl文件，找到以下语句

2. ACE_INLINE ACE_CDR::Boolean
3. operator<< (ACE_OutputCDR &os, ACE_CDR::ULong x)
4. {
5.   os.write_ulong (x);
6.   return (ACE_CDR::Boolean) os.good_bit ();
7. }
9. 继续下去 os.write_ulong (x);
11. ACE_INLINE ACE_CDR::Boolean
12. ACE_OutputCDR::write_ulong (ACE_CDR::ULong x)
13. {
14.   const void *temp = &x;
15.   return this->write_4 (reinterpret_cast<const ACE_CDR::ULong*> (temp));
16. }
18. 继续跟踪this->write_4 (reinterpret_cast<const ACE_CDR::ULong*> (temp));
19. ACE_CDR::Boolean
20. ACE_OutputCDR::write_4 (const ACE_CDR::ULong *x)
21. {
22.   char *buf = 0;
23.   if (this->adjust (ACE_CDR:ONG_SIZE, buf) == 0)
24.     {
25.        ....
26.     }
27. }
29. 再继续adjust (ACE_CDR:ONG_SIZE, buf)
31. ACE_INLINE int
32. ACE_OutputCDR::adjust (size_t size, char*& buf)
33. {
34.   return this->adjust (size, size, buf);
35. }
37. 继续 this->adjust (size, size, buf);
39. ACE_INLINE int
40. ACE_OutputCDR::adjust (size_t size,
41.                        size_t align,
42.                        char*& buf)
43. {
44.   if (!this->current_is_writable_)
45.     return this->grow_and_adjust (size, align, buf);
46. #if !defined (ACE_LACKS_CDR_ALIGNMENT)
47.   const size_t offset =
48.     ACE_align_binary (this->current_alignment_, align)
49.     - this->current_alignment_;
50.   buf = this->current_->wr_ptr () + offset;
51. #else
52.   buf = this->current_->wr_ptr ();
53. #endif /* ACE_LACKS_CDR_ALIGNMENT */
54.   char *end = buf + size;
55.   if (end <= this->current_->end () &&
56.       end >= buf)
57.     {
58. #if !defined (ACE_LACKS_CDR_ALIGNMENT)
59.       this->current_alignment_ += offset + size;
60. #endif /* ACE_LACKS_CDR_ALIGNMENT */
61.       this->current_->wr_ptr (end);
62.       return 0;
63.     }
64.   return this->grow_and_adjust (size, align, buf);
65. }
67. 好！我们找到了，原来校正的代码就在这里！仔细看看
68. #if !defined (ACE_LACKS_CDR_ALIGNMENT)
70. 这里说明，如果你定义了ACE_LACKS_CDR_ALIGNMENT，那么ACE就不会帮你校准对齐字节啦！
72. 哈哈，是不是很兴奋？别着急，让我们动手
74. 打开config.h文件，加入以下一句
75. #define ACE_LACKS_CDR_ALIGNMENT
77. 重新编译ACE，好，将新的lib加入工程
78. （如果你用了aced.dll或ace.dll，注意路径，或把新的dll拷贝到system32目录下）
80. 让我们来运行一下原来的程序
81.          out << (ACE_CDR::UShort)1;
82.          out << (ACE_CDR:ong)2;
83.          ACE_LOG_MSG->log_hexdump( LM_DEBUG , mb->base() , out.length() , "t");
86.          字节将成为如下排列(16进制)            xx xx      xx xx xx xx
88. 哈哈！你再试试以上四个例子，会发现都没有问题了！
90. 那么，从现在开始，你还需要写自己的整编和解编的包装类吗？我看没有必要了吧。还不快动手修改你的工程？
91. 补充：
92. 如果不这么做。那么在接收端用ACE_IntputCDR进行 >> 操作时。如果没有进行读时的强制转换
93. 比如 没有这样写
94. ACE_CDR::Char c;
95. ACE_CDR::UShort s;
96. ACE_InputCDR in(...);
97. in >> (ACE_CDR::ULong)c;
98. in >> (ACE_CDR::ULong)s;
99. 而是这样写：
100. ACE_InputCDR in(...);
101. in >>  c;
102. in >> s;
103. 必出各种字节乱码问题。因为中间多了CORBA的marshaling 与demarshaling对齐数据。
104. 如果按照以上方法重新编译ACE后。即可省事多了（同时也节省了网络流量）
105. ACE_OutputCDR out(..);
106. out << c;
107. out << s;
108. ------------------------------------
109. ACE_InputCDR in(...);
110. in >>  c;
111. in >> s;

复制代码

无须任何类型转换。绝不出错。
再次声明。你不必自己写整编和解编。该论坛多次讨论过该问题。这是一个非常好的解决之道。



[ 本帖最后由 peakzhang 于 2007-12-26 22:28 编辑 ]

peakzhang

疑问1：

（你不见CNPV1中都是强转成ACE_CDR::ULong吗？这下知道了吧）

这个我没有找到，是否所有的都这样转了？

疑问2：

比如 没有这样写

ACE_CDR::Char c;

ACE_CDR::UShort s;

ACE_InputCDR in(...);

in >> (ACE_CDR::ULong)c;

in >> (ACE_CDR::ULong)s;

这样的写法是否有点太强求了，如果你是按照Char和UShort整编的，那只需要使用

in >>  c;

in >> s;

这样的写法就能真确解编。

疑问3：

ACE_LACKS_CDR_ALIGNMENT是用来进行决定是否要对齐操作的，你把他屏蔽了，是否会造成其他后果，比方说网络字节对齐等。

peakzhang

加上ACE_LACKS_CDR_ALIGNMENT宏，应该会影响CORBA，因为默认要8字节对齐。但我们如果不用CORBA，用此宏无妨。
我自己试验过，如果没有此宏，解码的确会出现对齐的错误。

peakzhang

我的实际测试代码：

1. ACE_Message_Block out_mb(1024);
3. ACE_OutputCDR out(&out_mb);
5. out<<(ACE_CDR::UShort)<<1;
7. out<<(ACE_CDR:ong)<<2;
9. out<<(ACE_CDR::Char)<<3;
11. out<<(ACE_CDR::UShort)<<4;
13. out<<(ACE_CDR::UShort)<<5;
15. out<<(ACE_CDR::Char)<<6;
17. out<<(ACE_CDR::UShort)<<7;
19. out<<(ACE_CDR::Char)<<8;
21. out<<(ACE_CDR:ong)<<9;
23. ACE_LOG_MSG->log_hexdump(LM_DEBUG, out_mb.base(), out.length(), "t");
25. ACE_InputCDR in(out);
27. ACE_CDR::UShort a;
29. ACE_CDR:ong b;
31. ACE_CDR::Char c;
33. ACE_CDR::UShort d;
35. ACE_CDR::UShort e;
37. ACE_CDR::Char f;
39. ACE_CDR::UShort g;
41. ACE_CDR::Char h;
43. ACE_CDR:ong i;
45. in >> a;
47. in >> b;
49. in >> c;
51. in >> d;
53. in >> e;
55. in >> f;
57. in >> g;
59. in >> h;
61. in >> i;

复制代码

测试结果：

1.能正确解编

2.

t-HEXDUMP 24 bytes

01 00 cd cd 02 00 00 00 03 cd 04 00 05 00 06 cd

07 00 08 cd 09 00 00 00

peakzhang

我就是说的不用CORBA的情况。ACE_LACKS_CDR_ALIGNMENT这个宏也就是为不用CORBA字节对齐时使用的

peakzhang

回sim。

并不是所有应用都需要对齐字节，不对齐字节并不表示容易出现解码错误。用了该宏，那么在收发两边按照同样的顺序读出，也不需要增加强制类型转换也不会出错。

根据不同的应用选择不同方法