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

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

Program to read csv file, store characters and numbers in separate arrays

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

Contents

  Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-15 05:05 -0800
    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 13:48 +0000
      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-15 08:22 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 16:28 +0000
          Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-15 09:25 -0800
            Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 19:31 +0000
              Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:19 -0800
                Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 10:01 +0000
                  Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 02:43 -0800
                    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 11:03 +0000
                      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 03:08 -0800
                        Re: Program to read csv file, store characters and numbers in separate arrays jameskuyper@verizon.net - 2016-12-18 03:32 -0800
                    Re: Program to read csv file, store characters and numbers in separate arrays Barry Schwarz <schwarzb@dqel.com> - 2016-12-16 17:09 -0800
              Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:25 -0800
                Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 10:11 +0000
                  Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 02:45 -0800
                    Re: Program to read csv file, store characters and numbers in separate arrays Keith Thompson <kst-u@mib.org> - 2016-12-16 09:54 -0800
                      Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 17:56 +0000
                      Re: Program to read csv file, store characters and numbers in separate arrays gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-16 18:02 +0000
                  Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 03:06 -0800
                    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 11:28 +0000
                      Re: Program to read csv file, store characters and numbers in separate arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 12:02 +0000
                        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 12:41 +0000
                          Re: Program to read csv file, store characters and numbers in separate arrays BartC <bc@freeuk.com> - 2016-12-16 13:40 +0000
                            Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 14:03 +0000
                        Re: Program to read csv file, store characters and numbers in separate arrays BartC <bc@freeuk.com> - 2016-12-16 13:03 +0000
                          Re: Program to read csv file, store characters and numbers in separate arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 15:04 +0000
                            Re: Program to read csv file, store characters and numbers in separate arrays BartC <bc@freeuk.com> - 2016-12-16 15:26 +0000
                              Re: Program to read csv file, store characters and numbers in separate arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 17:01 +0000
                      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 04:18 -0800
    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 14:12 +0000
      Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-15 16:14 +0100
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 15:37 +0000
          Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-15 23:20 +0100
            Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 23:27 +0000
              Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-16 12:10 +0100
                Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 11:43 +0000
                  Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-16 14:01 +0100
                    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 13:12 +0000
                      Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-16 14:57 +0100
        Re: Program to read csv file, store characters and numbers in separate arrays BartC <bc@freeuk.com> - 2016-12-15 16:30 +0000
          Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 16:36 +0000
            Re: Program to read csv file, store characters and numbers in separate arrays David Brown <david.brown@hesbynett.no> - 2016-12-15 23:29 +0100
      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-15 08:26 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 16:33 +0000
      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-15 08:32 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 16:37 +0000
        Re: Program to read csv file, store characters and numbers in separate arrays Keith Thompson <kst-u@mib.org> - 2016-12-15 12:17 -0800
          Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:33 -0800
      Re: Program to read csv file, store characters and numbers in separate arrays Keith Thompson <kst-u@mib.org> - 2016-12-15 12:23 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 20:39 +0000
      Re: Program to read csv file, store characters and numbers in separate arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 21:13 +0000
      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 00:39 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:54 +0000
          Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:09 -0800
            Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 09:32 +0000
              Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:51 -0800
                Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 10:08 +0000
                  Re: Program to read csv file, store characters and numbers in separate arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 11:09 +0000
                    Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 03:16 -0800
                      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 03:20 -0800
                        Re: Program to read csv file, store characters and numbers in separate arrays Keith Thompson <kst-u@mib.org> - 2016-12-16 09:48 -0800
                          Re: Program to read csv file, store characters and numbers in separate arrays gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-16 17:55 +0000
                          Re: Program to read csv file, store characters and numbers in separate arrays raltbos@xs4all.nl (Richard Bos) - 2016-12-20 11:53 +0000
                    Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 11:33 +0000
              Re: Program to read csv file, store characters and numbers in separate arrays Keith Thompson <kst-u@mib.org> - 2016-12-16 09:46 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-03 15:38 -0500
    Re: Program to read csv file, store characters and numbers in separate arrays Barry Schwarz <schwarzb@dqel.com> - 2016-12-15 12:36 -0800
      Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 01:44 -0800
        Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 10:04 +0000
          Re: Program to read csv file, store characters and numbers in separate arrays Alla _ <modelling.data@gmail.com> - 2016-12-16 03:14 -0800
            Re: Program to read csv file, store characters and numbers in separate arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 11:46 +0000

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

