On Thu, 29 Oct 2009 23:26:39 -0500, Ellery Newcomer
<ellery-newco...@utulsa.edu> wrote:
Phil Deets wrote:
I put the comma inside the version block because then there wouldn't be
duplicate commas if the version was removed. If the version number was 6
in the above example, it would evaluate to "A, B, C, D, E," with my way,
but
enum Tag
{
A, B, C,
version (5) {
D, E
},
version (7) {
F, G
},
// ...
}
would evaluate to "A, B, C, D, E, ," which has two commas in a row.
However, you could keep version blocks separated with commas if you
specialized the enum grammar specifically for version blocks, which
might be the right way to go.
It really doesn't matter. By the time you get around to evaluating the
version condition, you'll have thrown away all those commas anyways. All
that matters is that you can clearly distinguish the members. However,
it will be simpler to implement (and express in ebnf) if you separate
versions/members with commas. Like
enumBody -> { enumMembers }
enumMembers -> enumMember , enumMembers
enumMembers -> enumMember ,
enumMembers -> enumMember
enumMember -> Identifier
enumMember -> Identifier = AsgExp
enumMember -> ccCondition enumBody
Good point. That makes sense when I think of it that way. I was thinking
in a preprocessor mindset where the text had to make sense if the version
just disappeared like the text does with the C preprocessor.
