kc@rna.UUCP (Kaare Christian) (01/11/90)
By chance, I've just come across another lawyerly question. Naturally
I've consulted the usual suspects to come up with a clear understanding
of what's what, but haven't had much luck. The topic, C++ aggregate
initializations. From various sources (Stroustrup, Lippman, The Ugly
Reddish Book) it is obvious that C++ initializations are much more
flexible that C's. This capability, while tremendously useful, hasn't
garnered much attention. It is omitted from most lists of "how C++ fixes
up C." Anyway, it is obvious that the following are OK inits:
int f(int); // URB pg 50
int a = 2;
int b = f(a);
The simple question is: does this apply to aggregates? Are the following
legal?
int c[] = { f(0), f(1), f(2) };
struct D { int x; } d = { f(a) };
I can't find a mention of any restriction that says aggregate
initializers must be consts, but this sort of stuff just doesn't
compile with ZTC 2.0.
Kaare Christian
kc@rna.rockefeller.edu
...cmcl2!rna!kcjimad@microsoft.UUCP (JAMES ADCOCK) (01/13/90)
I tried the general case you suggested -- init'ing a int array using
a bunch of int f(int)'s -- and 2.0 complained it can't do that.
Interestingly, the following *does* compile -- it just generates
bad code:
#include <stdio.h>
class INT
{
int i;
public:
INT(int ii) : i(ii) {}
operator int() { return i; }
};
main()
{
INT c[] = { INT(0), INT(1), INT(2) };
printf("%d\n",(int)c[0]);
}comeau@utoday.UUCP (Greg Comeau) (01/13/90)
In article <974@rna.UUCP> kc@rna.UUCP (Kaare Christian) writes: >...C++ aggregate initializations... tremendously useful, hasn't >garnered much attention. It is omitted from most lists of "how C++ fixes >up C." Both points are generally true. >Anyway, it is obvious that the following are OK inits: >int f(int); int a = 2; int b = f(a); // URB pg 50 Absolutely. >The simple question is: does this apply to aggregates? Are the following >legal? >int c[] = { f(0), f(1), f(2) }; >struct D { int x; } d = { f(a) }; >I can't find a mention of any restriction that says aggregate >initializers must be consts, but this sort of stuff just doesn't >compile with ZTC 2.0. the DRM (Draft Reference Manual aka Ugly Reddish Book aka URB) addresses this in 8.4 and since it's not contested in 8.4.1 it's alright as well. Also const !necessarily == constant. I'm interested to see the error messages from Zortech on this. Cfront won't handle the latter cases either, probably because it requires a few special gyrations, but gives "not implemented" error messages. Does anybody know if Oregon accepts these? -- Greg, Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of CC C++, SysAdm columnist for UNIX Today!, Microsoft Systems Journal (C programming), + others. Also, BIX c.language & c.plus.plus conf. moderator. Here:attmail!csanta!greg / BIX:comeau / CIS:72331, 3421 / voice:718-849-2355