Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101407 > unrolled thread

Correct way of doing string manipulation functions

Back to article view | Back to comp.lang.c

Contents

  Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-10 15:43 -0800
    Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-10 19:36 -0500
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:41 +0000
        Re: Correct way of doing string manipulation functions James Kuyper <jameskuyper@verizon.net> - 2017-01-11 07:19 -0500
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:36 -0800
    Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:41 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:54 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:38 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:24 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:38 +0000
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:02 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:28 -0800
          Re: Correct way of doing string manipulation functions Ian Collins <ian-news@hotmail.com> - 2017-01-11 18:19 +1300
            Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 02:40 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:18 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:37 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:23 -0800
    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 01:12 +0000
      Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 11:59 +0000
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:39 -0800
    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-10 17:55 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 18:21 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:21 +0000
        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:33 -0800
          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:43 -0800
          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 15:50 +0000
            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 08:07 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:46 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:04 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:37 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 05:47 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:14 -0800
                        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:34 -0800
                        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 07:38 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 07:59 -0800
              Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 22:24 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 03:30 -0800
                  Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 03:52 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 04:23 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:42 -0800
    Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-10 19:19 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:40 -0800
    Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-10 20:31 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:45 -0800
    Re: Correct way of doing string manipulation functions Gareth Owen <gwowen@gmail.com> - 2017-01-11 17:20 +0000
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 12:38 -0500
        Strings as first class citizens (Was: Correct way of doing string manipulation functions) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-11 17:53 +0000
          Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-11 12:46 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) fir <profesor.fir@gmail.com> - 2017-01-11 14:40 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Robert Wessel <robertwessel2@yahoo.com> - 2017-01-11 18:12 -0600
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-11 09:56 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:48 -0800
    Re: Correct way of doing string manipulation functions Thiago Adams <thiago.adams@gmail.com> - 2017-01-11 12:09 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:00 -0800
    Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:11 -0800
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 19:03 -0500
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 02:46 -0800
      Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-12 00:08 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 03:02 -0800
          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 11:38 +0000
            Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:51 +0000
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 14:41 +0000
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:32 -0800
            Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 18:15 +0000
            Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 11:46 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 13:52 -0800
            Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-12 16:50 -0800
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 00:59 +0000
                Re: Correct way of doing string manipulation functions raltbos@xs4all.nl (Richard Bos) - 2017-01-13 08:59 +0000
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:07 +0000
                  Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 10:11 -0800
                    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 18:49 +0000
                Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 08:43 -0800
                Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:45 -0800
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:17 +0000
                    Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:30 -0800
                      Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:48 +0000
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 11:02 -0800
                          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 19:15 +0000
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:18 -0800
                      Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 12:14 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:49 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:19 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:46 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 11:55 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 10:41 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:51 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 12:28 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:07 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 13:29 -0800
                          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 21:45 +0000
                            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:59 -0800
                              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 15:08 -0800
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 14:13 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:47 -0800
              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 08:02 -0800
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-12 07:50 -0800
        Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 08:37 -0800
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:41 -0800
      Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:39 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 18:02 -0800

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#101417

W dniu środa, 11 stycznia 2017 00:43:53 UTC+1 użytkownik Fernando D. Bozzo napisał:
> Hi all,
> 
> I'm starting at C but have a background on programmming in OOP.
> 
> My question is about string manipulation functions and the correct/best/good way of doing this in C.
> 
> I've made a function that returns just the filename of a given full path or url, which I use this way:
> 
> 
> // Suppose argv[1] is "http://www.myserver.com/file.html"
> char *text_out = justfname(argv[1]);
> printf("justfname = [%s]\n", text_out);
> free(text_out);
> 
> 
> 
> /**
>  * Returns the filename without path
>  * 
>  * Examples:
>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
>  */
> char *justfname(char *text_in)
> {
>     int len = strlen(text_in);
>     char *fname = NULL;
>     char *text_out = malloc(sizeof(text_in));
>     fname = strrchr(text_in, '/');
>     if (fname == NULL)
>     {
>         fname = strrchr(text_in, '\\');
>         if (fname == NULL)
>         {
>             fname = text_in;
>         }
>         else
>         {
>             fname++; // Advance address +1 (skip "\" char)
>         }
>     }
>     else
>     {
>         fname++; // Advance address +1 (skip "/" char)
>     }
> 
>     // Copy obtained data
>     strncpy(text_out, fname, len);
> 
>     return text_out;
> }
> 
> 
> 
> So my questions are:
> 1) Is this implementation ok/correct, or is there a better way of doing it?
> 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
> 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?
> 
> Thanks!

your implementation is wrong in many aspects
(firstly i dont think it works at all, returning 
mallocked ram is also very bad, also your names 
are not ok, esp "fname" ... and more)

in such simple case (where you sure name will be 
always at the end after last \ or / , and you will
be using this name only to read not to modify (all 
sane apis will be ok with that last assumption))
you can just return pointer to first char of the name, so you  will only need to find it

 char *ScanForPathOrURLName(char *text_in)
 {
  int k = strlen(text_in) - 1; //set on last char
 
  for(; k>=0; k--) //go down till first
  {
    if(  text_in[k] == '\\' )  break;
    if(  text_in[k] == '/' )   break;
  }
  return text_in + k + 1 ;
}

this is much better imo, but you as a user of this 
function should know assumptions (what it do and what not)

also not that this 
    justfname("c:\aaa\bbb\ccc\ddd.txt")             
you need to write as
    justfname("c:\\aaa\\bbb\\ccc\\ddd.txt")             

in more general case when you have no guarantee that 
some word is not necessary at the end of this string i
would also not mallocked not copied ram but found 
a begining and an end of searched data and return it as
a structure containing two pointers to the caller
(then he could copy it)

/fir/

[toc] | [prev] | [next] | [standalone]

#101418

On Tuesday, January 10, 2017 at 8:55:14 PM UTC-5, fir wrote:
> ...also your names 
> are not ok, esp "fname"

The names come from the Visual FoxPro language and a host of JUST*()
functions:

    justdrive()
    https://msdn.microsoft.com/en-us/library/aa977908(v=vs.71).aspx

    justext()
    https://msdn.microsoft.com/en-us/library/aa977909(v=vs.71).aspx

    justfname()
    https://msdn.microsoft.com/en-us/library/aa977910(v=vs.71).aspx

    justpath()
    https://msdn.microsoft.com/en-us/library/aa977911(v=vs.71).aspx

    juststem()
    https://msdn.microsoft.com/en-us/library/aa977912(v=vs.71).aspx

Each is designed to take a character string input, and return a
character string output, a copy of the original input ... so in
this case, a malloc()'d return value is correct.

Remember this, fir:

    One should learn before one teaches.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#101421

fir <profesor.fir@gmail.com> writes:

