[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #57173] Feature request: zeta function for complex arguments
From: |
Patrick Alken |
Subject: |
Re: [bug #57173] Feature request: zeta function for complex arguments |
Date: |
Tue, 5 Nov 2019 20:25:18 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
This brings up an issue which I've wondered about for a while. GSL
currently conforms to the c89 standard. I believe the previous
maintainer (Brian) wanted this so that users on older/legacy systems
could continue to use GSL. I have continued this tradition, and for
every release, I make sure GSL will compile with -std=c89.
If we begin using features of later C standards (c99, c11, etc), then
GSL will no longer compile with -std=c89.
I guess the question is whether we want to continue to support c89, or
abandon it in favor of newer features of C.
Patrick
On 11/5/19 1:20 PM, Gerard Jungman wrote:
> On 11/5/19 11:26 AM, Mark Galassi wrote:
>>>>>>> "Patrick" == Patrick Alken <address@hidden> writes:
>>
>>
>> Patrick> I don't think any progress was made on this
>>
>> One update to the discussion from back then is that C++11 has formalized
>> data compatibilty between the C11 _Complex type and the C++ complex
>> class. This also raises the architectural question of whether GSL might
>> want to use C's complex type.
>
> Although, strangely enough, they made support for
> complex types optional. Does anybody know the
> rationale for this decision? This kind of
> back-peddling seems very strange.
>
> I have been using the new types myself in C code,
> for several years. Of course, gcc and clang are not
> going to drop support for the types. But I worry that
> this "optionality" means they may not get the love
> and attention they need. Or worse, that something
> weird might happen leading to a divergence of
> implementations.
>
>
> It would be good to move to the standard, if we know
> it is not going to deteriorate in some way, and that
> there are no hidden issues with the implementations
> as they exist now. There are some weird hidden
> issues, like the meaning and consequences of
> the CX_LIMITED_RANGE pragma.
>
> At the very least, it would be good to read the normative
> parts carefully. Annex G of either the c17 draft standard
> (n2176) or the c11 draft standard (n1570). The two seem
> to be identical, but I have not taken out a microscope.
>