[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] casting to igraph_real_t

From: Gábor Csárdi
Subject: Re: [igraph] casting to igraph_real_t
Date: Tue, 26 Jun 2012 21:53:44 -0400

On Tue, Jun 26, 2012 at 5:55 PM, Murat Tasan <address@hidden> wrote:
> hi all - i just started using the igraph C library, and noticed that i
> can't seem to find a function to reliably cast various C types to the
> corresponding igraph_X_t type.
> just as an example, i'm currently relying on what i've found in the
> igraph_types.h to simply do things like:
> extern double *edgelist; // declared/defined in an external library
> that i can't control.
> extern int edgelist_length;
> igraph_vector_t v;
> igraph_vector_view(&v, edgelist, edgelist_length);
> ... since igraph_real_t is defined as a double in igraph_types.h.
> this doesn't seem quite safe to me, however, as if the igraph library
> changes in the future quite a few things will break (in my code at
> least).

You are right, and this is not safe. You should at least check that
igraph_real_t and double have the same size.

> i was somewhat expecting to find a series of casting functions, e.g.
> as_igraph_real_t(int x), that would serve as a one-stop location for
> moving between igraph types and standard C types, but if it does
> exist, i can't seem to locate it.

There are no functions for this, because whatever igraph_real_t might
be, it will be a basic type and you can do the casting the usual C
way, i.e.:

igraph_real_t ir;
double d= (double) igraph_real_t;

> do most folks here just use basic casting as the short code above, or
> is there an accepted more uniform method?

There is no casting in the code above. More precisely you are only
casting pointers, which will not work as soon as igraph_real_t will be
different than double. However, to be realistic, the chance for
changing igraph_real_t in the near-medium future is very very slim.


> such a series of casting functions would also make it easier to modify
> a single module of code in the future in case the underlying types
> change (rather than track down all the explicit and implicit casts
> through the rest of all programs using the igraph library).
> cheers,
> -murat
> _______________________________________________
> igraph-help mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/igraph-help

Gabor Csardi <address@hidden>     MTA KFKI RMKI

reply via email to

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