RE: C++ static integer class constants...

["John Ratliff" <webmaster at technoplaza dot net>]

I forgot to hit reply to all, but I wanted this to go to the list.

> After reading Ryan's post, I looked at the (draft) standard.  It says:
> 
> 4 If  a  static  data  member  is of const integral or const enumeration
>   type, its declaration in the class definition can specify a  constant-
>   initializer   which   shall   be   an   integral  constant  expression
>   (_expr.const_).  In that case, the member can appear in integral  con-
>   stant expressions within its scope.  The member shall still be defined
>   in a namespace scope if it is used in the program  and  the  namespace
>   scope definition shall not contain an initializer.
> 
> If I understand this correctly, even const static members need to have 
> a definition somewhere.  Maybe this is "needed" so that you may always 
> take the address of such const static members.
> 
> So the compiler is free to use the constant as if they were variables, 
> if it needs to.  Your code compiles OK if the line
> 
>         int offset = (redundant ? B : A);
> 
> is replaced by
> 
>         if(redundant)
>           offset = B;
>         else
>           offset = A;
> 
> I don't know why, but it does work here.

This seems like a definite bug. The fact that it works in 3.4.2 and not in
3.3.3 seems like a probable bug to me, but I will ask this question in a
standard C++ newsgroup so that someone intimately familiar with the standard
can give me a definitive answer, but I still think g++ 3.3 is wrong and g++
3.4 is right.

If I were taking the address of the constant, sure, it would have to have
storage space and I wouldn't expect it any other way.

I was looking at the assembly generated by each compiler. There is a
striking difference. Here is foo::method(bool redundant) in x86 assembly
generated by mingw/g++ 3.4.2. I have commented the relevant sections.

-----------------------------------------------
.globl __ZNK3foo6methodEb
	.def	__ZNK3foo6methodEb;	.scl	2;	.type	32;
.endef
__ZNK3foo6methodEb:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$40, %esp
	movl	12(%ebp), %eax
	movb	%al, -1(%ebp)    ; move redundant (%al) to stack
	cmpb	$0, -1(%ebp)     ; if redundant is false 
	je	L12              ; goto L12
	movl	$8184, -16(%ebp) ; move 8184 (0x1FF8) into -16(%ebp) (aka
offset)
	jmp	L13              ; goto L13
L12:
	movl	$8, -16(%ebp)    ; move 8 into offset
L13:
	movl	-16(%ebp), %eax  ; return std::pair blah blah blah
	movl	%eax, -8(%ebp)
	movl	8(%ebp), %eax
	addl	-8(%ebp), %eax
	incl	%eax
	movzbl	(%eax), %eax
	movb	%al, -11(%ebp)
	leal	-11(%ebp), %eax
	movl	%eax, 8(%esp)
	movl	8(%ebp), %edx
	movl	-8(%ebp), %eax
	movzbl	(%eax,%edx), %eax
	movb	%al, -12(%ebp)
	leal	-12(%ebp), %eax
	movl	%eax, 4(%esp)
	leal	-10(%ebp), %eax
	movl	%eax, (%esp)
	call	__ZNSt4pairIhhEC1ERKhS2_
	movzwl	-10(%ebp), %eax
	leave
	ret
-----------------------------------------------

And here is g++ 3.3.3's assembly output. As you can see, it's not even
trying to use it as a constant. This is why storage space is required.

-----------------------------------------------
_ZNK3foo6methodEb:
.LFB1535:
	pushl	%ebp
.LCFI14:
	movl	%esp, %ebp
.LCFI15:
	subl	$24, %esp
.LCFI16:
	movl	16(%ebp), %eax
	movb	%al, -1(%ebp)    ; move al (redundant) to stack
	cmpb	$0, -1(%ebp)     ; is redundant false?
	je	.L6              ; then jump to .L6
	movl	_ZN3foo1BE, %eax ; move B (storage space required) to eax
	movl	%eax, -16(%ebp)  ; put eax on the stack
	jmp	.L7
.L6:
	movl	_ZN3foo1AE, %eax ; move A (storage space required) to eax
	movl	%eax, -16(%ebp)  ; and put eax on the stack
.L7:
	movl	-16(%ebp), %eax  ; ??? why is it moving it just to move it
back?
	movl	%eax, -8(%ebp)   ; whatever, the rest is return std::pair
blah blah
	subl	$4, %esp
	movl	12(%ebp), %eax
	addl	-8(%ebp), %eax
	incl	%eax
	movb	(%eax), %al
	movb	%al, -9(%ebp)
	leal	-9(%ebp), %eax
	pushl	%eax
	movl	12(%ebp), %edx
	movl	-8(%ebp), %eax
	movb	(%eax,%edx), %al
	movb	%al, -10(%ebp)
	leal	-10(%ebp), %eax
	pushl	%eax
	pushl	8(%ebp)
.LCFI17:
	call	_ZNSt4pairIhhEC1ERKhS2_
	addl	$16, %esp
	movl	8(%ebp), %eax
	leave
	ret	$4
-----------------------------------------------

If you replace the ternary operator with the if as you suggested, the
assembly looks more like the 3.4.2 version. This is why it compiles, and
makes it seem more and more like a bug. Clearly it's capable of doing what I
think it should do, but chooses not to when presented with the ternary
operator.

> 
> So you need to define those constants somewhere, but the compiler  may 
> use the initializer in the class scope, if it is able to do so.  For 
> some reason, GCC couldn't use the initializer in the first case, so it 
> is using the address of the constants.  Go figure.

The assembly output and changing from ternary to if proves it can use the
initializer, but chooses not to.

Thanks,

--John Ratliff