[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk
Subject:    Re: g_strcmp0
From:       Milosz Derezynski <internalerror () gmail ! com>
Date:       2010-08-31 20:38:13
Message-ID: AANLkTik5mURzbEQgz4ybSXSnb53dJXLXueyvKo5bdSaR () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Well, to be honest, the g_ stuff serves as an abstraction layer; I don't
think that currently there is any problem with using the plain C type
instead of the g_ type in this (or other) functions, but for consistency's
sake and for the case that this typedef will become more complex depending
on other platforms supported in the future I would consider this a minor bug
and opt to get it fixed.

2010/8/31 David Nečas <yeti@physics.muni.cz>

> On Mon, Aug 30, 2010 at 10:49:26PM -0300, John Williams wrote:
> > As the documentation
> > (
> http://library.gnome.org/devel/glib/2.24/glib-String-Utility-Functions.html#g-strcmp0
> )
> > the g_strcmp0 requires const char instead const gchar and returns int
> > instead gint.
>
> Does it matter with
>
> typedef char   gchar;
> typedef int    gint;
>
> ?
>
> These types correspond exactly to the standard C types; they are defined
> only for convenience (you can put g- before everything), see their
> documentation.
>
> Yeti
>
> _______________________________________________
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>



-- 
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

[Attachment #5 (text/html)]

Well, to be honest, the g_ stuff serves as an abstraction layer; I don&#39;t think \
that currently there is any problem with using the plain C type instead of the g_ \
type in this (or other) functions, but for consistency&#39;s sake and for the case \
that this typedef will become more complex depending on other platforms supported in \
the future I would consider this a minor bug and opt to get it fixed.<br> <br><div \
class="gmail_quote">2010/8/31 David Nečas <span dir="ltr">&lt;<a \
href="mailto:yeti@physics.muni.cz" \
target="_blank">yeti@physics.muni.cz</a>&gt;</span><br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

<div>On Mon, Aug 30, 2010 at 10:49:26PM -0300, John Williams wrote:<br>
&gt; As the documentation<br>
&gt; (<a href="http://library.gnome.org/devel/glib/2.24/glib-String-Utility-Functions.html#g-strcmp0" \
target="_blank">http://library.gnome.org/devel/glib/2.24/glib-String-Utility-Functions.html#g-strcmp0</a>)<br>
 &gt; the g_strcmp0 requires const char instead const gchar and returns int<br>
&gt; instead gint.<br>
<br>
</div>Does it matter with<br>
<br>
typedef char    gchar;<br>
typedef int      gint;<br>
<br>
?<br>
<br>
These types correspond exactly to the standard C types; they are defined<br>
only for convenience (you can put g- before everything), see their<br>
documentation.<br>
<br>
Yeti<br>
<div><div></div><div><br>
_______________________________________________<br>
gtk-list mailing list<br>
<a href="mailto:gtk-list@gnome.org" target="_blank">gtk-list@gnome.org</a><br>
<a href="http://mail.gnome.org/mailman/listinfo/gtk-list" \
target="_blank">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br> \
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Please note that \
according to the German law on data retention,<br>information on every electronic \
information exchange with me is<br>retained for a period of six months.<br>

[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge<br>jeder \
elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]<br>



_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


[prev in list] [next in list] [prev in thread] [next in thread]