> W dniu środa, 11 stycznia 2017 00:43:53 UTC+1 użytkownik Fernando
> D. Bozzo napisał:
>> Hi all,
>> 
>> I'm starting at C but have a background on programmming in OOP.
>> 
>> My question is about string manipulation functions and the correct/best/good way of doing this in C.
>> 
>> I've made a function that returns just the filename of a given full path or url, which I use this way:
>> 
>> 
>> // Suppose argv[1] is "http://www.myserver.com/file.html"
>> char *text_out = justfname(argv[1]);
>> printf("justfname = [%s]\n", text_out);
>> free(text_out);
>> 
>> 
>> 
>> /**
>>  * Returns the filename without path
>>  * 
>>  * Examples:
>>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
>>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
>>  */
>> char *justfname(char *text_in)
>> {
>>     int len = strlen(text_in);
>>     char *fname = NULL;
>>     char *text_out = malloc(sizeof(text_in));
>>     fname = strrchr(text_in, '/');
>>     if (fname == NULL)
>>     {
>>         fname = strrchr(text_in, '\\');
>>         if (fname == NULL)
>>         {
>>             fname = text_in;
>>         }
>>         else
>>         {
>>             fname++; // Advance address +1 (skip "\" char)
>>         }
>>     }
>>     else
>>     {
>>         fname++; // Advance address +1 (skip "/" char)
>>     }
>> 
>>     // Copy obtained data
>>     strncpy(text_out, fname, len);
>> 
>>     return text_out;
>> }
>> 
>> 
>> 
>> So my questions are:
>> 1) Is this implementation ok/correct, or is there a better way of doing it?
>> 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
>> 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?
>> 
>> Thanks!
>
> your implementation is wrong in many aspects
> (firstly i dont think it works at all, returning 
> mallocked ram is also very bad, also your names 
> are not ok, esp "fname" ... and more)
>
> in such simple case (where you sure name will be always at the end
> after last \ or / , and you will be using this name only to read not
> to modify (all sane apis will be ok with that last assumption)) you
> can just return pointer to first char of the name, so you will only
> need to find it

You also have to be sure that the lifetime of the returned pointer is
not used after the end of the array's life.

>  char *ScanForPathOrURLName(char *text_in)

You can help document some of the assumption by using const:

  const char *ScanForPathOrURLName(const char *text_in)

>  {
>   int k = strlen(text_in) - 1; //set on last char

This does not handle an empty input ("").  And it's not the most
portable because size_t values can be larger than an int can represent.
You may be ruling out those possibilities, but it's good to document
such assumption in a comment.

>   for(; k>=0; k--) //go down till first
>   {
>     if(  text_in[k] == '\\' )  break;
>     if(  text_in[k] == '/' )   break;
>   }
>   return text_in + k + 1 ;
> }

I think the answer for "c:file" should be "path" rather than "c:file".

Another way:

  const char *file_ptr = text_in;
  for (const char *cp = text_in; *cp; cp++)
       if (*cp == '/' || *cp == '\\' || *cp == ':')
           file_ptr = cp;
  return file_ptr + (file_ptr != text_in);

though maybe less tricksy would be

  const char *file_ptr = 0;
  for (const char *cp = text_in; *cp; cp++)
       if (*cp == '/' || *cp == '\\' || *cp == ':')
           file_ptr = cp;
  return file_ptr ? text_in : file_ptr + 1;

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101436

W dniu środa, 11 stycznia 2017 04:21:19 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu środa, 11 stycznia 2017 00:43:53 UTC+1 użytkownik Fernando
> > D. Bozzo napisał:
> >> Hi all,
> >> 
> >> I'm starting at C but have a background on programmming in OOP.
> >> 
> >> My question is about string manipulation functions and the correct/best/good way of doing this in C.
> >> 
> >> I've made a function that returns just the filename of a given full path or url, which I use this way:
> >> 
> >> 
> >> // Suppose argv[1] is "http://www.myserver.com/file.html"
> >> char *text_out = justfname(argv[1]);
> >> printf("justfname = [%s]\n", text_out);
> >> free(text_out);
> >> 
> >> 
> >> 
> >> /**
> >>  * Returns the filename without path
> >>  * 
> >>  * Examples:
> >>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
> >>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
> >>  */
> >> char *justfname(char *text_in)
> >> {
> >>     int len = strlen(text_in);
> >>     char *fname = NULL;
> >>     char *text_out = malloc(sizeof(text_in));
> >>     fname = strrchr(text_in, '/');
> >>     if (fname == NULL)
> >>     {
> >>         fname = strrchr(text_in, '\\');
> >>         if (fname == NULL)
> >>         {
> >>             fname = text_in;
> >>         }
> >>         else
> >>         {
> >>             fname++; // Advance address +1 (skip "\" char)
> >>         }
> >>     }
> >>     else
> >>     {
> >>         fname++; // Advance address +1 (skip "/" char)
> >>     }
> >> 
> >>     // Copy obtained data
> >>     strncpy(text_out, fname, len);
> >> 
> >>     return text_out;
> >> }
> >> 
> >> 
> >> 
> >> So my questions are:
> >> 1) Is this implementation ok/correct, or is there a better way of doing it?
> >> 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
> >> 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?
> >> 
> >> Thanks!
> >
> > your implementation is wrong in many aspects
> > (firstly i dont think it works at all, returning 
> > mallocked ram is also very bad, also your names 
> > are not ok, esp "fname" ... and more)
> >
> > in such simple case (where you sure name will be always at the end
> > after last \ or / , and you will be using this name only to read not
> > to modify (all sane apis will be ok with that last assumption)) you
> > can just return pointer to first char of the name, so you will only
> > need to find it
> 
> You also have to be sure that the lifetime of the returned pointer is
> not used after the end of the array's life.
> 
> >  char *ScanForPathOrURLName(char *text_in)
> 
> You can help document some of the assumption by using const:
> 
>   const char *ScanForPathOrURLName(const char *text_in)
> 
> >  {
> >   int k = strlen(text_in) - 1; //set on last char
> 
> This does not handle an empty input ("").  And it's not the most
> portable because size_t values can be larger than an int can represent.
> You may be ruling out those possibilities, but it's good to document
> such assumption in a comment.
> 
> >   for(; k>=0; k--) //go down till first
> >   {
> >     if(  text_in[k] == '\\' )  break;
> >     if(  text_in[k] == '/' )   break;
> >   }
> >   return text_in + k + 1 ;
> > }
> 
> I think the answer for "c:file" should be "path" rather than "c:file".
> 
> Another way:
> 
>   const char *file_ptr = text_in;
>   for (const char *cp = text_in; *cp; cp++)
>        if (*cp == '/' || *cp == '\\' || *cp == ':')
>            file_ptr = cp;
>   return file_ptr + (file_ptr != text_in);
> 
> though maybe less tricksy would be
> 
>   const char *file_ptr = 0;
>   for (const char *cp = text_in; *cp; cp++)
>        if (*cp == '/' || *cp == '\\' || *cp == ':')
>            file_ptr = cp;
>   return file_ptr ? text_in : file_ptr + 1;
> 
> <snip>
> -- 
> Ben.