#99517

On 15/12/2016 15:14, David Brown wrote:

> Regarding macros, I would always limit the use of macros to when you
> actually need them to be macros.  If usage of CISPRNG_RAND_MAX permits,
> I would prefer:
>
> static const unsigned long int cisprng_rand_max = 0x7ffffffful;

You said elsewhere that assembly syntax is not literature, but this is 
verging on War and Peace.

It took a couple of readings to establish it was only declaring one thing.

-- 
bartc

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

#99520

On 15/12/16 16:30, BartC wrote:
> On 15/12/2016 15:14, David Brown wrote:
>
>> Regarding macros, I would always limit the use of macros to when you
>> actually need them to be macros.  If usage of CISPRNG_RAND_MAX permits,
>> I would prefer:
>>
>> static const unsigned long int cisprng_rand_max = 0x7ffffffful;
>
> You said elsewhere that assembly syntax is not literature, but this is
> verging on War and Peace.

"War and Peace" is 587,287 words, so even if we take every token as a 
"word", this is only 0.0000153247496 of a war. Barely even a playground 
skirmish.

> It took a couple of readings to establish it was only declaring one thing.

You need to do a lot more C programming. One learns, after a while, to 
take these things in at a single glance.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99579

On 15/12/16 17:36, Richard Heathfield wrote:
> On 15/12/16 16:30, BartC wrote:
>> On 15/12/2016 15:14, David Brown wrote:
>>
>>> Regarding macros, I would always limit the use of macros to when you
>>> actually need them to be macros.  If usage of CISPRNG_RAND_MAX permits,
>>> I would prefer:
>>>
>>> static const unsigned long int cisprng_rand_max = 0x7ffffffful;
>>
>> You said elsewhere that assembly syntax is not literature, but this is
>> verging on War and Peace.
>
> "War and Peace" is 587,287 words, so even if we take every token as a
> "word", this is only 0.0000153247496 of a war. Barely even a playground
> skirmish.
>
>> It took a couple of readings to establish it was only declaring one
>> thing.
>
> You need to do a lot more C programming. One learns, after a while, to
> take these things in at a single glance.
>

In my programming, it would like be:

static const uint32_t cisprng_rand_max = 0x7fffffff;

But my code generally doesn't need to be as portable as Richard likes 
his code to be.  While my code might be used with 16-bit or 32-bit ints, 
on cpus from 8-bit up to 64-bit, there are none that I have come across 
that don't have uint32_t.

(But then, I can use C99 and not just C90 :-) )

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

#99515

On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
> [the code]
> 
> On 15/12/16 13:05, Alla _ wrote:
> 
> > (3) I will use a header file, in which I will store preprocessor commands, like
> > #define and #include, as well as functions' declarations, etc.;
> 
> A well-designed header contains *only* the following:
> 
> 1) inclusion guards;
> 2) macro definitions (#defines);
> 3) type definitions (typedefs);
> 4) function prototypes;
Thank you very much for this list. This is what I have planned 
to include.
> 5) comments;
> 6) #include directives *ONLY* for those headers that are required for 
> the immediate purposes of the header itself.
Thank you - I have seen somewhere that sometimes all headers
can be included in the single header file (not only directly needed
for processing things within this header file), which sounded strange;
thank you for confirming that it is an incorrect approach, so I will
not repeat that bad practice. 
> 
> For example, here's a quick header I threw together a year or so ago:
> 
> /* CISPRNG - Cryptographically In-Secure
>   * Pseudo-Random Number Generator
>   *
>   * Written by Richard Heathfield,
>   * 20 October 2015.
>   *
>   * You will also need cisprng.c and a
>   * C compiler.
>   *
>   * The author places this code into the
>   * public domain, and so it may be freely
>   * used for any legal purpose, although
>   * I would recommend against using it
>   * in circumstances where you really need
>   * a cryptographically secure PRNG, because
>   * it isn't one.
>   */
> #ifndef H_CISPRNG_H_
> #define H_CISPRNG_H_
> 
> #define CISPRNG_RAND_MAX (0x7FFFFFFFUL)
> 
> /* Single state versions */
> /* set the seed */
> void cisprng_set(unsigned long seed);
> /* get a PRN */
> unsigned long cisprng_random(void);
> /* get a PRN in a range */
> unsigned long cisprng_range(unsigned long low,
>                              unsigned long high);
> /* Custom state versions */
> unsigned long cisprng_csrandom(unsigned long *pseed);
> unsigned long cisprng_csrange(unsigned long *pseed,
>                                unsigned long low,
>                                unsigned long high);
> #endif
> /* end of cisprng.h */
> 
> Note that it doesn't define any types. But if it did, they would go 
> after the #defines but before the function prototypes. Nor does it 
> include any headers. But *if* I'd used, say, size_t *in the header*, I'd 
> have included <stddef.h> in the header. But I would *not* include 
> <stddef.h> in the header just because the corresponding C file used 
> size_t (which, actually, it doesn't). A module header is not a place to 
> hide #includes.
<snip>

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

#99519

On 15/12/16 16:26, Alla _ wrote:
 > Richard Heathfield wrote:
<snip>
>> 6) #include directives *ONLY* for those headers that are required for
>> the immediate purposes of the header itself.
> Thank you - I have seen somewhere that sometimes all headers
> can be included in the single header file (not only directly needed
> for processing things within this header file), which sounded strange;
> thank you for confirming that it is an incorrect approach, so I will
> not repeat that bad practice.

