有多少种方法可以去掉c代码中的注释？

雨丝风片

这两天看代码的时候碰到了一个结构体，注释多的惊人（当然，这是个好习惯，^_^）。但我要写分析笔记，为了格式好看，于是想如何能够方便地把这些注释去掉。

就以这个结构体为例吧：

1. /* The structure which defines the type of a value.  It should never
   
2.    be possible for a program lval value to survive over a call to the
   
3.    inferior (i.e. to be put into the history list or an internal
   
4.    variable).  */
   
5. 
   
6. struct value
   
7. {
   
8.   /* Type of value; either not an lval, or one of the various
   
9.      different possible kinds of lval.  */
   
10.   enum lval_type lval;
    
11. 
    
12.   /* Is it modifiable?  Only relevant if lval != not_lval.  */
    
13.   int modifiable;
    
14. 
    
15.   /* Location of value (if lval).  */
    
16.   union
    
17.   {
    
18.     /* If lval == lval_memory, this is the address in the inferior.
    
19.        If lval == lval_register, this is the byte offset into the
    
20.        registers structure.  */
    
21.     CORE_ADDR address;
    
22. 
    
23.     /* Pointer to internal variable.  */
    
24.     struct internalvar *internalvar;
    
25. 
    
26.     /* Number of register.  Only used with lval_reg_frame_relative.  */
    
27.     int regnum;
    
28.   } location;
    
29. 
    
30.   /* Describes offset of a value within lval of a structure in bytes.
    
31.      If lval == lval_memory, this is an offset to the address.
    
32.      If lval == lval_register, this is a further offset from
    
33.      location.address within the registers structure.  
    
34.      Note also the member embedded_offset below.  */
    
35.   int offset;
    
36. 
    
37.   /* Only used for bitfields; number of bits contained in them.  */
    
38.   int bitsize;
    
39. 
    
40.   /* Only used for bitfields; position of start of field.
    
41.      For BITS_BIG_ENDIAN=0 targets, it is the position of the LSB.
    
42.      For BITS_BIG_ENDIAN=1 targets, it is the position of the MSB. */
    
43.     int bitpos;
    
44. 
    
45.   /* Frame value is relative to.  In practice, this ID is only used if
    
46.      the value is stored in several registers in other than the
    
47.      current frame, and these registers have not all been saved at the
    
48.      same place in memory.  This will be described in the lval enum
    
49.      above as "lval_reg_frame_relative".  */
    
50.   struct frame_id frame_id;
    
51. 
    
52.   /* Type of the value.  */
    
53.   struct type *type;
    
54. 
    
55.   /* If a value represents a C++ object, then the `type' field gives
    
56.      the object's compile-time type.  If the object actually belongs
    
57.      to some class derived from `type', perhaps with other base
    
58.      classes and additional members, then `type' is just a subobject
    
59.      of the real thing, and the full object is probably larger than
    
60.      `type' would suggest.
    
61. 
    
62.      If `type' is a dynamic class (i.e. one with a vtable), then GDB
    
63.      can actually determine the object's run-time type by looking at
    
64.      the run-time type information in the vtable.  When this
    
65.      information is available, we may elect to read in the entire
    
66.      object, for several reasons:
    
67. 
    
68.      - When printing the value, the user would probably rather see the
    
69.        full object, not just the limited portion apparent from the
    
70.        compile-time type.
    
71. 
    
72.      - If `type' has virtual base classes, then even printing `type'
    
73.        alone may require reaching outside the `type' portion of the
    
74.        object to wherever the virtual base class has been stored.
    
75. 
    
76.      When we store the entire object, `enclosing_type' is the run-time
    
77.      type -- the complete object -- and `embedded_offset' is the
    
78.      offset of `type' within that larger type, in bytes.  The
    
79.      VALUE_CONTENTS macro takes `embedded_offset' into account, so
    
80.      most GDB code continues to see the `type' portion of the value,
    
81.      just as the inferior would.
    
82. 
    
83.      If `type' is a pointer to an object, then `enclosing_type' is a
    
84.      pointer to the object's run-time type, and `pointed_to_offset' is
    
85.      the offset in bytes from the full object to the pointed-to object
    
86.      -- that is, the value `embedded_offset' would have if we
    
87.      followed the pointer and fetched the complete object.  (I don't
    
88.      really see the point.  Why not just determine the run-time type
    
89.      when you indirect, and avoid the special case?  The contents
    
90.      don't matter until you indirect anyway.)
    
91. 
    
92.      If we're not doing anything fancy, `enclosing_type' is equal to
    
93.      `type', and `embedded_offset' is zero, so everything works
    
94.      normally.  */
    
95.     struct type *enclosing_type;
    
96.     int embedded_offset;
    
97.     int pointed_to_offset;
    
98. 
    
99.     /* Values are stored in a chain, so that they can be deleted
    
100.        easily over calls to the inferior.  Values assigned to internal
     
101.        variables or put into the value history are taken off this
     
102.        list.  */
     
103.     struct value *next;
     
104. 
     
105.     /* Register number if the value is from a register.  */
     
106.     short regno;
     
107. 
     
108.     /* If zero, contents of this value are in the contents field.  If
     
109.        nonzero, contents are in inferior memory at address in the
     
110.        location.address field plus the offset field (and the lval
     
111.        field should be lval_memory).
     
112. 
     
113.        WARNING: This field is used by the code which handles
     
114.        watchpoints (see breakpoint.c) to decide whether a particular
     
115.        value can be watched by hardware watchpoints.  If the lazy flag
     
116.        is set for some member of a value chain, it is assumed that
     
117.        this member of the chain doesn't need to be watched as part of
     
118.        watching the value itself.  This is how GDB avoids watching the
     
119.        entire struct or array when the user wants to watch a single
     
120.        struct member or array element.  If you ever change the way
     
121.        lazy flag is set and reset, be sure to consider this use as
     
122.        well!  */
     
123.     char lazy;
     
124. 
     
125.     /* If nonzero, this is the value of a variable which does not
     
126.        actually exist in the program.  */
     
127.     char optimized_out;
     
128. 
     
129.     /* The BFD section associated with this value.  */
     
130.     asection *bfd_section;
     
131. 
     
132.     /* Actual contents of the value.  For use of this value; setting
     
133.        it uses the stuff above.  Not valid if lazy is nonzero.
     
134.        Target byte-order.  We force it to be aligned properly for any
     
135.        possible value.  Note that a value therefore extends beyond
     
136.        what is declared here.  */
     
137.     union
     
138.     {
     
139.       long contents[1];
     
140.       DOUBLEST force_doublest_align;
     
141.       LONGEST force_longest_align;
     
142.       CORE_ADDR force_core_addr_align;
     
143.       void *force_pointer_align;
     
144.     } aligner;
     
145.     /* Do not add any new members here -- contents above will trash them.  */
     
146. };

