Function factories

Discussion in 'C Programming' started by Edward Rutherford, Aug 21, 2012.

  1. Hello

    I want to make a factory that produces other functions according to a
    parameter.

    The following code does not compile:

    typedef int *(foo)(int);

    foo adder_factory(int x)
    {
    int f(int a)
    {
    return a + x;
    }
    return &f;
    }

    The idea is that adder_factor(42) should be a function that adds 42 to
    whatever it gets passed.

    What's the right way of doing this in C? How can I get closures or
    something similar in C?
    Edward Rutherford, Aug 21, 2012
    #1
    1. Advertising

  2. Edward Rutherford

    Nobody Guest

    On Tue, 21 Aug 2012 20:36:31 +0000, Edward Rutherford wrote:

    > I want to make a factory that produces other functions according to a
    > parameter.
    >
    > The following code does not compile:
    >
    > typedef int *(foo)(int);
    >
    > foo adder_factory(int x)
    > {
    > int f(int a)
    > {
    > return a + x;
    > }
    > return &f;
    > }


    C does not have inner functions or closures.

    > The idea is that adder_factor(42) should be a function that adds 42 to
    > whatever it gets passed.
    >
    > What's the right way of doing this in C? How can I get closures or
    > something similar in C?


    typedef struct foo {
    int (*func)(const struct foo *, int);
    int param;
    } *foo;

    static int adder(const struct foo *closure, int x) {
    return closure->param + x;
    }

    foo adder_factory(int x)
    {
    foo p = malloc(sizeof(*p));
    p->func = adder;
    p->param = x;
    return p;
    }

    #define call_foo(f, x) ((f)->func((f), (x))
    Nobody, Aug 21, 2012
    #2
    1. Advertising

  3. On Aug 22, 7:34 am, David Brown <>
    wrote:
    > On 21/08/2012 22:36, Edward Rutherford wrote:
    >
    >
    >
    >
    >
    > > Hello

    >
    > > I want to make a factory that produces other functions according to a
    > > parameter.

    >
    > > The following code does not compile:

    >
    > > typedef int *(foo)(int);

    >
    > > foo adder_factory(int x)
    > > {
    > >    int f(int a)
    > >    {
    > >      return a + x;
    > >    }
    > >    return &f;
    > > }

    >
    > > The idea is that adder_factor(42) should be a function that adds 42 to
    > > whatever it gets passed.

    >
    > > What's the right way of doing this in C? How can I get closures or
    > > something similar in C?

    >
    > You can't.
    >
    > You can get sort-of simulated closures in complicated and verbose ways,
    > but there is no good way to do it.  gcc supports nested functions as an
    > extension to C, but that won't give you closures like this.
    >
    > If you want to stick close to C, then C++11 supports lambda functions
    > and closures.
    >
    > If you want to write code that makes strong use of closures in the
    > style, then use a programming language that supports it.  The latest C++
    > standard will get you the basics, but if you want to write code in a
    > more functional programming style, there are much better languages to
    > work with (ocaml, python, haskell, etc.)


    scheme

    (and does Python have particularly good support for functional
    programming?)
    Nick Keighley, Aug 22, 2012
    #3
  4. Edward Rutherford

    jacob navia Guest

    Le 21/08/12 22:36, Edward Rutherford a écrit :
    > Hello
    >
    > I want to make a factory that produces other functions according to a
    > parameter.
    >
    > The following code does not compile:
    >
    > typedef int *(foo)(int);
    >
    > foo adder_factory(int x)
    > {
    > int f(int a)
    > {
    > return a + x;
    > }
    > return &f;
    > }
    >
    > The idea is that adder_factor(42) should be a function that adds 42 to
    > whatever it gets passed.
    >
    > What's the right way of doing this in C? How can I get closures or
    > something similar in C?
    >


    If you have the JIT of lcc-win you write:

    typedef int (*foo)(int);


    foo adder_factory(int value)
    {
    foo fnPtr;
    char buf[512];

    sprintf(buf,"int fn(int a) { return a + %d;}",value);
    fnPtr = (foo)compile(buf);
    return fnPtr;
    }
    jacob navia, Aug 22, 2012
    #4
  5. Edward Rutherford

    tom st denis Guest

    On Aug 22, 6:32 am, jacob navia <> wrote:
    > Le 21/08/12 22:36, Edward Rutherford a écrit :
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > Hello

    >
    > > I want to make a factory that produces other functions according to a
    > > parameter.

    >
    > > The following code does not compile:

    >
    > > typedef int *(foo)(int);

    >
    > > foo adder_factory(int x)
    > > {
    > >    int f(int a)
    > >    {
    > >      return a + x;
    > >    }
    > >    return &f;
    > > }

    >
    > > The idea is that adder_factor(42) should be a function that adds 42 to
    > > whatever it gets passed.

    >
    > > What's the right way of doing this in C? How can I get closures or
    > > something similar in C?

    >
    > If you have the JIT of lcc-win you write:
    >
    > typedef int (*foo)(int);
    >
    > foo adder_factory(int value)
    > {
    >         foo fnPtr;
    >         char buf[512];
    >
    >         sprintf(buf,"int fn(int a) { return a + %d;}",value);
    >         fnPtr = (foo)compile(buf);
    >         return fnPtr;


    You could accomplish similiar [though more longwinded] via compiling
    code and using dlopen() to load it into your process space.

    Both of which are completely OT for this group though.

    BTW: your code doesn't seem to do any sort of error checking. What if
    compile() fails?

    Tom
    tom st denis, Aug 22, 2012
    #5
  6. Edward Rutherford

    James Kuyper Guest

    On 08/22/2012 10:40 AM, tom st denis wrote:
    > On Aug 22, 6:32 am, jacob navia <> wrote:

    ....
    >> If you have the JIT of lcc-win you write:
    >>
    >> typedef int (*foo)(int);
    >>
    >> foo adder_factory(int value)
    >> {
    >> foo fnPtr;
    >> char buf[512];
    >>
    >> sprintf(buf,"int fn(int a) { return a + %d;}",value);
    >> fnPtr = (foo)compile(buf);
    >> return fnPtr;

    >
    > You could accomplish similiar [though more longwinded] via compiling
    > code and using dlopen() to load it into your process space.


    The intent was for the definition of the adder to be contained inside
    the definition of adder_factory().

    > Both of which are completely OT for this group though.
    >
    > BTW: your code doesn't seem to do any sort of error checking. What if
    > compile() fails?


    From the way it's used, it would appear to return a pointer. If
    compile() fails, it might return a null pointer, in which case
    adder_factory() will also return a null pointer, leaving it for the
    caller to decide what to do about it. That's a perfectly reasonable way
    of passing on the information that the call failed.

    However, I think that compile() looks horribly type-unsafe.
    James Kuyper, Aug 22, 2012
    #6
  7. Nobody wrote:
    > On Tue, 21 Aug 2012 20:36:31 +0000, Edward Rutherford wrote:
    >
    >> I want to make a factory that produces other functions according to a
    >> parameter.
    >>
    >> The following code does not compile:
    >>
    >> typedef int *(foo)(int);
    >>
    >> foo adder_factory(int x)
    >> {
    >> int f(int a)
    >> {
    >> return a + x;
    >> }
    >> return &f;
    >> }

    >
    > C does not have inner functions or closures.
    >
    >> The idea is that adder_factor(42) should be a function that adds 42 to
    >> whatever it gets passed.
    >>
    >> What's the right way of doing this in C? How can I get closures or
    >> something similar in C?

    >
    > typedef struct foo {
    > int (*func)(const struct foo *, int); int param;
    > } *foo;
    >
    > static int adder(const struct foo *closure, int x) {
    > return closure->param + x;
    > }
    >
    > foo adder_factory(int x)
    > {
    > foo p = malloc(sizeof(*p));
    > p->func = adder;
    > p->param = x;
    > return p;
    > }
    >
    > #define call_foo(f, x) ((f)->func((f), (x))


    Thanks for the suggestion. Unfortunately I need an actual function, not a
    macro, to be able to pass as a comparator function to qsort.

    Guess I just have to communicate what I need through a global variable?
    It would be nice if qsort took an extra "void *data" parameter, like
    functions in Glib (where it's called a gpointer of course)...
    Edward Rutherford, Aug 22, 2012
    #7
  8. Edward Rutherford

    James Kuyper Guest

    On 08/22/2012 12:36 PM, Edward Rutherford wrote:
    > Nobody wrote:
    >> On Tue, 21 Aug 2012 20:36:31 +0000, Edward Rutherford wrote:

    ....
    >>> The idea is that adder_factor(42) should be a function that adds 42 to
    >>> whatever it gets passed.
    >>>
    >>> What's the right way of doing this in C? How can I get closures or
    >>> something similar in C?

    >>
    >> typedef struct foo {
    >> int (*func)(const struct foo *, int); int param;
    >> } *foo;
    >>
    >> static int adder(const struct foo *closure, int x) {
    >> return closure->param + x;
    >> }
    >>
    >> foo adder_factory(int x)
    >> {
    >> foo p = malloc(sizeof(*p));
    >> p->func = adder;
    >> p->param = x;
    >> return p;
    >> }
    >>
    >> #define call_foo(f, x) ((f)->func((f), (x))

    >
    > Thanks for the suggestion. Unfortunately I need an actual function, not a
    > macro, to be able to pass as a comparator function to qsort.
    >
    > Guess I just have to communicate what I need through a global variable?


    That's one alternative. However, you can avoid creating a global, with
    all of the attendant problems. When used correctly, qsort() never calls
    the comparison function with null pointers. You can take advantage of
    that fact by making x a static variable local to the comparison
    function, and if the first argument to that function is a null pointer,
    interpret the second argument as a pointer to a new value for x.

    > It would be nice if qsort took an extra "void *data" parameter, like
    > functions in Glib (where it's called a gpointer of course)...


    Yes. It's a well-known problem with all of the original C standard
    library's callback functions. I think C11 has introduced some new
    callbacks, but I haven't had time to learn much about them.
    James Kuyper, Aug 22, 2012
    #8
  9. James Kuyper wrote:

    > On 08/22/2012 12:36 PM, Edward Rutherford wrote:
    >> Nobody wrote:
    >>> On Tue, 21 Aug 2012 20:36:31 +0000, Edward Rutherford wrote:

    > ...
    >>>> The idea is that adder_factor(42) should be a function that adds 42
    >>>> to whatever it gets passed.
    >>>>
    >>>> What's the right way of doing this in C? How can I get closures or
    >>>> something similar in C?
    >>>
    >>> typedef struct foo {
    >>> int (*func)(const struct foo *, int); int param;
    >>> } *foo;
    >>>
    >>> static int adder(const struct foo *closure, int x) {
    >>> return closure->param + x;
    >>> }
    >>>
    >>> foo adder_factory(int x)
    >>> {
    >>> foo p = malloc(sizeof(*p));
    >>> p->func = adder;
    >>> p->param = x;
    >>> return p;
    >>> }
    >>>
    >>> #define call_foo(f, x) ((f)->func((f), (x))

    >>
    >> Thanks for the suggestion. Unfortunately I need an actual function, not
    >> a macro, to be able to pass as a comparator function to qsort.
    >>
    >> Guess I just have to communicate what I need through a global variable?

    >
    > That's one alternative. However, you can avoid creating a global, with
    > all of the attendant problems. When used correctly, qsort() never calls
    > the comparison function with null pointers. You can take advantage of
    > that fact by making x a static variable local to the comparison
    > function, and if the first argument to that function is a null pointer,
    > interpret the second argument as a pointer to a new value for x.


    That is very clever.

    It does feel like a little bit of a hack to me, and I'd probably want to
    comment what was going on quite carefully.

    It also has the downside of introducing an extra branch instruction
    (check against NULL) in a function that could be called many many times
    in a sort.

    Still, ingenious! Thanks.
    Edward Rutherford, Aug 22, 2012
    #9
  10. Edward Rutherford

    James Kuyper Guest

    On 08/22/2012 01:01 PM, James Kuyper wrote:
    > On 08/22/2012 12:36 PM, Edward Rutherford wrote:

    ....
    >> It would be nice if qsort took an extra "void *data" parameter, like
    >> functions in Glib (where it's called a gpointer of course)...

    >
    > Yes. It's a well-known problem with all of the original C standard
    > library's callback functions. I think C11 has introduced some new
    > callbacks, but I haven't had time to learn much about them.


    The new callback function is the one passed to
    set_constraint_handler_s(). You cannot pass set_constraint_handler_s() a
    corresponding void*data to be passed to the constraint handler when it
    is called, so it looks like the committee has opted for consistency with
    previous callback functions, rather than more flexible functionality.

    constraint_handler_t functions take a second argument that is a void*,
    but it is either null or points at an implementation-defined object,
    which means that portable code can't do anything more useful with that
    pointer than reporting whether or not it's null (which isn't
    spectacularly useful).
    --
    James Kuyper
    James Kuyper, Aug 23, 2012
    #10
  11. Edward Rutherford

    jacob navia Guest

    Le 22/08/12 17:05, James Kuyper a écrit :
    > On 08/22/2012 10:40 AM, tom st denis wrote:
    >> On Aug 22, 6:32 am, jacob navia <> wrote:

    > ...
    >>> If you have the JIT of lcc-win you write:
    >>>
    >>> typedef int (*foo)(int);
    >>>
    >>> foo adder_factory(int value)
    >>> {
    >>> foo fnPtr;
    >>> char buf[512];
    >>>
    >>> sprintf(buf,"int fn(int a) { return a + %d;}",value);
    >>> fnPtr = (foo)compile(buf);
    >>> return fnPtr;

    >>
    >> You could accomplish similiar [though more longwinded] via compiling
    >> code and using dlopen() to load it into your process space.

    >
    > The intent was for the definition of the adder to be contained inside
    > the definition of adder_factory().
    >
    >> Both of which are completely OT for this group though.
    >>
    >> BTW: your code doesn't seem to do any sort of error checking. What if
    >> compile() fails?

    >
    > From the way it's used, it would appear to return a pointer.


    By convention it returns a pointer to the first function it finds.
    This is highly dependent on the application and customer setup.

    Some customers want to have a "main" function that starts the thing.
    In that case the JIT will return a pointer to that function. Others
    will put the main function at the start of the file and the Jit returns
    a function to the first function it compiles.

    In case of error (syntax error, no more memory, whatever catastrophe
    occurs), it returns NULL. Diagnostics are printed in stderr, whatever
    that is. In most applications stderr is a pipe connected to some
    file.

    Obviously in most applications the code buffer is machine generated.
    It could be however that it is used as a C interpreter.

    The resulting code is dynamically linked to the running program. There
    is no preprocessor.

    > If
    > compile() fails, it might return a null pointer, in which case
    > adder_factory() will also return a null pointer, leaving it for the
    > caller to decide what to do about it. That's a perfectly reasonable way
    > of passing on the information that the call failed.
    >
    > However, I think that compile() looks horribly type-unsafe.
    >


    In a sense yes, since it can return a pointer to ANY kind of function
    by definition... It is up to you to cast the result pointer into
    the right stuff. I do not see how to improve that without destroying
    the generality of the program.

    But we are used to it. fread() will read ANY kind of stuff into its
    buffer, it is up to you to interpret the data correctly.
    jacob navia, Aug 23, 2012
    #11
  12. On 22/08/2012 16:05, James Kuyper wrote:

    >
    > However, I think that compile() looks horribly type-unsafe.
    >


    Type safety in C? That's a novel concept :).
    Chicken McNuggets, Aug 23, 2012
    #12
  13. "James Kuyper" <> schrieb im Newsbeitrag
    news:...
    ....
    >> Type safety in C? That's a novel concept :).

    >
    > Is it? Try compiling the following code:
    >
    > int main(void)
    > {
    > double d;
    > int *pi = &d;
    > return 0;
    > }


    It compiles! On both Turbo C 2.0 and Borland C++Builder 5.

    There are just 2 warnings:

    Warning J:\C\TURBO2\NONAME.C 4: Suspicious pointer conversion in function
    main
    Warning J:\C\TURBO2\NONAME.C 6: 'pi' is assigned a value which is never used
    in function main

    Pascal is said to be more type safe. But I am astonished: Delphi 5 does not
    issue a warning at all, just a hint:

    program TypeSafe;
    {$APPTYPE CONSOLE}

    var d : double;
    pi : ^integer;
    begin
    pi := @d;
    exitcode := 0;
    end.

    [Hint] TypeSafe.dpr(7): 'pi' is assigned a value which is never used



    Heiner
    Heinrich Wolf, Aug 23, 2012
    #13
  14. On Aug 23, 10:13 am, James Kuyper <> wrote:
    > On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
    >
    > > On 22/08/2012 16:05, James Kuyper wrote:

    >
    > >> However, I think that compile() looks horribly type-unsafe.

    >
    > > Type safety in C? That's a novel concept :).

    >
    > Is it? Try compiling the following code:
    >
    > int main(void)
    > {
    >         double d;
    >         int *pi = &d;
    >         return 0;
    > }


    One additional line (that doesn't involve any casts) is sufficient -

    int main(void)
    {
    double d;
    void *pv = &d;
    int *pi = pv;
    return 0;
    }

    $ gcc -W -Wall -ansi -pedantic foo.c
    foo.c: In function ‘main’:
    foo.c:6:10: warning: unused variable ‘pi’
    Anand Hariharan, Aug 23, 2012
    #14
  15. Edward Rutherford

    James Kuyper Guest

    On 08/23/2012 12:18 PM, Heinrich Wolf wrote:
    >
    > "James Kuyper" <> schrieb im Newsbeitrag
    > news:...
    > ...
    >>> Type safety in C? That's a novel concept :).

    >>
    >> Is it? Try compiling the following code:
    >>
    >> int main(void)
    >> {
    >> double d;
    >> int *pi = &d;
    >> return 0;
    >> }

    >
    > It compiles! On both Turbo C 2.0 and Borland C++Builder 5.
    >
    > There are just 2 warnings:
    >
    > Warning J:\C\TURBO2\NONAME.C 4: Suspicious pointer conversion in function
    > main
    > Warning J:\C\TURBO2\NONAME.C 6: 'pi' is assigned a value which is never used
    > in function main


    The most that the C standard ever requires an implementation to do when
    processing a program that has any kind of defect is to produce at least
    one diagnostic message, contents unspecified; whether it then continues
    to generate an executable is entirely up to the implementation. This is
    one such case, a constraint violation (6.5.16.1p1). Any implementation
    for which this program fails to produce at least one diagnostic is
    non-conforming.
    James Kuyper, Aug 23, 2012
    #15
  16. Edward Rutherford

    James Kuyper Guest

    On 08/23/2012 12:18 PM, Heinrich Wolf wrote:
    >
    > "James Kuyper" <> schrieb im Newsbeitrag
    > news:...
    > ...
    >>> Type safety in C? That's a novel concept :).

    >>
    >> Is it? Try compiling the following code:
    >>
    >> int main(void)
    >> {
    >> double d;
    >> int *pi = &d;
    >> return 0;
    >> }

    >
    > It compiles! On both Turbo C 2.0 and Borland C++Builder 5.
    >
    > There are just 2 warnings:
    >
    > Warning J:\C\TURBO2\NONAME.C 4: Suspicious pointer conversion in function
    > main
    > Warning J:\C\TURBO2\NONAME.C 6: 'pi' is assigned a value which is never used
    > in function main


    The most that the C standard ever requires an implementation to do when
    processing a program that has any kind of defect is to produce at least
    one diagnostic message, contents unspecified; whether it then continues
    to generate an executable is entirely up to the implementation. This is
    one such case, a constraint violation (6.5.16.1p1). Any implementation
    for which this program fails to produce at least one diagnostic is
    non-conforming.
    James Kuyper, Aug 23, 2012
    #16
  17. Edward Rutherford

    jacob navia Guest

    Le 23/08/12 18:29, Anand Hariharan a écrit :
    > On Aug 23, 10:13 am, James Kuyper <> wrote:
    >> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
    >>
    >>> On 22/08/2012 16:05, James Kuyper wrote:

    >>
    >>>> However, I think that compile() looks horribly type-unsafe.

    >>
    >>> Type safety in C? That's a novel concept :).

    >>
    >> Is it? Try compiling the following code:
    >>
    >> int main(void)
    >> {
    >> double d;
    >> int *pi = &d;
    >> return 0;
    >> }

    >
    > One additional line (that doesn't involve any casts) is sufficient -
    >
    > int main(void)
    > {
    > double d;
    > void *pv = &d;
    > int *pi = pv;
    > return 0;
    > }
    >
    > $ gcc -W -Wall -ansi -pedantic foo.c
    > foo.c: In function ‘main’:
    > foo.c:6:10: warning: unused variable ‘pi’
    >
    >


    C allows you to interpret ANY part of memory as something else if you
    (as you have shown) are careful to avoid the built-in barriers of the
    language.

    Interpreting doubles as integers is very useful if you want to test
    some bits or manipulate some bits of the binary representation without
    going through expensive floating point operations. The whole Sun math
    library is built using this kind of code, and you can do that in C since
    it is a language that doesn't IMPOSE anything to the programmer, like
    C#, C++ or Cwhatever.
    jacob navia, Aug 23, 2012
    #17
  18. Edward Rutherford

    James Kuyper Guest

    On 08/23/2012 12:29 PM, Anand Hariharan wrote:
    > On Aug 23, 10:13 am, James Kuyper <> wrote:
    >> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
    >>
    >>> On 22/08/2012 16:05, James Kuyper wrote:

    >>
    >>>> However, I think that compile() looks horribly type-unsafe.

    >>
    >>> Type safety in C? That's a novel concept :).

    >>
    >> Is it? Try compiling the following code:
    >>
    >> int main(void)
    >> {
    >> double d;
    >> int *pi = &d;
    >> return 0;
    >> }

    >
    > One additional line (that doesn't involve any casts) is sufficient -
    >
    > int main(void)
    > {
    > double d;
    > void *pv = &d;
    > int *pi = pv;
    > return 0;
    > }


    Sure, C's support of type safety is weak, and easily circumvented. But
    it's not non-existent, as implied by Chicken's first comment above. I've
    used several languages with substantially less type safety; mostly ones
    where type mismatches are not detected until something blows up at run
    time. I greatly prefer catching them at compile time (a concept which
    doesn't even apply to some of those languages).
    James Kuyper, Aug 23, 2012
    #18
  19. On 23/08/2012 16:13, James Kuyper wrote:
    > On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
    >> On 22/08/2012 16:05, James Kuyper wrote:
    >>
    >>>
    >>> However, I think that compile() looks horribly type-unsafe.
    >>>

    >>
    >> Type safety in C? That's a novel concept :).

    >
    > Is it? Try compiling the following code:
    >
    > int main(void)
    > {
    > double d;
    > int *pi = &d;
    > return 0;
    > }
    >


    Yes. It compiles with a warning as expected. Not a great example of type
    safety.

    This code on the other hand compiles with no warnings:

    #include <stdlib.h>

    int main(void)
    {
    int *ptr = (int*) malloc(sizeof(long));
    *ptr = 10;
    short blah = *ptr;
    free(ptr);
    exit(EXIT_SUCCESS);
    }

    so please explain how C is a type safe language?

    The fact that malloc() returns a void pointer that can be cast to any
    type destroys any type safety C may have.

    Try Haskell for a real type safe language.
    Chicken McNuggets, Aug 23, 2012
    #19
  20. Edward Rutherford

    jacob navia Guest

    Le 23/08/12 19:02, Chicken McNuggets a écrit :
    > On 23/08/2012 16:13, James Kuyper wrote:
    >> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
    >>> On 22/08/2012 16:05, James Kuyper wrote:
    >>>
    >>>>
    >>>> However, I think that compile() looks horribly type-unsafe.
    >>>>
    >>>
    >>> Type safety in C? That's a novel concept :).

    >>
    >> Is it? Try compiling the following code:
    >>
    >> int main(void)
    >> {
    >> double d;
    >> int *pi = &d;
    >> return 0;
    >> }
    >>

    >
    > Yes. It compiles with a warning as expected. Not a great example of type
    > safety.
    >
    > This code on the other hand compiles with no warnings:
    >
    > #include <stdlib.h>
    >
    > int main(void)
    > {
    > int *ptr = (int*) malloc(sizeof(long));
    > *ptr = 10;
    > short blah = *ptr;
    > free(ptr);
    > exit(EXIT_SUCCESS);
    > }
    >
    > so please explain how C is a type safe language?
    >


    Because you can assign a 64 bit integer into a short. If there is an
    overflow the behavior is undefined but it can't be any overflow in your
    example since 10 will fit into a short.

    What is the problem?

    > The fact that malloc() returns a void pointer that can be cast to any
    > type destroys any type safety C may have.
    >
    > Try Haskell for a real type safe language.


    OK
    Lets suppose I have a double precision number and that I want to reset
    the sign bit without doing any expensive floating point operations.

    How do I do that in Haskell?
    jacob navia, Aug 23, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green

    overridding factories.

    Roedy Green, Aug 24, 2003, in forum: Java
    Replies:
    0
    Views:
    360
    Roedy Green
    Aug 24, 2003
  2. Kai Grossjohann

    JSP: Beans from factories?

    Kai Grossjohann, Dec 17, 2003, in forum: Java
    Replies:
    2
    Views:
    676
    Kai Grossjohann
    Dec 17, 2003
  3. Timo Nentwig
    Replies:
    0
    Views:
    3,909
    Timo Nentwig
    Apr 27, 2004
  4. Replies:
    1
    Views:
    435
    Oliver Wong
    Oct 2, 2006
  5. Chadrik
    Replies:
    0
    Views:
    211
    Chadrik
    Jun 21, 2008
Loading...

Share This Page