i disagree, my version (where i just dont care for const and size_t etc) feel better to me 

the only doubtfull thing i see is name of the function, 

(here i could probably rate it 5/10) but function naming is hard thing and maybe i not developed full rules here yet..

[toc] | [prev] | [next] | [standalone]

#101438

W dniu środa, 11 stycznia 2017 16:33:47 UTC+1 użytkownik fir napisał:
> 
> i disagree, my version (where i just dont care for const and size_t etc) feel better to me 
> 
> the only doubtfull thing i see is name of the function, 
> 
> (here i could probably rate it 5/10) but function naming is hard thing and maybe i not developed full rules here yet..

ye the name is bad.. this name is somewhat made by some 
who knows what the function is doin and it should be
made like for some who do not knows what it is doin

maybe ExtractFilenameFromPathOrUrl bould be better 
or FildFilenameInPathOrUrl (this is in school that chose writing whole sentences as function names as i do,
it looks like a bit ugly but its descriptive - other school 
uses schort names, it looks like better (quicker to read)
but i do not chose it)

[toc] | [prev] | [next] | [standalone]

#101439

On 11/01/2017 15:33, fir wrote:
> W dniu środa, 11 stycznia 2017 04:21:19 UTC+1 użytkownik Ben Bacarisse napisał:

>>   const char *ScanForPathOrURLName(const char *text_in)

> i disagree, my version (where i just dont care for const and size_t etc) feel better to me

I agree. I never bother with const, nor with size_t if I know or expect 
the size to be within the range of an int.

> the only doubtfull thing i see is name of the function,
>
> (here i could probably rate it 5/10) but function naming is hard thing and maybe i not developed full rules here yet..

My version of this function is called extractfile(), returning a pointer 
into the filespec.

Related functions are extractpath(), extractext() and extractbasefile, 
which are a little more complex in how they return their value, or (with 
getting the extension), in whether to return a null extension as "" or ".").

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#101440

W dniu środa, 11 stycznia 2017 16:50:50 UTC+1 użytkownik Bart napisał:
> On 11/01/2017 15:33, fir wrote:
> > W dniu środa, 11 stycznia 2017 04:21:19 UTC+1 użytkownik Ben Bacarisse napisał:
> 
> >>   const char *ScanForPathOrURLName(const char *text_in)
> 
> > i disagree, my version (where i just dont care for const and size_t etc) feel better to me
> 
> I agree. I never bother with const, nor with size_t if I know or expect 
> the size to be within the range of an int.
> 

me too

> > the only doubtfull thing i see is name of the function,
> >
> > (here i could probably rate it 5/10) but function naming is hard thing and maybe i not developed full rules here yet..
> 
> My version of this function is called extractfile(), returning a pointer 
> into the filespec.
> 
> Related functions are extractpath(), extractext() and extractbasefile, 
> which are a little more complex in how they return their value, or (with 
> getting the extension), in whether to return a null extension as "" or ".").
> 

as i said there are two schools short names amd long 
names (i use long names, it is slower to read, looks less pro, i dont ewan can say some arguments why i use it but i use it - maybe i will change someday i dont know)


extract dont feel totally fortunate to me, but as i said 
naming is especially hard - maybe 'take' woud be better 
TakeFileNameFromPathOrUrl() ? (thinking to long on such questions is burdensome so i usually get on compromises
and just chose something and dont much care)


> -- 
> bartc

[toc] | [prev] | [next] | [standalone]

#101483

Hi John:

I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.

One case on which I use larger names is when doing unit testing to express the case under test.


El miércoles, 11 de enero de 2017, 17:08:07 (UTC+1), fir  escribió:
> W dniu środa, 11 stycznia 2017 16:50:50 UTC+1 użytkownik Bart napisał:
> > On 11/01/2017 15:33, fir wrote:
> > > W dniu środa, 11 stycznia 2017 04:21:19 UTC+1 użytkownik Ben Bacarisse napisał:
> > 
> > >>   const char *ScanForPathOrURLName(const char *text_in)
> > 
> > > i disagree, my version (where i just dont care for const and size_t etc) feel better to me
> > 
> > I agree. I never bother with const, nor with size_t if I know or expect 
> > the size to be within the range of an int.
> > 
> 
> me too
> 
> > > the only doubtfull thing i see is name of the function,
> > >
> > > (here i could probably rate it 5/10) but function naming is hard thing and maybe i not developed full rules here yet..
> > 
> > My version of this function is called extractfile(), returning a pointer 
> > into the filespec.
> > 
> > Related functions are extractpath(), extractext() and extractbasefile, 
> > which are a little more complex in how they return their value, or (with 
> > getting the extension), in whether to return a null extension as "" or ".").
> > 
> 
> as i said there are two schools short names amd long 
> names (i use long names, it is slower to read, looks less pro, i dont ewan can say some arguments why i use it but i use it - maybe i will change someday i dont know)
> 
> 
> extract dont feel totally fortunate to me, but as i said 
> naming is especially hard - maybe 'take' woud be better 
> TakeFileNameFromPathOrUrl() ? (thinking to long on such questions is burdensome so i usually get on compromises
> and just chose something and dont much care)
> 
> 
> > -- 
> > bartc

[toc] | [prev] | [next] | [standalone]

#101508

W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> Hi John:
> 
> I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> 
> One case on which I use larger names is when doing unit testing to express the case under test.
> 
there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary

i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
different functions in separate modules or applications 
(if they are internel they may overlap, if c would have
'module prefixes' external could also overlap ) ) 

so i am not saying maybe that longer is better but 
you may also consider you break 3 important rules 
of naming some coders use (including me)

1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
(indeed if you use abbreviations you wuickly will live in
a word of your ovn abbreviations)
2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
3) build function names around 'verbs' (it makes a category of functions feel more consistent)

(ps im not personally a naming master and this above is still only a partial insight on naming domain)

maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
though i dont see it much) eventually all 3 could be
dropped but some would need to propose some concise 
replacement (i was not worked on it)

[toc] | [prev] | [next] | [standalone]

#101512

W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > Hi John:
> > 
> > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > 
> > One case on which I use larger names is when doing unit testing to express the case under test.
> > 
> there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> 
> i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> different functions in separate modules or applications 
> (if they are internel they may overlap, if c would have
> 'module prefixes' external could also overlap ) ) 
> 
> so i am not saying maybe that longer is better but 
> you may also consider you break 3 important rules 
> of naming some coders use (including me)
> 
> 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> (indeed if you use abbreviations you wuickly will live in
> a word of your ovn abbreviations)
> 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> 
> (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> 
> maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> though i dont see it much) eventually all 3 could be
> dropped but some would need to propose some concise 
> replacement (i was not worked on it)