复制代码

希望编辑之后的效果就是：

1. struct value
   
2. {
   
3.     enum lval_type lval;
   
4.     int modifiable;
   
5.     union
   
6.     {
   
7.         CORE_ADDR address;
   
8.         struct internalvar *internalvar;
   
9.         int regnum;
   
10.     } location;
    
11.     int offset;
    
12.     int bitsize;
    
13.     int bitpos;
    
14.     struct frame_id frame_id;
    
15.     struct type *type;
    
16.     struct type *enclosing_type;
    
17.     int embedded_offset;
    
18.     int pointed_to_offset;
    
19.     struct value *next;
    
20.     short regno;
    
21.     char lazy;
    
22.     char optimized_out;
    
23.     asection *bfd_section;
    
24.     union
    
25.     {
    
26.         long contents[1];
    
27.         DOUBLEST force_doublest_align;
    
28.         LONGEST force_longest_align;
    
29.         CORE_ADDR force_core_addr_align;
    
30.         void *force_pointer_align;
    
31.     } aligner;
    
32. };

复制代码

请问各位都知道哪些方法可以完成这个任务？欢迎举报！
如果各位想到了方法，麻烦准确地描述一下操作步骤，我好学习，

在文本编辑器中使用普通方式进行删除统一归为一种方法（不管你是用vim的“x”还是其它编辑器的“Del”，），但如果能在文本编辑器中使用诸如独特的正则表达式等“快捷”操作来完成任务的，则可算是一种独立的方法。

希望能够借此学习一下各种文本编辑器和脚本语言的特性，所以希望大家不吝赐教！

我先写了一个awk脚本来完成这个任务：
awkfile:

1. BEGIN { del = 0 }
   
2. /\/\*/ { del = 1 }
   
3. /\*\// { del = 0; next }
   
4. del == 0 && /^.+$/{ print }

复制代码

实验结果如下，假设上述结构体的代码放在value文件中：

1. [~]$
   
2. [~]$ cat awkfile
   
3. BEGIN { del = 0 }
   
