libclc-developers Mailing List for libclc (Page 2)
Status: Planning
Brought to you by:
augestad
Menu
▾
▴
libclc-developers — Communication between developers of libclc
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(1) |
Mar
(170) |
Apr
(73) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: regis <re...@in...> - 2003-04-03 20:20:31
|
Jan Engelhardt wrote: > > >> >With good naming conventions, you only scan the prototype in the docs > >> >to find what you want > >> >With bad ones, you must also read the full description. > >> >Have a look at the libncurse documentation to see what I mean. > >> >You really want "this" ? > >> >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html > >> > >> The only thing I am worried about is a prefix for Ncurses. > > > >beuarhhhhh.... > > Or what was it about, then? > > - Jan Engelhardt it is unreadable and inconsistent. Exemples: addchstr(): no underscore, start with the verb attr_get(): noun prefix + one underscore, end with the verb. tgetflag(): no underscore, the verb is in the middle. has_ic(): verb prefix + one underscore move(): verb written in full mvaddchstr(): 'move' shrinked to 'mv' |
|
From: Jan E. <je...@li...> - 2003-04-03 20:10:42
|
>> >Even for the standard strspn, I still don't know what spn stands for.= .. >> Play a bit of Gl=FCcksrad and buy a vowel. > >Why not giving it for free to the user. >What's the point to remove the 'o' of copy. >Just like this unix function creat(): >create() was just as fine. Yeah now I wonder. Did not they have enough space -- just for ONE char? creat(e) strc(o)py strsp(a)n anywhere else? - Jan Engelhardt |
|
From: Jan E. <je...@li...> - 2003-04-03 20:07:45
|
>> >With good naming conventions, you only scan the prototype in the docs >> >to find what you want >> >With bad ones, you must also read the full description. >> >Have a look at the libncurse documentation to see what I mean. >> >You really want "this" ? >> >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html >> >> The only thing I am worried about is a prefix for Ncurses. > >beuarhhhhh.... Or what was it about, then? - Jan Engelhardt |
|
From: regis <re...@in...> - 2003-04-03 20:01:51
|
Hallvard B Furuseth wrote: > > - Given a wanted feature by the user, it is hard for him to guess what > > is the corresponding function. > > The documentation should point the user in the right direction. See > cvs/doc/string/string.txt. Maybe that should be extended to include > brief (hopefully one-line) summaries for each function. Right. Where we diverge is that the documentation of a function starts with its name. |
|
From: regis <re...@in...> - 2003-04-03 19:57:55
|
Hallvard B Furuseth wrote: > > regis writes: > > I think most functions modifying / returning a string > > -- e.g. the function changing the letters to uppercase -- > > should allow the three following modes: > > > > 1) the output string is provided by the caller. > > For most function, it should be allowed > > that it is the input string itself. > > > > 2) the caller provide NULL for the result, and then > > the function allocates the memory for the output. > > > > in both cases, the output is returned. > > That's an idea. I'll bring it up on comp.lang.c if you don't want to, > in a couple of days. Unless the libclc discussion there takes off, > then I'll delay it a bit. By the way, it's a convention I was forced to use for my bitset implementation, otherwise I would have three times as many functions the current interface has. Since I believe it's a general problem not restricted to bitsets, I signal this issue to the implementators of the string module. |
|
From: regis <re...@in...> - 2003-04-03 19:51:37
|
Jan Engelhardt wrote: > > >With good naming conventions, you only scan the prototype in the docs > >to find what you want > >With bad ones, you must also read the full description. > >Have a look at the libncurse documentation to see what I mean. > >You really want "this" ? > >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html > > The only thing I am worried about is a prefix for Ncurses. beuarhhhhh.... |
|
From: regis <re...@in...> - 2003-04-03 19:46:11
|
Jan Engelhardt wrote: >=20 > >- Given a function name, It's hard to guess what it is supposed to do. > Depends. Like, strcpy() obviously copies a string, no? > >Even for the standard strspn, I still don't know what spn stands for... > Play a bit of Gl=FCcksrad and buy a vowel. Why not giving it for free to the user. What's the point to remove the 'o' of copy. Just like this unix function creat():=20 create() was just as fine. =20 > >Clearer (and unforgetable) names > >(with prefix clc_str_. Thinking of it, it would be better > >to reserve the long prefix clc_string_ for a possible future > >ADT for strings that expand/shrink automatically...) > Ok, what if we add a clc_newbie.h, for those who ain't > comfortable with short names? Well, I would not qualify myself as a newbie. (though I m naive enough to believe in a life after the 70's) --=20 Regis |
|
From: Jan E. <je...@li...> - 2003-04-03 19:34:34
|
>> But stdio.h (at least glib/gcc) has it as (void *)0 defined. > >On Solaris [...] Never mind. - Jan Engelhardt |
|
From: Jan E. <je...@li...> - 2003-04-03 19:34:00
|
>With good naming conventions, you only scan the prototype in the docs >to find what you want >With bad ones, you must also read the full description. >Have a look at the libncurse documentation to see what I mean. >You really want "this" ? >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html The only thing I am worried about is a prefix for Ncurses. >stdc... >libclc is a user library: This means lots of functions. glibc has as many functions. (wth with stdc then) >So the user must be helped to remember the function names at >first sight. We don't need another libncurses. - Jan Engelhardt |
|
From: Jan E. <je...@li...> - 2003-04-03 19:31:39
|
>- Given a function name, It's hard to guess what it is supposed to do. Depends. Like, strcpy() obviously copies a string, no? >- Given a wanted feature by the user, it is hard for him to guess what >is the corresponding function. If it's simple, you know it. If you don't, somebody else might know. I guess if he wants a perlish $a =3D $b in C, I'd suggest him strdup(). (Or malloc/strcpy) >- Given a function already used by the user, it is hard to remember it >for the next use. ? He should remember that he used a particular function. >What clc_stpcpy is supposed to do? What does the 'p' stand? pointer >What clc_strtok_r is supposed to do? What does the '_r' mean? _reentrant , I'd guess (that is, thread-safe et al) >What clc_strlcpy is supposed to do? What does the 'l' mean? length Asking: "What does the "n" mean in strncpy?" (i know the answer thanks) >These are as many questions the new user asks at the first sight >of these functions... Oh you meant new users... >Even for the standard strspn, I still don't know what spn stands for... Play a bit of Gl=FCcksrad and buy a vowel. >Clearer (and unforgetable) names >(with prefix clc_str_. Thinking of it, it would be better >to reserve the long prefix clc_string_ for a possible future >ADT for strings that expand/shrink automatically...) Ok, what if we add a clc_newbie.h, for those who ain't comfortable with short names? - Jan Engelhardt |
|
From: Jan E. <je...@li...> - 2003-04-03 19:28:30
|
>The functions names like strcpy() were created >when the screen lines were 40 char longs, and when >only a prefix of limited length made the names distinct >identifiers. Nowadays we have 72+ chars, and as everything evolves, so do our programs, complexities, etc. Did you know a usual C programmer does "medium" sized statements? Compare, in ASM there are no "sized" statements, you only have, say, inc %eax imul %eax,50 push %eax call function_call instead of function_call(++eax * 50); and whatever. (That is you could do ++eax; eax *= 50; function_call(eax); ) Enough off topic. I bet those ppl with 40 char screens (MS-DOS command "mode con cols=40" brings you the feeling), did probably use shorter statements. - Jan Engelhardt |
|
From: regis <re...@in...> - 2003-04-03 19:27:20
|
Hallvard B Furuseth wrote: > > - Given a function name, It's hard to guess what it is supposed to do. > > That's true, but unfortunately typical for C. This is not a reason to continue this way... > > - Given a wanted feature by the user, it is hard for him to guess what > > is the corresponding function. > > The documentation should point the user in the right direction. See > cvs/doc/string/string.txt. Maybe that should be extended to include > brief (hopefully one-line) summaries for each function. With good naming conventions, you only scan the prototype in the docs to find what you want With bad ones, you must also read the full description. Have a look at the libncurse documentation to see what I mean. You really want "this" ? http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html > It might have been nice if Standard C used such names, but it doesn't. > So I think we should at least partly stick to standard C's way of naming > things. This is the worst option. std c library is compact: There are few function so we can bear the stupid names. libclc is a user library: This means lots of functions. So the user must be helped to remember the function names at first sight. We don't need another libncurses. > Though I do think clc_str<lwr/upr> should be <lower/upper>, > like tolower/toupper(). Why erase the 'to'? clc_str_tolower clc_str_toupper > #define long_name(...) short_name(...) might be an idea, though. > > > ( I would merge clc_stpcpy() and clc_strdup() to the single function > > clc_str_copy() with a possibly NULL extra output arg. ) > > No way. Then it would have to return a pointer to the end of the string > if the argument is NULL and to the beginning if it is non-NULL. That's > _really_ confusing. Even more than you probably were when you > misremembered what clc_stpcpy does:-) Which further illustrates my point :o) messy names = mess in user brains |
|
From: Jan E. <je...@li...> - 2003-04-03 19:21:48
|
>This is a bit unwise because I would not have used >the word 'suck' with such a large audience. Did I see "suck" anywhere? Maybe i am just blind, whatever. Hey,everybody is free to express what he thinks. -- at least in a democratic state. - Jan Engelhardt |
|
From: Hallvard B F. <h.b...@us...> - 2003-04-03 19:20:37
|
regis writes: > I think most functions modifying / returning a string > -- e.g. the function changing the letters to uppercase -- > should allow the three following modes: > > 1) the output string is provided by the caller. > For most function, it should be allowed > that it is the input string itself. > > 2) the caller provide NULL for the result, and then > the function allocates the memory for the output. > > in both cases, the output is returned. That's an idea. I'll bring it up on comp.lang.c if you don't want to, in a couple of days. Unless the libclc discussion there takes off, then I'll delay it a bit. -- Hallvard |
|
From: Hallvard B F. <h.b...@us...> - 2003-04-03 19:16:44
|
> I'm not doing a formal proposal for a change of interface > (I would have to do it earlier on clc). It's not too late. That's one of the things the c.l.c discussion/vote thing is for. I'm going to propose a some changes there myself. -- Hallvard |
|
From: Hallvard B F. <h.b...@us...> - 2003-04-03 19:14:42
|
Jan Engelhardt writes: > But stdio.h (at least glib/gcc) has it as (void *)0 defined. On Solaris it's defined as 0 or 0L, depending on the architecture. So it has the decency to #define NULL as an integer with the same representation as (void *)0, but it didn't have to do that. -- Hallvard |
|
From: Hallvard B F. <h.b...@us...> - 2003-04-03 19:06:08
|
I still think this should go to comp.lang.c, but anyway: regis writes: >Hallvard B Furuseth wrote: >>regis writes: >>>> so that is a vote for ultostr? >>> >>> Mhh Yes, >>> except that the mangled names of all the string functions suck. >> >> Say it on c.l.c. With suggestions for other names. Then I'll probably >> speak up against you, I think most names are fine:-) > > - Given a function name, It's hard to guess what it is supposed to do. That's true, but unfortunately typical for C. > - Given a wanted feature by the user, it is hard for him to guess what > is the corresponding function. The documentation should point the user in the right direction. See cvs/doc/string/string.txt. Maybe that should be extended to include brief (hopefully one-line) summaries for each function. > - Given a function already used by the user, it is hard to remember it > for the next use. Not sure I really agree with that, but it's all the same of your first point anyway. > What clc_stpcpy is supposed to do? What does the 'p' stand? > What clc_strtok_r is supposed to do? What does the '_r' mean? > What clc_strlcpy is supposed to do? What does the 'l' mean? I think these function names should stay, because they are copied from already existing functions. <http://www.linuxcentral.com/linux/man-pages/stpcpy.3.html> <http://www.courtesan.com/todd/papers/strlcpy.html> <http://www.mkssoftware.com/docs/man3/strtok_r.3.asp> (I have no idea what the 'p' is. '_r' is standard for reentrant versions of non-reentrant functions. Maybe 'l' is 'length'.) > Even for the standard strspn, I still don't know what spn stands for... "span"? > Clearer (and unforgetable) names > (with prefix clc_str_. Thinking of it, it would be better > to reserve the long prefix clc_string_ for a possible future > ADT for strings that expand/shrink automatically...) > > from_unsigned_long() > to_uppercase() > trim_left() > trim_right() > trim() or trim_both() > split() > normalize() > reverse() > compare_case_insensitive() > etc. It might have been nice if Standard C used such names, but it doesn't. So I think we should at least partly stick to standard C's way of naming things. Though I do think clc_str<lwr/upr> should be <lower/upper>, like tolower/toupper(). #define long_name(...) short_name(...) might be an idea, though. > ( I would merge clc_stpcpy() and clc_strdup() to the single function > clc_str_copy() with a possibly NULL extra output arg. ) No way. Then it would have to return a pointer to the end of the string if the argument is NULL and to the beginning if it is non-NULL. That's _really_ confusing. Even more than you probably were when you misremembered what clc_stpcpy does:-) -- Hallvard |
|
From: regis <re...@in...> - 2003-04-03 19:04:26
|
regis wrote: >=20 > Bj=F8rn Augestad wrote: >=20 > > > Don't known if it has been discussed before, but I have > > > a general remark about the interface of the string function. > > > > That's good, but now that the source has been posted to c.l.c these > > comments really should be posted there as well. We cannot change at t= his > > stage, IMO. > > > > Please post your remarks there. You may even get an answer... ;-) >=20 > I'm not doing a formal proposal for a change of interface > (I would have to do it earlier on clc). > I'm only interested in the opinion of the implementators. Too late,=20 Jan Engelhardt forwarded my post to clc :o( This is a bit unwise because I would not have used=20 the word 'suck' with such a large audience. --=20 Regis |
|
From: regis <re...@in...> - 2003-04-03 18:55:06
|
Bj=F8rn Augestad wrote: > > Don't known if it has been discussed before, but I have > > a general remark about the interface of the string function. >=20 > That's good, but now that the source has been posted to c.l.c these > comments really should be posted there as well. We cannot change at thi= s > stage, IMO. >=20 > Please post your remarks there. You may even get an answer... ;-) I'm not doing a formal proposal for a change of interface (I would have to do it earlier on clc).=20 I'm only interested in the opinion of the implementators.=20 --=20 Regis |
|
From: regis <re...@in...> - 2003-04-03 18:35:50
|
Hallvard B Furuseth wrote: > > regis writes: > >> so that is a vote for ultostr? > > > > Mhh Yes, > > except that the mangled names of all the string functions suck. > > Say it on c.l.c. With suggestions for other names. Then I'll probably > speak up against you, I think most names are fine:-) - Given a function name, It's hard to guess what it is supposed to do. - Given a wanted feature by the user, it is hard for him to guess what is the corresponding function. - Given a function already used by the user, it is hard to remember it for the next use. What clc_stpcpy is supposed to do? What does the 'p' stand? What clc_strtok_r is supposed to do? What does the '_r' mean? What clc_strlcpy is supposed to do? What does the 'l' mean? These are as many questions the new user asks at the first sight of these functions... Even for the standard strspn, I still don't know what spn stands for... Clearer (and unforgetable) names (with prefix clc_str_. Thinking of it, it would be better to reserve the long prefix clc_string_ for a possible future ADT for strings that expand/shrink automatically...) from_unsigned_long() to_uppercase() trim_left() trim_right() trim() or trim_both() split() normalize() reverse() compare_case_insensitive() etc. ( I would merge clc_stpcpy() and clc_strdup() to the single function clc_str_copy() with a possibly NULL extra output arg. ) |
|
From: <bo...@me...> - 2003-04-03 18:25:22
|
regis wrote: > regis wrote: > >>Jan Engelhardt wrote: >> >>>so that is a vote for ultostr? >> >>Mhh Yes, >>except that the mangled names of all the string functions suck. >> > > > Don't known if it has been discussed before, but I have > a general remark about the inearface of the string function. That's good, but now that the source has been posted to c.l.c these comments really should be posted there as well. We cannot change at this stage, IMO. Please post your remarks there. You may even get an answer... ;-) -- boa libclc home: http://libclc.sourceforge.net |
|
From: regis <re...@in...> - 2003-04-03 18:20:42
|
Jan Engelhardt wrote: > > >By the way, what's the problem with clear > >and understandable function names like > > > >clc_string_to_uppercase() > >clc_string_to_lowercase() > >clc_string_reverse() > >clc_string_from_unsigned_long() > >etc. > > Hey, we do not program an OS called Microsoft Something. > (They use really long things for short things.) > You can add a #define in all your programs if you like so. > #define clc_string_from_unsinged_long clc_ultostr > > - Jan Engelhardt (No because clc_ prefix is reserved) The functions names like strcpy() were created when the screen lines were 40 char longs, and when only a prefix of limited length made the names distinct identifiers. |
|
From: Jan E. <je...@li...> - 2003-04-03 18:03:08
|
>By the way, what's the problem with clear >and understandable function names like > >clc_string_to_uppercase() >clc_string_to_lowercase() >clc_string_reverse() >clc_string_from_unsigned_long() >etc. Hey, we do not program an OS called Microsoft Something. (They use really long things for short things.) You can add a #define in all your programs if you like so. #define clc_string_from_unsinged_long clc_ultostr - Jan Engelhardt |
|
From: regis <re...@in...> - 2003-04-03 17:58:36
|
Jan Engelhardt wrote: > > >> so that is a vote for ultostr? > > > >Mhh Yes, > >except that the mangled names of all the string functions suck. > > tell us a better name for uh ultostr()... > strfromul? clc_string_from_unsigned_long() -- Regis |
|
From: regis <re...@in...> - 2003-04-03 17:55:16
|
regis wrote: > > Jan Engelhardt wrote: > > > > so that is a vote for ultostr? > > Mhh Yes, > except that the mangled names of all the string functions suck. > Don't known if it has been discussed before, but I have a general remark about the inearface of the string function. I think most functions modifying / returning a string -- e.g. the function changing the letters to uppercase -- should allow the three following modes: 1) the output string is provided by the caller. For most function, it should be allowed that it is the input string itself. 2) the caller provide NULL for the result, and then the function allocates the memory for the output. in both cases, the output is returned. that is, char * clc_strupr(char *s) would become char * clc_strupr (char *output, char *input) By the way, what's the problem with clear and understandable function names like clc_string_to_uppercase() clc_string_to_lowercase() clc_string_reverse() clc_string_from_unsigned_long() etc. -- Regis |
1 message has been excluded from this view by a project administrator.