those rules may not make my coding perfect but they allow
to me abstract away whole category of problems, so i once
decided to use it for simplicity
(though maybe it is not ambitious, for long time i was not thinked on this )

[toc] | [prev] | [next] | [standalone]

#101520

W dniu czwartek, 12 stycznia 2017 12:37:36 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> > W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > > Hi John:
> > > 
> > > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > > 
> > > One case on which I use larger names is when doing unit testing to express the case under test.
> > > 
> > there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> > 
> > i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> > different functions in separate modules or applications 
> > (if they are internel they may overlap, if c would have
> > 'module prefixes' external could also overlap ) ) 
> > 
> > so i am not saying maybe that longer is better but 
> > you may also consider you break 3 important rules 
> > of naming some coders use (including me)
> > 
> > 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> > (indeed if you use abbreviations you wuickly will live in
> > a word of your ovn abbreviations)
> > 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> > 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> > 
> > (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> > 
> > maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> > though i dont see it much) eventually all 3 could be
> > dropped but some would need to propose some concise 
> > replacement (i was not worked on it)
> 
> those rules may not make my coding perfect but they allow
> to me abstract away whole category of problems, so i once
> decided to use it for simplicity
> (though maybe it is not ambitious, for long time i was not thinked on this )

maybe i will say yet a words why it is good to talk with newbs (some newbs)

i sometimes feel that talking with nebs (some newbs, alla not included) is good, it is probably becouse newbs are in such state when things (like language, customs, apps etc) 
are yet not defined, they are in some kind of root state

this root state can be at least just partially forgotten
by regs.. (got no beter name for non-newbs right now)
thiose regs define things (know how they are defined),
things may be defined more or less good, but this root
state always open a gate to the things be defined much
better

(people also tend to forget that redefinition of some things can change a lot and may bring a lot of value)

(those things are sadly a bit banal but are important,
maybe some time later i would be able to say more here)

\fir\

[toc] | [prev] | [next] | [standalone]

#101522

W dniu czwartek, 12 stycznia 2017 14:48:00 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 12 stycznia 2017 12:37:36 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> > > W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > > > Hi John:
> > > > 
> > > > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > > > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > > > 
> > > > One case on which I use larger names is when doing unit testing to express the case under test.
> > > > 
> > > there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> > > 
> > > i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> > > different functions in separate modules or applications 
> > > (if they are internel they may overlap, if c would have
> > > 'module prefixes' external could also overlap ) ) 
> > > 
> > > so i am not saying maybe that longer is better but 
> > > you may also consider you break 3 important rules 
> > > of naming some coders use (including me)
> > > 
> > > 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> > > (indeed if you use abbreviations you wuickly will live in
> > > a word of your ovn abbreviations)
> > > 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> > > 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> > > 
> > > (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> > > 
> > > maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> > > though i dont see it much) eventually all 3 could be
> > > dropped but some would need to propose some concise 
> > > replacement (i was not worked on it)
> > 
> > those rules may not make my coding perfect but they allow
> > to me abstract away whole category of problems, so i once
> > decided to use it for simplicity
> > (though maybe it is not ambitious, for long time i was not thinked on this )
> 
> maybe i will say yet a words why it is good to talk with newbs (some newbs)
> 
> i sometimes feel that talking with nebs (some newbs, alla not included) is good, it is probably becouse newbs are in such state when things (like language, customs, apps etc) 
> are yet not defined, they are in some kind of root state
> 
> this root state can be at least just partially forgotten
> by regs.. (got no beter name for non-newbs right now)
> thiose regs define things (know how they are defined),
> things may be defined more or less good, but this root
> state always open a gate to the things be defined much
> better
> 
> (people also tend to forget that redefinition of some things can change a lot and may bring a lot of value)
> 
> (those things are sadly a bit banal but are important,
> maybe some time later i would be able to say more here)
> 
> \fir\

i could even say that nevbs have higher perception (on root things) [even comparing to me who theoretically likes root (fundaments) studies] why they got it? im not sure maybe it is becouse they use quite different view (where things are undefined) and i use my point of view (where things are defined) thus i need a work to change the view temporarely where they got it for free.. when you define ways of wiev
you lost perception (sad, becouse this free perception
is so fine) (sad im so old, 40 now, and think my age is also responsible for my overal and final bad level )

[toc] | [prev] | [next] | [standalone]

#101524

W dniu czwartek, 12 stycznia 2017 15:15:10 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 12 stycznia 2017 14:48:00 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 12 stycznia 2017 12:37:36 UTC+1 użytkownik fir napisał:
> > > W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> > > > W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > > > > Hi John:
> > > > > 
> > > > > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > > > > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > > > > 
> > > > > One case on which I use larger names is when doing unit testing to express the case under test.
> > > > > 
> > > > there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> > > > 
> > > > i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> > > > different functions in separate modules or applications 
> > > > (if they are internel they may overlap, if c would have
> > > > 'module prefixes' external could also overlap ) ) 
> > > > 
> > > > so i am not saying maybe that longer is better but 
> > > > you may also consider you break 3 important rules 
> > > > of naming some coders use (including me)
> > > > 
> > > > 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> > > > (indeed if you use abbreviations you wuickly will live in
> > > > a word of your ovn abbreviations)
> > > > 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> > > > 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> > > > 
> > > > (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> > > > 
> > > > maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> > > > though i dont see it much) eventually all 3 could be
> > > > dropped but some would need to propose some concise 
> > > > replacement (i was not worked on it)
> > > 
> > > those rules may not make my coding perfect but they allow
> > > to me abstract away whole category of problems, so i once
> > > decided to use it for simplicity
> > > (though maybe it is not ambitious, for long time i was not thinked on this )
> > 
> > maybe i will say yet a words why it is good to talk with newbs (some newbs)
> > 
> > i sometimes feel that talking with nebs (some newbs, alla not included) is good, it is probably becouse newbs are in such state when things (like language, customs, apps etc) 
> > are yet not defined, they are in some kind of root state
> > 
> > this root state can be at least just partially forgotten
> > by regs.. (got no beter name for non-newbs right now)
> > thiose regs define things (know how they are defined),
> > things may be defined more or less good, but this root
> > state always open a gate to the things be defined much
> > better
> > 
> > (people also tend to forget that redefinition of some things can change a lot and may bring a lot of value)
> > 
> > (those things are sadly a bit banal but are important,
> > maybe some time later i would be able to say more here)
> > 
> > \fir\
> 
> i could even say that nevbs have higher perception (on root things) [even comparing to me who theoretically likes root (fundaments) studies] why they got it? im not sure maybe it is becouse they use quite different view (where things are undefined) and i use my point of view (where things are defined) thus i need a work to change the view temporarely where they got it for free.. when you define ways of wiev
> you lost perception (sad, becouse this free perception
> is so fine) (sad im so old, 40 now, and think my age is also responsible for my overal and final bad level )

