Prev: need recommendation on win32 api book or site
Next: Cheap wholesale 2010 World Cup jerseys by paypal and free shipping
From: Alf P. Steinbach on 13 Jun 2010 01:56
* Richard Heathfield, on 13.06.2010 05:39:
> Alf P. Steinbach wrote:
>> * Chad, on 13.06.2010 02:18:
>>> Let's say I have function called delete() that takes a string 's' as
>>> its argument. This functions sole purpose is to delete a node from a
>>> singly linked list. The pseudo code would be like the following....
>>>
>>> void delete(char *s)
>>
>> This looks like C. In C++ 'delete' is a keyword. So you might want to
>> avoid it also in C.
>
> The only reason to avoid it in C is if you want the code to compile in
> C++ too. Since code that is written to be both C and C++ tends to be bad
> C and worse C++, it's rarely a great idea to make the attempt.

Hm, that's quite a number of erors in 1 pair of graphs. He he. OK, taking them
in order.

"The only reason to avoid it in C is if you want the code to compile in C++
too". As I read it you're thinking of compiling function definitions and such.
No sir, it's all about header files: much of the reason that C++ became popular
was that you could easily link with C libraries, but you can't do that so easily
when the C programmer uses names such as 'delete' and 'class'.

"Since code that is written be both C and C++ tends to be bad C and worse C++",
well, again it seems you're thinking about functions definitions, while what
matters is header file stuff, pure declarations.

"[conclusion] it's rarely a great idea to make the attempt".

On the contrary, it's an incompetent programmer who doesn't take into
consideration how well the C header will play with C++. I'm not implying
anything about you here, I know you're competent. The above seems to indicate
that you just didn't think things through before typing away a response, or
perhaps you were out on the town on Saturday evening, or whatever. And of course
I'm talking about professional programmers. Students (like I assumme the OP is)
are not expected to already know, which is why I mentioned this.


> Case in point: if he were using C++, why on earth would he be worrying
> about this in the first place? He would just use the STL.

It looks like C code.

I assume it is C code.

That said, many students who are learning C++ are forbidden by their not very
bright teachers to use the standard library (the "STL" is just a part of that
library), and regardless of C or C++ you can infer that this is student work
from both the questions and the fact of implement-my-own-hashtable.


> I tend to use C++ keywords at the drop of a hat in my C code, because
> they don't 'arf make a noise if I accidentally use the wrong compiler!

I do hope you don't use C++ keywords as names in your library header files.


>> The formal argument would better be
>>
>> char const* s
>>
>> (modulo C syntax, which I'm not that familiar with) which would allow
>> the function to be called with 'char const*' actual argument.
>
> Yes, that's good syntax; so is const char *s, which some people find
> more readable.

I prefer the form I showed because it generalizes to more complicated
declarations, but e.g. the C++ standard, and Bjarne, use the form you show.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>
From: Richard Heathfield on 13 Jun 2010 09:23
Alf P. Steinbach wrote:
> * Richard Heathfield, on 13.06.2010 05:39:
>> Alf P. Steinbach wrote:
>>> * Chad, on 13.06.2010 02:18:
>>>> Let's say I have function called delete() that takes a string 's' as
>>>> its argument. This functions sole purpose is to delete a node from a
>>>> singly linked list. The pseudo code would be like the following....
>>>>
>>>> void delete(char *s)
>>>
>>> This looks like C. In C++ 'delete' is a keyword. So you might want to
>>> avoid it also in C.
>>
>> The only reason to avoid it in C is if you want the code to compile in
>> C++ too. Since code that is written to be both C and C++ tends to be bad
>> C and worse C++, it's rarely a great idea to make the attempt.
>
> Hm, that's quite a number of erors in 1 pair of graphs. He he. OK,
> taking them in order.

Actually, I'll grant you *one* error, which you re-use several times.
Code re-use is good. Error re-use is bordering on the unfair. :-)

>
> "The only reason to avoid it in C is if you want the code to compile in
> C++ too". As I read it you're thinking of compiling function definitions
> and such. No sir, it's all about header files: much of the reason that
> C++ became popular was that you could easily link with C libraries, but
> you can't do that so easily when the C programmer uses names such as
> 'delete' and 'class'.

Yes, that's a reasonable point that I hadn't considered. It is indeed
true that a good C++ programmer will, by virtue of being a good
programmer, re-use code where practical and sensible, and that means
being able to link to C libs, and that means C libs that don't interfere
at a file scope level with C++ syntax checking. So yes, I'll give you
that one.

<snip>

>> I tend to use C++ keywords at the drop of a hat in my C code, because
>> they don't 'arf make a noise if I accidentally use the wrong compiler!
>
> I do hope you don't use C++ keywords as names in your library header files.

No, I don't, but that's less to do with good planning than to do with
the fact that C++ keywords don't generally make good (eg) function
names! They do, however, sometimes make for excellent identifiers. My
most common is:

T *t_create(args)
{
T *new = malloc(sizeof *new);
if(new != NULL)
{
new->members = initialise from args;
}
return new;
}

which I find intuitive as well as useful from the compiler-diagnostic
point of view.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
From: Chad on 13 Jun 2010 13:10
On Jun 12, 8:20 pm, "Alf P. Steinbach" <al...(a)start.no> wrote:

> If your code works without knowing the length, why do you think it needs to know
> the length?
>

This may or may not answer your question. A few days ago, on another
forum, someone had asked which operation(s) on a singly linked list
don't need to know the length of the list. I guess they meant
operations that don't require the length of the list as one of the
function arguments. The first thing that came to my mind was deleting
a node at the end of a linked list since you would have to traverse
the entire list in order to find the last node. However, this didn't
seem quite right, because the function can be done without having the
length of the linked list as one of the function arguments. Ie, all I
would have to do is just pass the head of the linked list to some
delete function.

My second guess was sorting a linked list. For example, if I would do
something totally boneheaded[1], and do a Bubble Sort on the list. But
then, couldn't this sort operation be done using a function callback?

Chad


[1]The only thing that might be more bonehead, would be to pull a
spinoza on comp.lang.c, and then start using some very creative
metaphors to describe your mom, because I lost the technical debate.
From: Paul N on 13 Jun 2010 15:52
On 13 June, 04:20, "Alf P. Steinbach" <al...(a)start.no> wrote:
> Anyway you might find it useful to have a function
>
>      struct nlist* unlink( struct nlist** pp_next )
>      {
>          struct nlist* p_node = *pp_next;
>          *pp_next = p_node->next;
>          return p_node;
>      }

Using the name "unlink" might get you problems. Turbo C++ (which
includes a C compiler) uses the name as a function to delete a file,
and says that this is available on UNIX systems.

HTH,
Paul.
From: Richard Heathfield on 13 Jun 2010 15:53
Chad wrote:
> On Jun 12, 8:20 pm, "Alf P. Steinbach" <al...(a)start.no> wrote:
>
>> If your code works without knowing the length, why do you think it needs to know
>> the length?
>>
>
> This may or may not answer your question. A few days ago, on another
> forum, someone had asked which operation(s) on a singly linked list
> don't need to know the length of the list.

The answer is easy: All of them.

> I guess they meant
> operations that don't require the length of the list as one of the
> function arguments.

Any operation that needs, for some reason, to know the length of the
list can find out easily enough by calling this function or its moral
equivalent:

size_t list_getlength(node *p)
{
size_t len = 0;
while(p != NULL)
{
p = p->next;
++len;
}
return len;
}

so it is never necessary to pass the list length as a function argument.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: need recommendation on win32 api book or site
Next: Cheap wholesale 2010 World Cup jerseys by paypal and free shipping