4. /\/\*/ { del = 1 }
   
5. /\*\// { del = 0; next }
   
6. del == 0 && /^.+$/{ print }
   
7. [~]$
   
8. [~]$
   
9. [~]$ awk -f awkfile value
   
10. struct value
    
11. {
    
12.     enum lval_type lval;
    
13.     int modifiable;
    
14.     union
    
15.     {
    
16.         CORE_ADDR address;
    
17.         struct internalvar *internalvar;
    
18.         int regnum;
    
19.     } location;
    
20.     int offset;
    
21.     int bitsize;
    
22.     int bitpos;
    
23.     struct frame_id frame_id;
    
24.     struct type *type;
    
25.     struct type *enclosing_type;
    
26.     int embedded_offset;
    
27.     int pointed_to_offset;
    
28.     struct value *next;
    
29.     short regno;
    
30.     char lazy;
    
31.     char optimized_out;
    
32.     asection *bfd_section;
    
33.     union
    
34.     {
    
35.         long contents[1];
    
36.         DOUBLEST force_doublest_align;
    
37.         LONGEST force_longest_align;
    
38.         CORE_ADDR force_core_addr_align;
    
39.         void *force_pointer_align;
    
40.     } aligner;
    
41. };
    
42. [~]$
    
43. [~]$

复制代码

[ 本帖最后由 雨丝风片 于 2006-10-24 11:29 编辑 ]

雨丝风片

我举的结构体的例子有一个特殊之处，就是它的代码和注释没有混杂在同一行内，因此我写的脚本也只能处理这种情况。期待各位给出能够处理代码和注释混杂在同一行内的情况的方法。

congli

学习ing ^_^

雨丝风片

原帖由 congli 于 2006-10-24 11:40 发表
学习ing ^_^

是我学习ing！你们赶快想想有没有其它的方法，^_^

Macolex

用Perl或者PHP的正则表达式。

你去php版问问写过采集的，应该是小菜。

（不过我不会）

雨丝风片

原帖由 Macolex 于 2006-10-24 11:59 发表
用Perl或者PHP的正则表达式。

你去php版问问写过采集的，应该是小菜。

（不过我不会）

哦，最好是有现成的方法推荐过来哈！
我的目的之一也是想看看不同的脚本语言在完成这个任务时的优缺点如何，

antijp

这个脚本怎么处理"/**/"？

似乎要正确处理所有的情况是很麻烦的……

大大狗

perl正则可以实现，但我还没学到这呢

雨丝风片

原帖由 antijp 于 2006-10-24 13:37 发表
这个脚本怎么处理"/**/"？

似乎要正确处理所有的情况是很麻烦的……

如果是一行之内只有/*... */的话，前面的脚本已经能够处理了，只是它无法处理c代码和注释在一行之内混杂的情况。我新写了一个awk脚本：

1. BEGIN { del = 0 }
   
2. /\/\*.*\*\// { sub(/\/\*.*\*\//, "") }
   
3. /\/\*/ { del = 1 }
   
4. /\*\// { del = 0; next }
   
5. /^ *$/ { next }
   
6. del == 0 { print }

复制代码

这个脚本可以去掉下面四种形式的注释：

1. 
   
2. /* aaaaaaaaaaaaaaaaaaaaaaaaa
   
3.    bbbbbbbbbbbbbbbbbbbbbbbbb
   
4.    ccccccccccccccccccccccccc */
   
5. 
   
6. /* ddddddddddddddddddddddddd */
   
7. 
   
8. int foo; /* eeeeeeeeeeeeeeeee */
   
9. 
   
10. /* ffffffffffffffff */  int bar;
    

复制代码

但还处理不了下面这种形式的注释：

1. 
   
2. int foobar; /* fffffffffffffffff
   
3.                ggggggggggggggggg */
   

复制代码

[ 本帖最后由 雨丝风片 于 2006-10-24 15:02 编辑 ]

雨丝风片

原帖由 大大狗 于 2006-10-24 14:10 发表
perl正则可以实现，但我还没学到这呢

不是可不可以实现的问题，是大家都能想到哪些具体方法来实现，并比较这些方法的各自特点的问题。
如果编写脚本来完成整个任务，多半是离不开正则表达式的，这跟用不用perl到没什么关系，但不排除
不同语言之间的正则表达式等方面的差异会对这个问题的求解产生可观的影响，所以这个问题才很有
探究的意义。

我写的awk脚本也用到了“正则”，