note also that this increased perception is maybe less on
programming but more on ones approach/ relation to programming.. im talking more on this part and its content

should go to eat something,

[toc] | [prev] | [next] | [standalone]

#101526

El jueves, 12 de enero de 2017, 15:15:10 (UTC+1), fir  escribió:
> W dniu czwartek, 12 stycznia 2017 14:48:00 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 12 stycznia 2017 12:37:36 UTC+1 użytkownik fir napisał:
> > > W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> > > > W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > > > > Hi John:
> > > > > 
> > > > > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > > > > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > > > > 
> > > > > One case on which I use larger names is when doing unit testing to express the case under test.
> > > > > 
> > > > there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> > > > 
> > > > i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> > > > different functions in separate modules or applications 
> > > > (if they are internel they may overlap, if c would have
> > > > 'module prefixes' external could also overlap ) ) 
> > > > 
> > > > so i am not saying maybe that longer is better but 
> > > > you may also consider you break 3 important rules 
> > > > of naming some coders use (including me)
> > > > 
> > > > 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> > > > (indeed if you use abbreviations you wuickly will live in
> > > > a word of your ovn abbreviations)
> > > > 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> > > > 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> > > > 
> > > > (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> > > > 
> > > > maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> > > > though i dont see it much) eventually all 3 could be
> > > > dropped but some would need to propose some concise 
> > > > replacement (i was not worked on it)
> > > 
> > > those rules may not make my coding perfect but they allow
> > > to me abstract away whole category of problems, so i once
> > > decided to use it for simplicity
> > > (though maybe it is not ambitious, for long time i was not thinked on this )
> > 
> > maybe i will say yet a words why it is good to talk with newbs (some newbs)
> > 
> > i sometimes feel that talking with nebs (some newbs, alla not included) is good, it is probably becouse newbs are in such state when things (like language, customs, apps etc) 
> > are yet not defined, they are in some kind of root state
> > 
> > this root state can be at least just partially forgotten
> > by regs.. (got no beter name for non-newbs right now)
> > thiose regs define things (know how they are defined),
> > things may be defined more or less good, but this root
> > state always open a gate to the things be defined much
> > better
> > 
> > (people also tend to forget that redefinition of some things can change a lot and may bring a lot of value)
> > 
> > (those things are sadly a bit banal but are important,
> > maybe some time later i would be able to say more here)
> > 
> > \fir\
> 
> i could even say that nevbs have higher perception (on root things) [even comparing to me who theoretically likes root (fundaments) studies] why they got it? im not sure maybe it is becouse they use quite different view (where things are undefined) and i use my point of view (where things are defined) thus i need a work to change the view temporarely where they got it for free.. when you define ways of wiev
> you lost perception (sad, becouse this free perception
> is so fine) (sad im so old, 40 now, and think my age is also responsible for my overal and final bad level )


I'm with you with the part that newbs (in some language in this case) sometimes bring you a different view and even can make you remember something you did forget because tested once ande never used it (happened to me:) The good thing is that if one consider itself good in what he/she do and like to keep learning, then there is a lot to learn from others, indifferent of their technical level.

I think that the age have nothing to do with the level. One can learn at every age, but not everybody do it or like doing it.\0 => (string termination:)

[toc] | [prev] | [next] | [standalone]

#101528

W dniu czwartek, 12 stycznia 2017 16:39:03 UTC+1 użytkownik Fernando D. Bozzo napisał:
> El jueves, 12 de enero de 2017, 15:15:10 (UTC+1), fir  escribió:
> > W dniu czwartek, 12 stycznia 2017 14:48:00 UTC+1 użytkownik fir napisał:
> > > W dniu czwartek, 12 stycznia 2017 12:37:36 UTC+1 użytkownik fir napisał:
> > > > W dniu czwartek, 12 stycznia 2017 12:04:59 UTC+1 użytkownik fir napisał:
> > > > > W dniu środa, 11 stycznia 2017 23:46:44 UTC+1 użytkownik Fernando D. Bozzo napisał:
> > > > > > Hi John:
> > > > > > 
> > > > > > I take naming seriously, but I try to balance between readability, usefulness, usability and verbosity, "justfname" is almost acronym of "just file name", which is not too short and easy to remember.
> > > > > > Your function name could be right, but I find it large in excess. Simple concepts should be kept compact and easily readable and not too large.
> > > > > > 
> > > > > > One case on which I use larger names is when doing unit testing to express the case under test.
> > > > > > 
> > > > > there are two main naming schols maybe: short names which are quicker to read but less descriptive, and long names which itself works like commentary
> > > > > 
> > > > > i am not totally decided which one is better.. some could say that is quick is readable quick is better maybe (though it is more comples thing for example short names are somewhat like "local names" where same names may overlap 
> > > > > different functions in separate modules or applications 
> > > > > (if they are internel they may overlap, if c would have
> > > > > 'module prefixes' external could also overlap ) ) 
> > > > > 
> > > > > so i am not saying maybe that longer is better but 
> > > > > you may also consider you break 3 important rules 
> > > > > of naming some coders use (including me)
> > > > > 
> > > > > 1) dont use acrontyms/abbreviations (as given name may be abbreviated in many ways it produces a lot of chaos) 
> > > > > (indeed if you use abbreviations you wuickly will live in
> > > > > a word of your ovn abbreviations)
> > > > > 2) dont use local (short, potentially overlapping, 'despecyficated') names, use global (specyfic) names 
> > > > > 3) build function names around 'verbs' (it makes a category of functions feel more consistent)
> > > > > 
> > > > > (ps im not personally a naming master and this above is still only a partial insight on naming domain)
> > > > > 
> > > > > maybe the second rule can be eventually dropped, but right now i consider all 3 as a reasonable to me (first seem strongest to me here, 2nd could be maybe also dropped
> > > > > though i dont see it much) eventually all 3 could be
> > > > > dropped but some would need to propose some concise 
> > > > > replacement (i was not worked on it)
> > > > 
> > > > those rules may not make my coding perfect but they allow
> > > > to me abstract away whole category of problems, so i once
> > > > decided to use it for simplicity
> > > > (though maybe it is not ambitious, for long time i was not thinked on this )
> > > 
> > > maybe i will say yet a words why it is good to talk with newbs (some newbs)
> > > 
> > > i sometimes feel that talking with nebs (some newbs, alla not included) is good, it is probably becouse newbs are in such state when things (like language, customs, apps etc) 
> > > are yet not defined, they are in some kind of root state
> > > 
> > > this root state can be at least just partially forgotten
> > > by regs.. (got no beter name for non-newbs right now)
> > > thiose regs define things (know how they are defined),
> > > things may be defined more or less good, but this root
> > > state always open a gate to the things be defined much
> > > better
> > > 
> > > (people also tend to forget that redefinition of some things can change a lot and may bring a lot of value)
> > > 
> > > (those things are sadly a bit banal but are important,
> > > maybe some time later i would be able to say more here)
> > > 
> > > \fir\
> > 
> > i could even say that nevbs have higher perception (on root things) [even comparing to me who theoretically likes root (fundaments) studies] why they got it? im not sure maybe it is becouse they use quite different view (where things are undefined) and i use my point of view (where things are defined) thus i need a work to change the view temporarely where they got it for free.. when you define ways of wiev
> > you lost perception (sad, becouse this free perception
> > is so fine) (sad im so old, 40 now, and think my age is also responsible for my overal and final bad level )
> 
> 
> I'm with you with the part that newbs (in some language in this case) sometimes bring you a different view and even can make you remember something you did forget because tested once ande never used it (happened to me:) The good thing is that if one consider itself good in what he/she do and like to keep learning, then there is a lot to learn from others, indifferent of their technical level.
> 
> I think that the age have nothing to do with the level. One can learn at every age, but not everybody do it or like doing it.\0 => (string termination:)

