Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Dinamic array without malloc - Can be done? Date: Mon, 30 Jan 2017 11:35:44 -0800 Organization: None to speak of Lines: 61 Message-ID: References: <863e4550-027a-4d32-b5df-e34f2c7b4439@googlegroups.com> <87a8asjdiw.fsf@bsb.me.uk> <8087f1de-3ea6-f75e-5c3b-a64efe6a7d84@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="a9fae22b5f567322e337da4e19df7ab9"; logging-data="25319"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QG4GJUkDMJ9aGsshS7SND" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:b26E/UCu596CDfwCc6Ibqrc8dWI= sha1:tG9EmfgZM/ScxIhjwphWN9zN08I= Xref: csiph.com comp.lang.c:102784 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >>>> In C99, complex types are mandatory, but the header >>>> is required only for hosted implementations. That meant that a >>>> freestanding implementation must support the types _Complex >>>> float, _Complex double, and _Complex long double, but without >>>> there's no portable way to specify the value of i. >>> >>> What isn't portable about this? >>> >>> typedef _Complex float Zfloat; >>> >>> Zfloat >>> imaginary_unit(){ >>> return (union {float f[2]; Zfloat z;}){ {0,1} }.z; >>> } >> >> OK, no *clean* portable way. > > I'm not sure if this response is meant to be funny, but if it > isn't, what isn't clean about this way of providing i? It can't > be used to initialize file scope or static varibles, but other > than that what's wrong with it? (I'm assuming the function would > be defined as 'static inline' if that were thought important.) The language provides complex types, but the core language doesn't provide a direct way to specify the value of i, the most fundamental mathematical complex constant that isn't a real number. A function that takes advantage of an incidental guarantee about the *representation* of complex types to construct the value of i is clever and useful, but IMHO it's hardly clean. (Perhaps that guarantee is intended to permit this kind of thing.) IMHO the language *should* have provided a simpler way to specify the value of i. Perhaps the semantics of compound literals could have been extended to permit complex values, such as (float _Complex){0.0, 1.0}; Imagine a language that provides floating-point types but has no way to write a constant expression with the value -1.0. Some kind of union hack that fiddles with the sign bit might be workable, but I'd hardly consider it satisfactory. > Note by the way that freestanding implementations are not obliged > to support complex types, even in C99, by virtue of section 4 p6. Ah, you're right, I missed that. That blows most of my argument out of the water. Any C99 conforming hosted implementation (and any C11 conforming hosted implementation that doesn't predefine __STDC_NO_COMPLEX__) must support both the _Complex keyword and the _Complex_I macro, so it's not as bad as I thought it was. I suppose my remaining objection is mainly esthetic. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"