Including */ in a C-style block comment

Question

Is there any way to include */ in a C-style block comment? Changing the block comment to a series of line comments (//) is not an option in this case.

Here's an example of the sort of comment causing a problem:

/**
 * perl -pe 's/(?<=.{6}).*//g' : Limit to PID
 */

Softener

In this particular example, there are of course many other ways of writing equivalent regular expressions or equivalent commands that wouldn't require that character combination. – Gazetteer

@Reb Kennedy: You're correct, but it seems silly to modify the functionality just so that it will fit inside a comment. – Softener

Thanks for asking this question; the accepted answer is a real eye-opener. – Sleight

Why is changing the block comment to a series of line comments not an option? – Raptorial

bk1e, hey u got a great idea i think. if / causes problems, then why not just close before the offending line, then do with "//" and then reintroduce / ... */ test – Chicane

@bk1e: Mandatory, overly-specific code formatting guidelines, of course. And yes, I'm aware that's an oxymoron. – Softener

Answer 1

Usually comments don't need to be literal, so this doesn't come up too often.

You can wrap it all in a #if block:

#if 0
whatever you want can go here, comments or not
#endif

Alisaalisan

This seems like such an abuse of preprocessor commands, but it does get the job done. – Softener

It comes with the territory. C was made to be abused. – Alisaalisan

Sneaky it may be, but this is extremely common! – Grampus

Common enough that some editors understand the notation and highlight everything between #if 0 and #endif as a comment. – Affective

i use #if 0 for commenting out code blocks. The things within #if 0 must be valid preprocessor tokens. Not too easy to find a violation, since the preprocessor will eat much stuff that's only later in the "real" phases either rejected or accepted. But try putting "\ " within between them. Errors out with gcc ("backslash and newline separated by space"), while putting "/*" errors out with comeau ("comment not closed at end of file"). But for commenting out code, this is optimal imo. – Chicane

Answer 2

Nope! There isn't.

Supinate

Sometimes the simple answers are the best – Subversive

Answer 3

You can side-step the issue by munging your regex to not include the offending sequence of characters. From the looks of what you're doing, this should should work (make the * non-greedy):

/**
 * perl -pe 's/(?<=.{6}).*?//g' : Limit to PID
 */

Eaglet

Is this C question going to turn into a JAPH session? ;-) – Phosphorylase

Answer 4

In the general case, you can't.

Here's a tricky answer that happens to work in this case:

/**
 * perl -pe 's/(?<=.{6}).* //gx' : Limit to PID
 */

This is (or should be, I didn't actually test the perl command) a regex that matches the same as the original because the x modifier allows whitespace to be used for clarity in the expression, which allows the * to be separated from the /.

You could use more whitespace, I've included just the single space that breaks the end of comment block token.

Some compilers support an option to turn on the non-standard feature of allowing nested comments. This is usually a bad idea, but in this particular case you could also do

/** 
 * /* perl -pe 's/(?<=.{6}).*//g' : Limit to PID
 */

with that option turned on for just this source file. Of course as demonstrated by the funky coloring in the above fragment, the rest of your tools may not know what you are up to and will make incorrect guesses.

Phosphorylase

Answer 5

For this specific case, you can change the delimiter on your perl regex. You can use any non-alphanumeric, non-whitespace delimiter. Here I switched to #:

/** 
 * perl -pe 's#(?<=.{6}).*##g' : Limit to PID
 */

Common choices are # and %.

'Bracketing characters' like parens or braces get a slightly different syntax, because they are expected to be matched pairs:

/** 
 * perl -pe 's[(?<=.{6}).*][]g' : Limit to PID
 */

Nudity