It's bad practice, yes. I wouldn't go so far as to say that it is 
"incorrect" - it doesn't break the rules of the language. It's just not 
a very good idea. It's a bit like putting porridge and custard on toast.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99518

On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
> [the code]
> 
> On 15/12/16 13:05, Alla _ wrote:
> 
<snip>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <ctype.h>
> > #include <string.h>
> >
> >
> > #define BUFFER_SIZE 100
> > //#define ARRAY_SIZE(a) (sizeof(a)/sizeof(*(a)))
> > #define INCOME_STATEMENT "files/income_test.csv"
> >
> > int main(int argc, char *argv[])
> > {
> >     //check for correct number of arguments
> >     if(argc > 2)
> >     {
> >         printf("Usage: program_name [file_name]");
> 
> You might want a \n on there. Or use puts() instead if you prefer.
> 
> Otherwise, this happens:
> 
> Usage: program_name [file_name]me@mymachine$
> 
> which probably isn't what you wanted to see.
> 
> >         return EXIT_FAILURE;
> >     }
> >     //determine a file to use
> >     char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
> 
> I don't suppose you plan to change the filename, so why not make this const?
> 
> const char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
> 
> This will remove the *only* diagnostic message that gcc gave me (and by 
> the way, to get only one warning when using my flag choices is quite an 
> achievement!).
Oh ) I tried, and very glad to read this. Thank you!
I always use only the following flag, which you have taught me to use:
gcc -Wall -Werror -Wextra -pedantic -std=c99 program.c -o program
Shall I use some more?
> 
<snip>

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

#99521

On 15/12/16 16:32, Alla _ wrote:
> On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
>> [the code]
>>
>> On 15/12/16 13:05, Alla _ wrote:
>>
> <snip>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <ctype.h>
>>> #include <string.h>
>>>
>>>
>>> #define BUFFER_SIZE 100
>>> //#define ARRAY_SIZE(a) (sizeof(a)/sizeof(*(a)))
>>> #define INCOME_STATEMENT "files/income_test.csv"
>>>
>>> int main(int argc, char *argv[])
>>> {
>>>     //check for correct number of arguments
>>>     if(argc > 2)
>>>     {
>>>         printf("Usage: program_name [file_name]");
>>
>> You might want a \n on there. Or use puts() instead if you prefer.
>>
>> Otherwise, this happens:
>>
>> Usage: program_name [file_name]me@mymachine$
>>
>> which probably isn't what you wanted to see.
>>
>>>         return EXIT_FAILURE;
>>>     }
>>>     //determine a file to use
>>>     char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
>>
>> I don't suppose you plan to change the filename, so why not make this const?
>>
>> const char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
>>
>> This will remove the *only* diagnostic message that gcc gave me (and by
>> the way, to get only one warning when using my flag choices is quite an
>> achievement!).
> Oh ) I tried, and very glad to read this. Thank you!
> I always use only the following flag, which you have taught me to use:
> gcc -Wall -Werror -Wextra -pedantic -std=c99 program.c -o program
> Shall I use some more?

