[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: C99 complex types in Glib
From: CaStarCo <castarco () gmail ! com>
Date: 2010-12-11 6:52:42
Message-ID: AANLkTimRu4o0mgsC8yvZUJgRr8ZuPHbsda+=uqNupfqd () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello :)
2010/12/11 Emmanuele Bassi <ebassi@gmail.com>
>
> hi;
>
> glib development is discussed on the gtk-devel mailing list, but I can
> directly answer to you right now.
>
> On Sat, 2010-12-11 at 00:19 +0100, CaStarCo wrote:
>
> > I write here because i have many doubts and because i want to
> > contribute with my code to the Glib library ^^ .
>
> cool, contributions are much welcome...
>
> > The first doubt is : The Glib project is using the C99 spec or the C89
> > spec?
>
> for portability reasons, GLib follows the C89 spec. the C99 spec is not
> fully implemented by all compilers on all platforms we're tracking, so
> it cannot be used.
>
> > If it's the second case... there is any way to contribute to Glib
> > adding support to the complex floating point types that C99 introduced
> > in the year 2000 ?
>
> honestly, I doubt this is a compelling enough use case to introduce new
> types; applications that require complex floating point types will also
> require other ad hoc facilities that GLib does not provide.
>
I don't think so :p , one usage example: extending the Vala language, in any
case, the complex.h header provides simple functions to work with complex
numbers.
Another usage example: simplify the code of, for example, gcalctool.
In any case, if the reasons of not extending Glib are related with
compatibility, that's a stronger reason :) .
>
> nevertheless, if new types have been introduced and if they can be
> checked at configure-time, then they may be supported by wrapping them,
> in to provide a graceful degradation path.
>
>
I have a doubt about that. To introduce a type following the way you
described... I must create another "mini library" inside the Glib?
> code contributions for GLib go through Bugzilla:
>
> http://bugzilla.gnome.org/enter_bug.cgi?product=glib
>
> ciao,
> Emmanuele.
>
>
>
Thanks for your atention!
--
- Per la llibertat del coneixement -
- Per la llibertat de la ment... -
[Attachment #5 (text/html)]
Hello :)<br><br><div class="gmail_quote">2010/12/11 Emmanuele Bassi <span \
dir="ltr"><<a href="mailto:ebassi@gmail.com">ebassi@gmail.com</a>></span><br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">
<br>
hi;<br>
<br>
glib development is discussed on the gtk-devel mailing list, but I can<br>
directly answer to you right now.<br>
<div class="im"><br>
On Sat, 2010-12-11 at 00:19 +0100, CaStarCo wrote:<br>
<br>
> I write here because i have many doubts and because i want to<br>
> contribute with my code to the Glib library ^^ .<br>
<br>
</div>cool, contributions are much welcome...<br>
<div class="im"><br>
> The first doubt is : The Glib project is using the C99 spec or the C89<br>
> spec?<br>
<br>
</div>for portability reasons, GLib follows the C89 spec. the C99 spec is not<br>
fully implemented by all compilers on all platforms we're tracking, so<br>
it cannot be used.<br>
<div class="im"><br>
> If it's the second case... there is any way to contribute to Glib<br>
> adding support to the complex floating point types that C99 introduced<br>
> in the year 2000 ?<br>
<br>
</div>honestly, I doubt this is a compelling enough use case to introduce new<br>
types; applications that require complex floating point types will also<br>
require other ad hoc facilities that GLib does not \
provide.<br></blockquote><div><br></div><div>I don't think so :p , one usage \
example: extending the Vala language, in any case, the complex.h header provides \
simple functions to work with complex numbers.</div>
<div><br></div><div>Another usage example: simplify the code of, for example, \
gcalctool.</div><div><br></div><div>In any case, if the reasons of not extending Glib \
are related with compatibility, that's a stronger reason :) .</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <br>
nevertheless, if new types have been introduced and if they can be<br>
checked at configure-time, then they may be supported by wrapping them,<br>
in to provide a graceful degradation path.<br>
<br></blockquote><div><br></div><div>I have a doubt about that. To introduce a type \
following the way you described... I must create another "mini library" \
inside the Glib?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
code contributions for GLib go through Bugzilla:<br>
<br>
<a href="http://bugzilla.gnome.org/enter_bug.cgi?product=glib" \
target="_blank">http://bugzilla.gnome.org/enter_bug.cgi?product=glib</a><br> <br>
ciao,<br>
Emmanuele.<br>
<font color="#888888"><br><br>
</font></blockquote></div><div><br></div>Thanks for your atention! <br \
clear="all"><br>-- <br>- Per la llibertat del coneixement -<br>- Per la llibertat de \
la ment... -<br>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic