You are right, sed is the correct tool for virtually absolutely everything, including what you want to do. ;-))
Here is the naive approach, which will work on your example:
sed 's/\/\*.*\*\///' /path/to/file > /out/put/file
The (conceivable) problem with this approach is that regexps are "greedy", which means that always the longest-possible match is selected. That means: the above regexp selects "/", followed by any number of any characters, followed by "/". In case you have several comments in one line like this:
some_code; /* comment */ some_more; /* other comment */
The regexp would match the text marked in bold:
some_code; /* comment */ some_more; /* other comment */
In case you need to take care of this (perhaps rather rare) possibility you will have to refine the way you match the characters in between the introductory comment sequence and the comment-end-sequence. For instance:
sed 's/\/\*[^/*]*\*\///g' /path/to/file > /out/put/file
This will match "/", followed by any number of any characters save for "/" or "", followed by a "/". This is better and will work on the previous example but will be fooled if a single "/" or "" appears in the comments like this input:
You can put more work into it and refine the regexp even further but ultimately there will be (in a strict sense) no solution to your problem because a regexp engine (like sed is in the core) cannot replace a parser. See here for a more thorough discussion of this subject.
You are right: non-greedy matching takes care of a few cases. Still, what i said about regexps being unable to parse still stands. For instance, your perl-program would have problems with:
char foo[3]="/*"; char bar[3]="*/"; /* comment */
I admit, this (and some more cases i could cite) are fringe. Maybe the thread-O/P will never encounter any of these. But again, it is - in a strict sense - impossible to overcome all of these problems (some of them, yes, but not all) because a regexp engine cannot work as a parser.