That's plenty for now.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99560

Alla _ <modelling.data@gmail.com> writes:
[...]
> I always use only the following flag, which you have taught me to use:
> gcc -Wall -Werror -Wextra -pedantic -std=c99 program.c -o program
> Shall I use some more?

That's fine.

Warning: The following could be a distraction, and you can consider
ignoring it.

You could consider using -std=c11 rather than -std=c99 if you
have a sufficiently new version of gcc, but unless you're using
C11-specific features (which you probably aren't) it doesn't matter.
(With recent versions, say gcc 6.0 and up, C11 support is roughly
as good as C99 support.  Also, the default is "-std=gnu11" rather
than the "-std=gnu90" of older releases.  But the default doesn't
matter if you're specifying "-std=..." anyway.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#99611

On Thursday, December 15, 2016 at 11:16:40 PM UTC+3, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
> [...]
> > I always use only the following flag, which you have taught me to use:
> > gcc -Wall -Werror -Wextra -pedantic -std=c99 program.c -o program
> > Shall I use some more?
> 
> That's fine.
> 
> Warning: The following could be a distraction, and you can consider
> ignoring it.
> 
> You could consider using -std=c11 rather than -std=c99 if you
> have a sufficiently new version of gcc, but unless you're using
> C11-specific features (which you probably aren't) it doesn't matter.
> (With recent versions, say gcc 6.0 and up, C11 support is roughly
> as good as C99 support.  Also, the default is "-std=gnu11" rather
> than the "-std=gnu90" of older releases.  But the default doesn't
> matter if you're specifying "-std=..." anyway.)
> 
As I am now (for a few months already) a lucky (or not? :) ) user
of El Capitan (10.11.6), I guess I have quite new gcc. But I have 
also fount out, serendipitously, that Apple now uses clang 
instead of gcc, and hence, when I tried to learn gdb yet again,
I have stumbled upon the fact that now I have to learn a different
debugger provided by Apple, and it is so difficult, that I had to 
quit that attempt yet again. Sad that I can't use gdb. 
This was a long way of saying that yes, most likely, I have a new
version of clang. 

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

#99562

Richard Heathfield <rjh@cpax.org.uk> writes:
> [the code]
>
> On 15/12/16 13:05, Alla _ wrote:
>
>> (3) I will use a header file, in which I will store preprocessor
>> commands, like #define and #include, as well as functions'
>> declarations, etc.;
>
> A well-designed header contains *only* the following:
>
> 1) inclusion guards;
> 2) macro definitions (#defines);
> 3) type definitions (typedefs);
> 4) function prototypes;
> 5) comments;
> 6) #include directives *ONLY* for those headers that are required for 
> the immediate purposes of the header itself.

I'd also include struct, union, and enum type declarations if
appropriate.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#99568

On 15/12/16 20:23, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [the code]
>>
>> On 15/12/16 13:05, Alla _ wrote:
>>
>>> (3) I will use a header file, in which I will store preprocessor
>>> commands, like #define and #include, as well as functions'
>>> declarations, etc.;
>>
>> A well-designed header contains *only* the following:
>>
>> 1) inclusion guards;
>> 2) macro definitions (#defines);
>> 3) type definitions (typedefs);
>> 4) function prototypes;
>> 5) comments;
>> 6) #include directives *ONLY* for those headers that are required for
>> the immediate purposes of the header itself.
>
> I'd also include struct, union, and enum type declarations if
> appropriate.

