if you had a C gnome ...

[Uno]

I dabble in a lot of languages, and I don't think that I'm alone in the
notion that I pick the language I'm going to use to fit the problem.

For example, if I needed to know what files were in the current
directory, well I would not use standard C, as it is outside the purview
of standard C.

Sorting is another thing. Now that I've got Dann Corbitt's templates
for sorting, I would be more inclined to take it as a task in C. You
get a lot better feedback on things when you can guarantee that the
usage is standard (in whatever syntax).

The part of C where I struggle most is pointers. Indeed, if I could
have a super-intelligent gnome cover one aspect of reading and writing
in C, it would be to figure out what is going on with the pointers. If
there's more than 5 of them in a code block, I'm gonna drop the ball.

I'm curious how unusual this is. Let me poll with this question:

If you had a super-intelligent gnome to help you with one aspect of
programming in C, what would it be?

 

[Ian Collins]

I dabble in a lot of languages, and I don't think that I'm alone in the
notion that I pick the language I'm going to use to fit the problem.

For example, if I needed to know what files were in the current
directory, well I would not use standard C, as it is outside the purview
of standard C.

Sorting is another thing. Now that I've got Dann Corbitt's templates for
sorting, I would be more inclined to take it as a task in C. You get a
lot better feedback on things when you can guarantee that the usage is
standard (in whatever syntax).

The part of C where I struggle most is pointers. Indeed, if I could have
a super-intelligent gnome cover one aspect of reading and writing in C,
it would be to figure out what is going on with the pointers. If there's
more than 5 of them in a code block, I'm gonna drop the ball.

I guess I never had that problem because I started form assembler.

I'm curious how unusual this is. Let me poll with this question:

If you had a super-intelligent gnome to help you with one aspect of
programming in C, what would it be?

The typing!

 

[Uno]

The typing!

What, getting the types correct or the keystrokes?

 

[Ian Collins]

What, getting the types correct or the keystrokes?

The latter.

 

[Tom St Denis]

The part of C where I struggle most is pointers.  Indeed, if I could
have a super-intelligent gnome cover one aspect of reading and writing
in C, it would be to figure out what is going on with the pointers.  If
there's more than 5 of them in a code block, I'm gonna drop the ball.

re: pointers, use valgrind and/or debugger. There I saved you a lot
of trouble.

I'm curious how unusual this is.  Let me poll with this question:

If you had a super-intelligent gnome to help you with one aspect of
programming in C, what would it be?

Honestly? I'd love to have some form of "mark/release" for malloc/
calloc/realloc so I could easily tell the heap code to free anything
allocated after a certain point. When I write library code (for
crypto) I often spend enough time first initializing all my local
variables to NULL, then having to write the cleanup at the tail of the
function, e.g.

if (ptrA) { free(ptrA); }
if (ptrB) { free(ptrB); }
etc...

It'd be nice to be able to say something like

int somefunc(...)
{
void *ptrA, *ptrB, *ptrC;

heap_mark();
ptrA = malloc(whatever);
....
....
....
heap_release();
return ret_code;
}

That would make my life simpler, only problem is something like that
wouldn't exactly be thread safe so it's not entirely practical. Well,
unless behind the scenes heap_mark/malloc/calloc/realloc were all
tagged somehow ... like

int id = heap_mark();
ptrA = malloc(id, whatever);
....
heap_release(id);

And of course you can accomplish it with macro redefinitions to a non-
libc version of the heap functions [which is what I do instead]. but
it'd be nice to be part of the standard C lib.

Tom

 

[Uno]

The latter.

Rather amazing to find so few weak points in a syntax, y'all must love
having basically broken floating point.

 

[Shao Miller]

if (ptrA) { free(ptrA); }
if (ptrB) { free(ptrB); }
etc...

Hmm... In C99 (at least), I believe that you can attempt to 'free' a
null pointer value to no ill effect. Since a garbage value in either
'ptrA' or 'ptrB' should pass your 'if', the only case that shouldn't
pass should be a null pointer value... Which can be passed to 'free'.

 

[Tom St Denis]

Those two if's are also pointless in C89.

Ah true, though sometimes the logic has something like

if (blah) { free(blah->foo); free(blah); }

or

if (foo) { some_func_to_free_foo(foo); }

Where I could make those functions behave with NULL but to me it's
clearer to say "only do if not NULL". Which doesn't change my point
that it'd be nice to be able to GC the memory, specially if you're
calling a lot of sub-functions who call sub-functions who call ...

In my case I do GC on a global level so it's easy to just trap all
heap functions and be done with.

 

[Nick Keighley]

Rather amazing to find so few weak points in a syntax,

well I still consider the syntax ugly and the "declaration mirrors
usage" was in my opion an interesting but unltimately flawed idea.

typedef struct Able* (*Function_Pointer) (int, int);

I must admit I struggled with C pointers. And I'd used assmebler and
Pascal. My insight was to realise (or rather be told)

int* i; /* i is a ptr-to-int */
int *i; /* *i is an int */

These are both the same declaration, just looked at in a different
way. That helped me.

Also, whenever I dealt with ptr-to-ptr I initially fell back to a
simpler ptr-to-int case first.

void swop (int *i, int *j)
{
int t;
t = *i;
*i = *j;
*j = t;
}

Hence a more complicated example

void alloc_table (int **tab)
{
*tab = malloc (TABLE_SIZE);
}

I find it odd that you refer to C as "a syntax". Don't the semantice
mean anything to you?

y'all must love
having basically broken floating point.

what's wrong with the floating point?

 

[Uno]

re: pointers, use valgrind and/or debugger. There I saved you a lot
of trouble.

It's been too long that I haven't had a debugger I like. I had an
unexpected windfall and now have a budget for both books and software.
With my background, I never made gdb.exe a frustration reducer.

Honestly? I'd love to have some form of "mark/release" for malloc/
calloc/realloc so I could easily tell the heap code to free anything
allocated after a certain point. When I write library code (for
crypto) I often spend enough time first initializing all my local
variables to NULL, then having to write the cleanup at the tail of the
function, e.g.

if (ptrA) { free(ptrA); }
if (ptrB) { free(ptrB); }
etc...

It'd be nice to be able to say something like

int somefunc(...)
{
void *ptrA, *ptrB, *ptrC;

heap_mark();
ptrA = malloc(whatever);
...
...
...
heap_release();
return ret_code;
}

That would make my life simpler, only problem is something like that
wouldn't exactly be thread safe so it's not entirely practical. Well,
unless behind the scenes heap_mark/malloc/calloc/realloc were all
tagged somehow ... like

int id = heap_mark();
ptrA = malloc(id, whatever);
...
heap_release(id);

And of course you can accomplish it with macro redefinitions to a non-
libc version of the heap functions [which is what I do instead]. but
it'd be nice to be part of the standard C lib.

Is the idea that you would have your own malloc in this library that
includes this free'ing? It often gets said that ordinary mortals can't
write malloc. I wonder why that is.