bug-gsl
[Top][All Lists]
Advanced

[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.
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]