Re: [D3D8 PATCH] d3d8 shaders update - VS2
The best way I know to create block comments *without* tampering with interior comments is like this: /* note about reason for commenting block */ #if 0 code code /* comments */ code #endif
From: Fabian Cenedese <Cenedese(a)indel.ch>
- object->functionLength = 1; /* no Function defined use fixed function vertex processing */ + object->functionLength = 1; // no Function defined use fixed function vertex processing
<nitpick> C++ style comments are strongly discouraged </nitpick>
yes, i know but this comment is INTO a block comment ;) and C comments will break the block comment
What I usually do in such a case is change the existing tags like that:
code /* comment */
becomes (note the spaces in the tags).
/* block comment code / * comment * / */
Like that you still see where the comment was but it doesn't end the block anymore. Of course if the block comment gets removed you have to change the tags back.
bye Fabi
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
The best way I know to create block comments *without* tampering with interior comments is like this:
/* note about reason for commenting block */ #if 0 code code /* comments */ code #endif
Whereas this is the solution with the least work it's also hard to spot. If using a text editor with syntax coloring it all looks the same. But if a code isn't effective I'd like to see that. That's why I really comment it out. But this is just my personal opinion, besides that nothing's wrong with the above. bye Fabi A: No, see http://www.netmeister.org/news/learn2quote.html Q: Should I include quotations after my reply ?
"Fabian Cenedese" <Cenedese(a)indel.ch> wrote:
The best way I know to create block comments *without* tampering with interior comments is like this:
/* note about reason for commenting block */ #if 0 code code /* comments */ code #endif
Whereas this is the solution with the least work it's also hard to spot. If using a text editor with syntax coloring it all looks the same. But if a code isn't effective I'd like to see that.
Actually it could be considered as an editor fault if it changes color for commented out code but doesn't recognize the #if 0/#endif construct. -- Dmitry.
/* note about reason for commenting block */ #if 0 code code /* comments */ code #endif
Whereas this is the solution with the least work it's also hard to spot. If using a text editor with syntax coloring it all looks the same. But if a code isn't effective I'd like to see that.
Actually it could be considered as an editor fault if it changes color for commented out code but doesn't recognize the #if 0/#endif construct.
I wouldn't say so. A comment is easily recognized by the chars /* */ or //. But to get a #if 0 or #if _ANYTHING you really need a language dependant preprocessor which goes beyond a normal text editor, even one with syntax coloring. Do you have such a text editor that finds #if's? bye Fabi
Actually it could be considered as an editor fault if it changes color for commented out code but doesn't recognize the #if 0/#endif construct.
I'd tend to agree... OTOH I don't like colour :-)
I wouldn't say so. A comment is easily recognized by the chars /* */ or //.
No it isn't! You still have to know the language in order to get quoting right. Try editing an m4 source file!
But to get a #if 0 or #if _ANYTHING you really need a language dependant preprocessor which goes beyond a normal text editor, even one with syntax coloring.
The only difficulty is knowing which half of the #if ... #else ... #endif to parse. Parsing both is wrong and will lead to miscoloration.
Do you have such a text editor that finds #if's?
No, and I would use it if I did :-) David -- David Laight: david(a)l8s.co.uk
On December 19, 2002 05:29 am, David Laight wrote:
No, and I would use it if I did :-)
http://www.vim.org -- Dimi.
On Thu, Dec 19, 2002 at 07:08:40AM -0500, Dimitrie O. Paun wrote:
On December 19, 2002 05:29 am, David Laight wrote:
No, and I would use it if I did :-) ^^^ not
Finger trouble...
Probably... David -- David Laight: david(a)l8s.co.uk
On Thursday 19 December 2002 10:14, Fabian Cenedese wrote:
/* note about reason for commenting block */ #if 0 code code /* comments */ code #endif
Whereas this is the solution with the least work it's also hard to
spot. If
using a text editor with syntax coloring it all looks the same. But if a code
isn't
effective I'd like to see that.
Actually it could be considered as an editor fault if it changes color for commented out code but doesn't recognize the #if 0/#endif construct.
I wouldn't say so. A comment is easily recognized by the chars /* */ or //. But to get a #if 0 or #if _ANYTHING you really need a language dependant preprocessor which goes beyond a normal text editor, even one with syntax coloring. Do you have such a text editor that finds #if's?
Yes :) Vim parses #if 0. So #if 0 ... #endif is colored like a comment. Of course that does not mean that all #if -s will be parsed, but IMO only #if 0 should be colored like a comment since other #if -s are not comments. Eg. if you have something like #if defined(__linux__) ... #elif defined(__bsd__) ... #endif You dont want to comment any out any part of the code since all code will be compiled on some OS. Regards Zsolt
participants (6)
-
David Laight -
Dimitrie O. Paun -
Dmitry Timoshkov -
Fabian Cenedese -
Jeff Smith -
Zsolt Rizsanyi