Hmmm. I wouldn't, because I'd typedef them (#3). But yes, I will concede 
that that is also an appropriate category for a header.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99572

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 15/12/16 13:05, Alla _ wrote:
<snip>
>>         char buffer[BUFFER_SIZE] = "";
>>         char array_names[50][50];
>>         int  array_values[50][50];
<snip>
>>         //Read each line from the file, store in the buffer
>>         for ( i = 0; fgets(buffer, sizeof(buffer), fp) != NULL; ++i )
>
> Since i isn't part of the loop control logic,

Ah, but it should be.

> I would suggest that you
> replace this line with the much more usual:
>
>   i = 0;
>   while(fgets(buffer, sizeof buffer, fp) != NULL)
>   {
>     /* stuff */
>     i++;
>   }

Maybe Alla_ is planning to grow the array, but I can't help commenting
on the code in front of me, and with a fixed-size array, I'd want to
include a test on i.  That could be written:

  for (i = 0; i < 50 && fgets(buffer, sizeof(buffer), fp); i++)

but that is verging on for abuse.  So maybe

  i = 0;
  while (i < 50 && fgets(buffer, sizeof(buffer)) {
      i++;
  }

or

  i = 0;
  while (fgets(buffer, sizeof(buffer))
      if (i < 50) {
          ...
          i++;
      }

depending on the exact intent.

<snip>
-- 
Ben.

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

#99604

On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
> [the code]
> 
> On 15/12/16 13:05, Alla _ wrote:
> 
<snip>
> > int main(int argc, char *argv[])
> > {
> >     //check for correct number of arguments
> >     if(argc > 2)
> >     {
> >         printf("Usage: program_name [file_name]");
> 
> You might want a \n on there. Or use puts() instead if you prefer.
> 
> Otherwise, this happens:
> 
> Usage: program_name [file_name]me@mymachine$
> 
Yes, I missed this one; I have forgotten to add the newline.
> which probably isn't what you wanted to see.
> 
> >         return EXIT_FAILURE;
> >     }
> >     //determine a file to use
> >     char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
> 
> I don't suppose you plan to change the filename, so why not make this const?
> 
> const char *data_file = (argc == 2)? argv[1] : INCOME_STATEMENT;
> 
> This will remove the *only* diagnostic message that gcc gave me (and by 
> the way, to get only one warning when using my flag choices is quite an 
> achievement!).
> 
> What should the program do if there are several arguments? At the 
> moment, if I tell it:
> 
> ./alla test1.csv test2.csv
> 
> I get this message:
> 
> Usage: program_name [file_name]
> 
> If the program can only handle one data file, I would expect to see 
> something like:
> 
> Sorry, I can only process one file. Ignoring subsequent arguments...
> 
> which you would code like this:
> 
> const char *data_file = (argc > 1)? argv[1] : INCOME_STATEMENT;
> if(argc > 2)
> {
>    fputs("Sorry, I can only process one file."
>          " Ignoring subsequent arguments...\n",
>          stderr);
> }
> 
Done, with a very slight change in words choice
> >
> >     FILE *fp = fopen(data_file, "r");
> >
> >     if ( fp )
> >     {
> >         char buffer[BUFFER_SIZE] = "";
> >         char array_names[50][50];
> >         int  array_values[50][50];
> 
> I am taking you at your word and forbearing to comment on these values, 
> but for the sake of a predictable life I would suggest that you 
> initialise these two arrays:
> 
> char array_names[50][50] = {0};
> int  array_values[50][50] = {0};
> 
> which will take advantage of the default static initialisation rule to 
> set everything to 0.
> 
Is it a typo, or did you intend to use only {}, instead of {{}}? 
And, yes, I have missed this initialization for some reason, although I did 
not forget to use it for the buffer array. I remember you have taught me 
to always use this type of initialization. You see, although you and everyone
here keep griping about me not heeding to your advices no matter how I have 
tried to convince you in the opposite, I do remember the majority of them,
because I have them whether written out by hand, or copied in a file, or 
remember them in my head (hope all them will eventually end up in my 
const memory buffer :) )  :D
> >         char *ptr_buffer = NULL;
> >         size_t i, j, k;
> >
> >         //Read each line from the file, store in the buffer
> >         for ( i = 0; fgets(buffer, sizeof(buffer), fp) != NULL; ++i )
> 
> Since i isn't part of the loop control logic, I would suggest that you 
> replace this line with the much more usual:
> 
>    i = 0;
>    while(fgets(buffer, sizeof buffer, fp) != NULL)
>    {
>      /* stuff */
>      i++;
>    }
> 
Indeed. Done.
> And if i is a line number, why not call it line_number? That's much more 
> descriptive than i.
> 
Done. I have also changed j and k names into names_column_number
and values_column_number - these are lengthy names and look a bit
heavy when used as indexes, but they are descriptive, so I will live 
them this way for now. 

> The loop body looked more or less okay to me, except that it's a touch 
> on the large side. Think about functional decomposition.
As I have mentioned in my description, this is exactly what I intend to do; 
it won't be easy for me, but what has been? ) and has to be done anyway
> 
> >         if (!feof(fp))
> >         {
> >             puts("Something went wrong with the provided file\n");
> >             return EXIT_FAILURE;
> >         }
> 
> Why not use ferror(fp) instead? It's a more direct description of what 
> you're trying to find out:
> 
>    if(ferror(fp))
>    {
> 
Because I have not known of it, and have not yet used it elsewhere. 
Changed. Done )
> And while we're on the subject, diagnostic messages sit much better on 
> stderr than on stdout. That way, they can be separated from the 
> program's normal output, like this:
> 
> ./alla test1.csv > test1.out 2> test1.log
> 
> which will put stdout stuff into test1.out and stderr stuff into test1.log.
>

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

#99605

On 16/12/16 08:39, Alla _ wrote:
> On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
>> [the code]
>>
<snip>
>>>     {
>>>         char buffer[BUFFER_SIZE] = "";
>>>         char array_names[50][50];
>>>         int  array_values[50][50];
>>
>> I am taking you at your word and forbearing to comment on these values,
>> but for the sake of a predictable life I would suggest that you
>> initialise these two arrays:
>>
>> char array_names[50][50] = {0};
>> int  array_values[50][50] = {0};
>>
>> which will take advantage of the default static initialisation rule to
>> set everything to 0.
>>
> Is it a typo, or did you intend to use only {}, instead of {{}}?

It isn't a typo. {0} always works, for any kind of aggregate type. But 
if you would prefer to use {{0}}, you {{{{{{{can}}}}}}}.

>> And if i is a line number, why not call it line_number? That's much more
>> descriptive than i.
>>
> Done. I have also changed j and k names into names_column_number
> and values_column_number - these are lengthy names and look a bit
> heavy when used as indexes, but they are descriptive, so I will live
> them this way for now.

It doesn't matter whether they "look heavy". What matters is whether the 
code is easy to read. It's easier to read if people know what the 
indices represent. Thanks to modern editors and their 'word completion' 
feature, the only real excuse (and it always /was/ just an excuse) for 
using short names --- that they take longer to type --- has gone.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99606

On Friday, December 16, 2016 at 11:54:40 AM UTC+3, Richard Heathfield wrote:
> On 16/12/16 08:39, Alla _ wrote:
> > On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
> >> [the code]
> >>
> <snip>
> >>>     {
> >>>         char buffer[BUFFER_SIZE] = "";
> >>>         char array_names[50][50];
> >>>         int  array_values[50][50];
> >>
> >> I am taking you at your word and forbearing to comment on these values,
> >> but for the sake of a predictable life I would suggest that you
> >> initialise these two arrays:
> >>
> >> char array_names[50][50] = {0};
> >> int  array_values[50][50] = {0};
> >>
> >> which will take advantage of the default static initialisation rule to
> >> set everything to 0.
> >>
> > Is it a typo, or did you intend to use only {}, instead of {{}}?
> 
> It isn't a typo. {0} always works, for any kind of aggregate type. But 
> if you would prefer to use {{0}}, you {{{{{{{can}}}}}}}.
My compiler complained about {0} )
<snip>

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

#99610

On 16/12/16 09:09, Alla _ wrote:
> On Friday, December 16, 2016 at 11:54:40 AM UTC+3, Richard Heathfield wrote:
>> On 16/12/16 08:39, Alla _ wrote:
>>> On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
>>>> [the code]
>>>>
>> <snip>
>>>>>     {
>>>>>         char buffer[BUFFER_SIZE] = "";
>>>>>         char array_names[50][50];
>>>>>         int  array_values[50][50];
>>>>
>>>> I am taking you at your word and forbearing to comment on these values,
>>>> but for the sake of a predictable life I would suggest that you
>>>> initialise these two arrays:
>>>>
>>>> char array_names[50][50] = {0};
>>>> int  array_values[50][50] = {0};
>>>>
>>>> which will take advantage of the default static initialisation rule to
>>>> set everything to 0.
>>>>
>>> Is it a typo, or did you intend to use only {}, instead of {{}}?
>>
>> It isn't a typo. {0} always works, for any kind of aggregate type. But
>> if you would prefer to use {{0}}, you {{{{{{{can}}}}}}}.
> My compiler complained about {0} )

Yes, so does mine. But it's wrong to do so. {0} is a C idiom, and 
perfectly correct.

It's probably a bit early in your C career to be telling you this, 
because the knowledge can lead to a certain devil-may-care attitude to 
warnings (and such an attitude is entirely wrong!), but here goes.

An implementation's diagnostic messages have a purpose, which is to draw 
your attention to possible mistakes in your program. And nowadays, they 
are very nearly always right.

But "very nearly always" isn't quite the same thing as "always". 
Sometimes they will point out something that they think is a problem, 
but that you *know for sure* is not a problem. In such circumstances, 
you have a choice: to modify the code anyway so as to shut up the 
warning, or to leave things alone and put up with the constant nagging 
(perhaps adding a comment to the code).

In this case, when faced with a diagnostic message for code that you 
didn't think should produce one, you did *exactly* the right thing --- 
you asked.

The *wrong* things to do would have been:

* ignore the message completely, without asking;
* change the code to get rid of the warning, without finding out what 
the warning meant.

It's all about understanding.

If you know exactly why a diagnostic message has been produced and what 
that message means, then you are in a good position to make an 
independent judgement based on your experience. But if you don't 
understand the message, you can't just ignore it. You need to find out 
what it means.

Some development teams have a house rule, and generally it's a good one, 
that the code should compile completely cleanly, without any diagnostic 
messages of any kind. In such circumstances, you should modify the code, 
but add a comment explaining what was there before and why you changed 
it. But, unless and until you join such a team, you are free to make 
your own decisions.

My own view is based on the fact that I use several different compilers, 
and code that clears up a warning in one of them will sometimes 
/generate/ a warning in another, and one can waste a lot of time trying 
to find an exact expression that will satisfy every compiler. If I 
*know* the code is right (and I always take my own knowledge with a 
pinch of salt, because sometimes what I know isn't actually correct), 
then I will generally choose to put up with the warning.

This is about knowing the rules. This is about understanding what a 
diagnostic message is telling you. And if you can't work it out, then ask.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99614

On Friday, December 16, 2016 at 12:32:54 PM UTC+3, Richard Heathfield wrote:
> On 16/12/16 09:09, Alla _ wrote:
> > On Friday, December 16, 2016 at 11:54:40 AM UTC+3, Richard Heathfield wrote:
> >> On 16/12/16 08:39, Alla _ wrote:
> >>> On Thursday, December 15, 2016 at 5:12:52 PM UTC+3, Richard Heathfield wrote:
> >>>> [the code]
> >>>>
> >> <snip>
> >>>>>     {
> >>>>>         char buffer[BUFFER_SIZE] = "";
> >>>>>         char array_names[50][50];
> >>>>>         int  array_values[50][50];
> >>>>
> >>>> I am taking you at your word and forbearing to comment on these values,
> >>>> but for the sake of a predictable life I would suggest that you
> >>>> initialise these two arrays:
> >>>>
> >>>> char array_names[50][50] = {0};
> >>>> int  array_values[50][50] = {0};
> >>>>
> >>>> which will take advantage of the default static initialisation rule to
> >>>> set everything to 0.
> >>>>
> >>> Is it a typo, or did you intend to use only {}, instead of {{}}?
> >>
> >> It isn't a typo. {0} always works, for any kind of aggregate type. But
> >> if you would prefer to use {{0}}, you {{{{{{{can}}}}}}}.
> > My compiler complained about {0} )
> 
> Yes, so does mine. But it's wrong to do so. {0} is a C idiom, and 
> perfectly correct.
> 
> It's probably a bit early in your C career to be telling you this, 
> because the knowledge can lead to a certain devil-may-care attitude to 
> warnings (and such an attitude is entirely wrong!), but here goes.
> 
> An implementation's diagnostic messages have a purpose, which is to draw 
> your attention to possible mistakes in your program. And nowadays, they 
> are very nearly always right.
> 
> But "very nearly always" isn't quite the same thing as "always". 
> Sometimes they will point out something that they think is a problem, 
> but that you *know for sure* is not a problem. In such circumstances, 
> you have a choice: to modify the code anyway so as to shut up the 
> warning, or to leave things alone and put up with the constant nagging 
> (perhaps adding a comment to the code).
> 
> In this case, when faced with a diagnostic message for code that you 
> didn't think should produce one, you did *exactly* the right thing --- 
> you asked.
> 
> The *wrong* things to do would have been:
> 
> * ignore the message completely, without asking;
> * change the code to get rid of the warning, without finding out what 
> the warning meant.
> 
> It's all about understanding.
> 
> If you know exactly why a diagnostic message has been produced and what 
> that message means, then you are in a good position to make an 
> independent judgement based on your experience. But if you don't 
> understand the message, you can't just ignore it. You need to find out 
> what it means.
> 
> Some development teams have a house rule, and generally it's a good one, 
> that the code should compile completely cleanly, without any diagnostic 
> messages of any kind. In such circumstances, you should modify the code, 
> but add a comment explaining what was there before and why you changed 
> it. But, unless and until you join such a team, you are free to make 
> your own decisions.
> 
> My own view is based on the fact that I use several different compilers, 
> and code that clears up a warning in one of them will sometimes 
> /generate/ a warning in another, and one can waste a lot of time trying 
> to find an exact expression that will satisfy every compiler. If I 
> *know* the code is right (and I always take my own knowledge with a 
> pinch of salt, because sometimes what I know isn't actually correct), 
> then I will generally choose to put up with the warning.
> 
> This is about knowing the rules. This is about understanding what a 
> diagnostic message is telling you. And if you can't work it out, then ask.
> 
Thank you very much for this explanation. 
The only thing - my compiler didn't try to warn me, it screamed: "Error" )
parse_csv_2.c:29:37: error: suggest braces around initialization of subobject
      [-Werror,-Wmissing-braces]
        char array_names[50][50] = {0};

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

#99619

On 16/12/16 09:51, Alla _ wrote:
<snip>
> The only thing - my compiler didn't try to warn me, it screamed: "Error" )
> parse_csv_2.c:29:37: error: suggest braces around initialization of subobject
>       [-Werror,-Wmissing-braces]
>         char array_names[50][50] = {0};

Then you have three choices: remove -Werror from your list of compiler 
flags, or remove -Wmissing-braces from your list of compiler flags, or 
change the code.

-Werror turns every warning into an error. That's *good*, if you are 
determined that your code must compile cleanly. Not so good if the 
compiler warns about code that is perfectly good and that you don't wish 
to change.

Your call.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#99631

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 16/12/16 09:51, Alla _ wrote:
> <snip>
>> The only thing - my compiler didn't try to warn me, it screamed: "Error" )
>> parse_csv_2.c:29:37: error: suggest braces around initialization of subobject
>>       [-Werror,-Wmissing-braces]
>>         char array_names[50][50] = {0};
>
> Then you have three choices: remove -Werror from your list of compiler
> flags, or remove -Wmissing-braces from your list of compiler flags, or
> change the code.

Or, four, change your compiler.  That may mean just an upgrade.  I think
gcc have fixed this or at least that's how I remember the issue, and I
certainly haven't seen that message, for that construct, for quite a
while.

<snip>
-- 
Ben.

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

#99634

On Friday, December 16, 2016 at 2:09:30 PM UTC+3, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> 
> > On 16/12/16 09:51, Alla _ wrote:
> > <snip>
> >> The only thing - my compiler didn't try to warn me, it screamed: "Error" )
> >> parse_csv_2.c:29:37: error: suggest braces around initialization of subobject
> >>       [-Werror,-Wmissing-braces]
> >>         char array_names[50][50] = {0};
> >
> > Then you have three choices: remove -Werror from your list of compiler
> > flags, or remove -Wmissing-braces from your list of compiler flags, or
> > change the code.
> 
> Or, four, change your compiler.  That may mean just an upgrade.  I think
> gcc have fixed this or at least that's how I remember the issue, and I
> certainly haven't seen that message, for that construct, for quite a
> while.
> 
Apple has "quietly" started using clang; I have only recently found out;
it seems I received that switch after installing some recent upgrades 
Apple has sent.  

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

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

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

csiph-web