sadly stating things like this you become a reg - fellow who define something defines out all other and accepts that; it is wiser to not define/state but perceptuate 
the living potential
(dont quite know how to do that, as myself i define a lot)

[toc] | [prev] | [next] | [standalone]

#101832

fir <profesor.fir@gmail.com> writes:

> W dniu ?roda, 11 stycznia 2017 16:50:50 UTC+1 u?ytkownik Bart napisa?:
>> On 11/01/2017 15:33, fir wrote:
>>> W dniu ?roda, 11 stycznia 2017 04:21:19 UTC+1 u?ytkownik Ben Bacarisse napisa?:
>>>
>>>>   const char *ScanForPathOrURLName(const char *text_in)
>>>
>>> i disagree, my version (where i just dont care for const and size_t
>>> etc) feel better to me
>>
>> I agree.  I never bother with const, nor with size_t if I know or
>> expect the size to be within the range of an int.
>
> me too
>
>>> the only doubtfull thing i see is name of the function,
>>>
>>> (here i could probably rate it 5/10) but function naming is hard
>>> thing and maybe i not developed full rules here yet..
>>
>> My version of this function is called extractfile(), returning a
>> pointer into the filespec.
>>
>> Related functions are extractpath(), extractext() and extractbasefile,
>> which are a little more complex in how they return their value, or
>> (with getting the extension), in whether to return a null extension as
>> "" or ".").
>
> as i said there are two schools short names amd long names [...]

I would say there is at least one other view, namely, for some
names it's important for them not to be overly terse (ie, they
should be "long"), whereas for certain other names it's okay
or sometimes better than just okay that they be short.

Choosing good names is hard, and there is no simple formula.
Almost everyone has rules of thumb that they follow, or
conventions about how names are chosen, or both.  Having such
rules and conventions definitely provides value, but at the same
time it's a mistake for naming choices to be too rigid, or to
assume that the "laxness" or "rigidity" of various rules should
be the same in all cases.  A good set of naming conventions will
allow more freedom along some axes and less freedom along other
axes.  Good developers will make an effort to cultivate and
exercise effective judgment in those areas where there is more
freedom to make choices.  They also will make an effort to
broaden their range both for reading code and for writing it.  In
almost all cases any particular set of name choices will have
both pluses and minuses;  the judgment comes not in deciding what
is "best" but deciding when the current set of design choices is
good enough, so that the work can go forward and proceed on to
other design choices.

[toc] | [prev] | [next] | [standalone]

#101840

W dniu niedziela, 15 stycznia 2017 07:24:32 UTC+1 użytkownik Tim Rentsch napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu ?roda, 11 stycznia 2017 16:50:50 UTC+1 u?ytkownik Bart napisa?:
> >> On 11/01/2017 15:33, fir wrote:
> >>> W dniu ?roda, 11 stycznia 2017 04:21:19 UTC+1 u?ytkownik Ben Bacarisse napisa?:
> >>>
> >>>>   const char *ScanForPathOrURLName(const char *text_in)
> >>>
> >>> i disagree, my version (where i just dont care for const and size_t
> >>> etc) feel better to me
> >>
> >> I agree.  I never bother with const, nor with size_t if I know or
> >> expect the size to be within the range of an int.
> >
> > me too
> >
> >>> the only doubtfull thing i see is name of the function,
> >>>
> >>> (here i could probably rate it 5/10) but function naming is hard
> >>> thing and maybe i not developed full rules here yet..
> >>
> >> My version of this function is called extractfile(), returning a
> >> pointer into the filespec.
> >>
> >> Related functions are extractpath(), extractext() and extractbasefile,
> >> which are a little more complex in how they return their value, or
> >> (with getting the extension), in whether to return a null extension as
> >> "" or ".").
> >
> > as i said there are two schools short names amd long names [...]
> 
> I would say there is at least one other view, namely, for some
> names it's important for them not to be overly terse (ie, they
> should be "long"), whereas for certain other names it's okay
> or sometimes better than just okay that they be short.
> 
> Choosing good names is hard, and there is no simple formula.
> Almost everyone has rules of thumb that they follow, or
> conventions about how names are chosen, or both.  Having such
> rules and conventions definitely provides value, but at the same
> time it's a mistake for naming choices to be too rigid, or to
> assume that the "laxness" or "rigidity" of various rules should
> be the same in all cases.  A good set of naming conventions will
> allow more freedom along some axes and less freedom along other
> axes.  Good developers will make an effort to cultivate and
> exercise effective judgment in those areas where there is more
> freedom to make choices.  They also will make an effort to
> broaden their range both for reading code and for writing it.  In
> almost all cases any particular set of name choices will have
> both pluses and minuses;  the judgment comes not in deciding what
> is "best" but deciding when the current set of design choices is
> good enough, so that the work can go forward and proceed on to
> other design choices.

its tru but talking that "naming rules are used" or "various naming rules are used" is less worth/valuable than speaking about specific rules
(wort stating maybe that present naming rules are very badly constrained by set of chars that could be used 
in identifiers in c - i would strongly like more 
characters in identifiers 

my own invention/decision to use 0x60 ascii char (so called grave accent) for making identifiers containing more ascii chars (like spaces and other)

int `ssd jj` = 10;

seem to be quite good (quite good lookin, ascii, even quite handy to type) 

other way is to incorporate more chars in identifiers 
(this is troublesome as i dont love unicode to much, but probably should be done or at least considered) or make 
also some changes to c 'syntaxer' 
(im not even sure if some 'skinning layer' over c couldnt be used allowing c to be common 'engine' under some skinning layers which would allow c code lookin in various 
ways (even not neccessary classic left to right with simple typescript, but maybe more variously geometrical (in various code geometries))

present poor identifier charset-related posibilities makes
c coding a bit sad - though are also and still important and i feel some probably could do important things in this space (im not much good in this layer, i use simple rules i 
mentioned and the visual outcome of this is not much appealing)

[toc] | [prev] | [next] | [standalone]

#101842

El domingo, 15 de enero de 2017, 12:30:22 (UTC+1), fir  escribió:
> W dniu niedziela, 15 stycznia 2017 07:24:32 UTC+1 użytkownik Tim Rentsch napisał:
> > fir writes:
> > 
> > > W dniu ?roda, 11 stycznia 2017 16:50:50 UTC+1 u?ytkownik Bart napisa?:
> > >> On 11/01/2017 15:33, fir wrote:
> > >>> W dniu ?roda, 11 stycznia 2017 04:21:19 UTC+1 u?ytkownik Ben Bacarisse napisa?:
> > >>>
> > >>>>   const char *ScanForPathOrURLName(const char *text_in)
> > >>>
> > >>> i disagree, my version (where i just dont care for const and size_t
> > >>> etc) feel better to me
> > >>
> > >> I agree.  I never bother with const, nor with size_t if I know or
> > >> expect the size to be within the range of an int.
> > >
> > > me too
> > >
> > >>> the only doubtfull thing i see is name of the function,
> > >>>
> > >>> (here i could probably rate it 5/10) but function naming is hard
> > >>> thing and maybe i not developed full rules here yet..
> > >>
> > >> My version of this function is called extractfile(), returning a
> > >> pointer into the filespec.
> > >>
> > >> Related functions are extractpath(), extractext() and extractbasefile,
> > >> which are a little more complex in how they return their value, or
> > >> (with getting the extension), in whether to return a null extension as
> > >> "" or ".").
> > >
> > > as i said there are two schools short names amd long names [...]
> > 
> > I would say there is at least one other view, namely, for some
> > names it's important for them not to be overly terse (ie, they
> > should be "long"), whereas for certain other names it's okay
> > or sometimes better than just okay that they be short.
> > 
> > Choosing good names is hard, and there is no simple formula.
> > Almost everyone has rules of thumb that they follow, or
> > conventions about how names are chosen, or both.  Having such
> > rules and conventions definitely provides value, but at the same
> > time it's a mistake for naming choices to be too rigid, or to
> > assume that the "laxness" or "rigidity" of various rules should
> > be the same in all cases.  A good set of naming conventions will
> > allow more freedom along some axes and less freedom along other
> > axes.  Good developers will make an effort to cultivate and
> > exercise effective judgment in those areas where there is more
> > freedom to make choices.  They also will make an effort to
> > broaden their range both for reading code and for writing it.  In
> > almost all cases any particular set of name choices will have
> > both pluses and minuses;  the judgment comes not in deciding what
> > is "best" but deciding when the current set of design choices is
> > good enough, so that the work can go forward and proceed on to
> > other design choices.
> 
> its tru but talking that "naming rules are used" or "various naming rules are used" is less worth/valuable than speaking about specific rules
> (wort stating maybe that present naming rules are very badly constrained by set of chars that could be used 
> in identifiers in c - i would strongly like more 
> characters in identifiers 
> 
> my own invention/decision to use 0x60 ascii char (so called grave accent) for making identifiers containing more ascii chars (like spaces and other)
> 
> int `ssd jj` = 10;
> 
> seem to be quite good (quite good lookin, ascii, even quite handy to type) 
> 
> other way is to incorporate more chars in identifiers 
> (this is troublesome as i dont love unicode to much, but probably should be done or at least considered) or make 
> also some changes to c 'syntaxer' 
> (im not even sure if some 'skinning layer' over c couldnt be used allowing c to be common 'engine' under some skinning layers which would allow c code lookin in various 
> ways (even not neccessary classic left to right with simple typescript, but maybe more variously geometrical (in various code geometries))
> 
> present poor identifier charset-related posibilities makes
> c coding a bit sad - though are also and still important and i feel some probably could do important things in this space (im not much good in this layer, i use simple rules i 
> mentioned and the visual outcome of this is not much appealing)


I think that if you want to standarize (which is something good) it's better traying to use something useful in many languages and not something that can be used only in one. In this case your suggestion of using `this type` of naming is not good at all. You can use thisType or this_type of naming that works in almost all languages and is understood by majority of developers in the world.

Even if you like your naming convention, if you are aware of team development (Open Source, private, whatever) and maintainability, then you shouldn't use it. Even if you are the only dev on your place, some day another dev will need to maintain your code, and you should take this recommendation into consideration like something important.

[toc] | [prev] | [next] | [standalone]

#101843

W dniu niedziela, 15 stycznia 2017 12:53:00 UTC+1 użytkownik Fernando D. Bozzo napisał:
> El domingo, 15 de enero de 2017, 12:30:22 (UTC+1), fir  escribió:
> > W dniu niedziela, 15 stycznia 2017 07:24:32 UTC+1 użytkownik Tim Rentsch napisał:
> > > fir writes:
> > > 
> > > > W dniu ?roda, 11 stycznia 2017 16:50:50 UTC+1 u?ytkownik Bart napisa?:
> > > >> On 11/01/2017 15:33, fir wrote:
> > > >>> W dniu ?roda, 11 stycznia 2017 04:21:19 UTC+1 u?ytkownik Ben Bacarisse napisa?:
> > > >>>
> > > >>>>   const char *ScanForPathOrURLName(const char *text_in)
> > > >>>
> > > >>> i disagree, my version (where i just dont care for const and size_t
> > > >>> etc) feel better to me
> > > >>
> > > >> I agree.  I never bother with const, nor with size_t if I know or
> > > >> expect the size to be within the range of an int.
> > > >
> > > > me too
> > > >
> > > >>> the only doubtfull thing i see is name of the function,
> > > >>>
> > > >>> (here i could probably rate it 5/10) but function naming is hard
> > > >>> thing and maybe i not developed full rules here yet..
> > > >>
> > > >> My version of this function is called extractfile(), returning a
> > > >> pointer into the filespec.
> > > >>
> > > >> Related functions are extractpath(), extractext() and extractbasefile,
> > > >> which are a little more complex in how they return their value, or
> > > >> (with getting the extension), in whether to return a null extension as
> > > >> "" or ".").
> > > >
> > > > as i said there are two schools short names amd long names [...]
> > > 
> > > I would say there is at least one other view, namely, for some
> > > names it's important for them not to be overly terse (ie, they
> > > should be "long"), whereas for certain other names it's okay
> > > or sometimes better than just okay that they be short.
> > > 
> > > Choosing good names is hard, and there is no simple formula.
> > > Almost everyone has rules of thumb that they follow, or
> > > conventions about how names are chosen, or both.  Having such
> > > rules and conventions definitely provides value, but at the same
> > > time it's a mistake for naming choices to be too rigid, or to
> > > assume that the "laxness" or "rigidity" of various rules should
> > > be the same in all cases.  A good set of naming conventions will
> > > allow more freedom along some axes and less freedom along other
> > > axes.  Good developers will make an effort to cultivate and
> > > exercise effective judgment in those areas where there is more
> > > freedom to make choices.  They also will make an effort to
> > > broaden their range both for reading code and for writing it.  In
> > > almost all cases any particular set of name choices will have
> > > both pluses and minuses;  the judgment comes not in deciding what
> > > is "best" but deciding when the current set of design choices is
> > > good enough, so that the work can go forward and proceed on to
> > > other design choices.
> > 
> > its tru but talking that "naming rules are used" or "various naming rules are used" is less worth/valuable than speaking about specific rules
> > (wort stating maybe that present naming rules are very badly constrained by set of chars that could be used 
> > in identifiers in c - i would strongly like more 
> > characters in identifiers 
> > 
> > my own invention/decision to use 0x60 ascii char (so called grave accent) for making identifiers containing more ascii chars (like spaces and other)
> > 
> > int `ssd jj` = 10;
> > 
> > seem to be quite good (quite good lookin, ascii, even quite handy to type) 
> > 
> > other way is to incorporate more chars in identifiers 
> > (this is troublesome as i dont love unicode to much, but probably should be done or at least considered) or make 
> > also some changes to c 'syntaxer' 
> > (im not even sure if some 'skinning layer' over c couldnt be used allowing c to be common 'engine' under some skinning layers which would allow c code lookin in various 
> > ways (even not neccessary classic left to right with simple typescript, but maybe more variously geometrical (in various code geometries))
> > 
> > present poor identifier charset-related posibilities makes
> > c coding a bit sad - though are also and still important and i feel some probably could do important things in this space (im not much good in this layer, i use simple rules i 
> > mentioned and the visual outcome of this is not much appealing)
> 
> 
> I think that if you want to standarize (which is something good) it's better traying to use something useful in many languages and not something that can be used only in one. In this case your suggestion of using `this type` of naming is not good at all. You can use thisType or this_type of naming that works in almost all languages and is understood by majority of developers in the world.
> 
> Even if you like your naming convention, if you are aware of team development (Open Source, private, whatever) and maintainability, then you shouldn't use it. Even if you are the only dev on your place, some day another dev will need to maintain your code, and you should take this recommendation into consideration like something important.

i recently talked that people often forget how much redefinition could bring value (speakin like yoda who
itself was redefining language?)
i also mentioned though how much virtual young undefinition 
state is freshy (i already managed to forgot that but 
at least i mentiioned it so i remember i forget it ;c 
- i vaguelly remember i forget many things (compared to my younger years), yet more i probably even dont remember i forget) 

[toc] | [prev] | [next] | [standalone]

#101481

Hi Ben:

Thanks for the examples. I've changed my implementation to check for the special chars from right to left (now including the ":" symbol), so I think I get it correct now.


El miércoles, 11 de enero de 2017, 4:21:19 (UTC+1), Ben Bacarisse  escribió:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu środa, 11 stycznia 2017 00:43:53 UTC+1 użytkownik Fernando
> > D. Bozzo napisał:
> >> Hi all,
> >> 
> >> I'm starting at C but have a background on programmming in OOP.
> >> 
> >> My question is about string manipulation functions and the correct/best/good way of doing this in C.
> >> 
> >> I've made a function that returns just the filename of a given full path or url, which I use this way:
> >> 
> >> 
> >> // Suppose argv[1] is "http://www.myserver.com/file.html"
> >> char *text_out = justfname(argv[1]);
> >> printf("justfname = [%s]\n", text_out);
> >> free(text_out);
> >> 
> >> 
> >> 
> >> /**
> >>  * Returns the filename without path
> >>  * 
> >>  * Examples:
> >>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
> >>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
> >>  */
> >> char *justfname(char *text_in)
> >> {
> >>     int len = strlen(text_in);
> >>     char *fname = NULL;
> >>     char *text_out = malloc(sizeof(text_in));
> >>     fname = strrchr(text_in, '/');
> >>     if (fname == NULL)
> >>     {
> >>         fname = strrchr(text_in, '\\');
> >>         if (fname == NULL)
> >>         {
> >>             fname = text_in;
> >>         }
> >>         else
> >>         {
> >>             fname++; // Advance address +1 (skip "\" char)
> >>         }
> >>     }
> >>     else
> >>     {
> >>         fname++; // Advance address +1 (skip "/" char)
> >>     }
> >> 
> >>     // Copy obtained data
> >>     strncpy(text_out, fname, len);
> >> 
> >>     return text_out;
> >> }
> >> 
> >> 
> >> 
> >> So my questions are:
> >> 1) Is this implementation ok/correct, or is there a better way of doing it?
> >> 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
> >> 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?
> >> 
> >> Thanks!
> >
> > your implementation is wrong in many aspects
> > (firstly i dont think it works at all, returning 
> > mallocked ram is also very bad, also your names 
> > are not ok, esp "fname" ... and more)
> >
> > in such simple case (where you sure name will be always at the end
> > after last \ or / , and you will be using this name only to read not
> > to modify (all sane apis will be ok with that last assumption)) you
> > can just return pointer to first char of the name, so you will only
> > need to find it
> 
> You also have to be sure that the lifetime of the returned pointer is
> not used after the end of the array's life.
> 
> >  char *ScanForPathOrURLName(char *text_in)
> 
> You can help document some of the assumption by using const:
> 
>   const char *ScanForPathOrURLName(const char *text_in)
> 
> >  {
> >   int k = strlen(text_in) - 1; //set on last char
> 
> This does not handle an empty input ("").  And it's not the most
> portable because size_t values can be larger than an int can represent.
> You may be ruling out those possibilities, but it's good to document
> such assumption in a comment.
> 
> >   for(; k>=0; k--) //go down till first
> >   {
> >     if(  text_in[k] == '\\' )  break;
> >     if(  text_in[k] == '/' )   break;
> >   }
> >   return text_in + k + 1 ;
> > }
> 
> I think the answer for "c:file" should be "path" rather than "c:file".
> 
> Another way:
> 
>   const char *file_ptr = text_in;
>   for (const char *cp = text_in; *cp; cp++)
>        if (*cp == '/' || *cp == '\\' || *cp == ':')
>            file_ptr = cp;
>   return file_ptr + (file_ptr != text_in);
> 
> though maybe less tricksy would be
> 
>   const char *file_ptr = 0;
>   for (const char *cp = text_in; *cp; cp++)
>        if (*cp == '/' || *cp == '\\' || *cp == ':')
>            file_ptr = cp;
>   return file_ptr ? text_in : file_ptr + 1;
> 
> <snip>
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web