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

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

How to compile several C files

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

Contents

  How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 06:10 -0800
    Re: How to compile several C files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-07 07:02 -0800
    Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-07 16:03 +0100
    Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 15:06 +0000
      Re: How to compile several C files BartC <bc@freeuk.com> - 2017-02-07 15:14 +0000
        Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 16:02 +0000
      Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 15:42 +0000
        Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 16:19 +0000
          Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 16:40 +0000
            Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 17:16 +0000
              Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 10:19 +0100
          Re: How to compile several C files "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-07 11:51 -0500
        Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 08:26 -0800
          Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 16:42 +0000
            Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 10:14 -0800
            Re: How to compile several C files vitale.alla@gmail.com - 2017-02-16 09:49 -0800
        Re: How to compile several C files Ian Collins <ian-news@hotmail.com> - 2017-02-08 17:35 +1300
          Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 10:28 +0100
            Re: How to compile several C files Ian Collins <ian-news@hotmail.com> - 2017-02-08 22:43 +1300
              Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 11:29 +0100
        Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 10:14 +0100
    Re: How to compile several C files James Kuyper <jameskuyper@verizon.net> - 2017-02-07 10:07 -0500
      Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 07:56 -0800
        Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 08:24 -0800
          Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 16:44 +0000
            Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 08:54 -0800
              Re: How to compile several C files "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-07 12:20 -0500
                Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 10:05 -0800
                  Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 18:27 +0000
                    Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 18:40 +0000
                    Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-07 12:22 -0800
                    Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 10:33 +0100
                      Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-08 10:25 -0800
        Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-07 08:58 -0800
        Re: How to compile several C files "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-07 12:07 -0500
          Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 09:14 -0800
            Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 17:21 +0000
              Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 10:14 -0800
              Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 10:28 -0800
                Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 18:43 +0000
                  Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 10:55 -0800
              Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 19:28 +0000
                Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-07 19:51 +0000
                Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 11:25 +0100
                  Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-08 12:11 +0000
                    Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 14:58 +0100
                      Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-08 14:23 +0000
                        Re: How to compile several C files supercat@casperkitty.com - 2017-02-08 07:48 -0800
                          Re: How to compile several C files Richard Heathfield <rjh@cpax.org.uk> - 2017-02-08 16:09 +0000
                            Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 17:23 +0100
                    Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 15:01 +0000
                      Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 17:22 +0100
                        Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-08 09:27 -0800
                          Re: How to compile several C files supercat@casperkitty.com - 2017-02-08 09:51 -0800
                            Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 21:06 +0000
                              Re: How to compile several C files supercat@casperkitty.com - 2017-02-08 13:20 -0800
                                Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 21:40 +0000
                                  Re: How to compile several C files supercat@casperkitty.com - 2017-02-08 13:49 -0800
                                    Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 23:09 +0000
                                Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 23:25 +0100
                                  Re: How to compile several C files supercat@casperkitty.com - 2017-02-08 15:17 -0800
                                    Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-09 01:17 +0100
                          Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 23:19 +0100
                            Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-08 16:44 -0800
                      Re: How to compile several C files Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 22:32 -0800
                    Re: How to compile several C files Robert Wessel <robertwessel2@yahoo.com> - 2017-02-09 04:03 -0600
                    Re: How to compile several C files Ian Collins <ian-news@hotmail.com> - 2017-02-10 07:52 +1300
                  Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 12:12 +0000
                    Re: How to compile several C files BartC <bc@freeuk.com> - 2017-02-08 13:09 +0000
                      Re: How to compile several C files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-08 05:14 -0800
                      Re: How to compile several C files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 15:32 +0000
                    Re: How to compile several C files David Brown <david.brown@hesbynett.no> - 2017-02-08 15:09 +0100
          Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-07 09:22 -0800
            Re: How to compile several C files Gareth Owen <gwowen@gmail.com> - 2017-02-07 18:29 +0000
              Re: How to compile several C files bart4858@gmail.com - 2017-02-07 11:05 -0800
              Re: How to compile several C files Keith Thompson <kst-u@mib.org> - 2017-02-07 12:26 -0800
    Re: How to compile several C files Barry Schwarz <schwarzb@dqel.com> - 2017-02-07 08:34 -0800
      Re: How to compile several C files Alla _ <modelling.data@gmail.com> - 2017-02-07 08:57 -0800
        Re: How to compile several C files "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-07 12:29 -0500
        Re: How to compile several C files Manfred <noname@invalid.add> - 2017-02-07 19:02 +0100

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

#103435

On 07/02/17 16:42, Richard Heathfield wrote:
> On 07/02/17 15:06, Ben Bacarisse wrote:
>> Once I have two files, I write a makefile.
> 
> I'm slightly lazier than that. Once I have /one/ file, I write a makefile.
> 
> To be more precise, I'm even lazier than /that/ - I run a program to
> write the makefile on my behalf:
> 
> makegen foo > Makefile
> 
> which generates a simple makefile for turning foo.c into foo (the
> executable file).
> 
> (If I were lazier still, I would rewrite makegen to write everything to
> Makefile by default.)
> 
> And before anyone asks, yes, I can feed multiple files to it (the first
> is taken as the executable output filename); yes, I can feed extra flags
> to it via -e=whatever; and yes, I can tell it about libraries using
> -lwhatever.
> 
> I'm not saying it generates a /great/ makefile. But it does all that I
> require of it.
> 

I'm even lazier - I use a Makefile that compiles all the .c files in my
directory, figuring out the dependencies automatically.  For new
projects, often the only thing I need to change in the Makefile is the
name of the final executable.  (I could do that automatically too, but
I'm too lazy.)

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

#103361

On 02/07/2017 09:10 AM, Alla _ wrote:
> Hello!
> 
> I have a program, which I would like to separate into two C files,
> and two .h files. The non-separated version works, but it would
> be logically correct to separate it into two parts.
> Actually, I already have done so. When I tried to
> compile two parts, I got a cryptic message saying that there were 
> some duplicates. Before digging deeper into that error message,
> I would like to found out if I correctly compile both files, and what 
> are the rules. 
> First file is named proforma.c; second one sql.c :
...
> (1) I include both header files in proforma.c and in sql.c
> (2) run in Terminal:
> gcc -Wall -Werror -Wextra  -std=c99  `mysql_config --cflags --libs` proforma.c sql.c -o

I cannot say whether the mysql_config part is correct, but the rest
seems fine, except for one detail: the -o option always requires a
filename argument. It tells gcc what name you want the output file to
have; if you don't want to override the default file name (a.out, in
this case), you don't need the -o option.

The exact text of the error message would be helpful. From my experience
with gcc, I suspect that it's cryptic only because you're unfamiliar
with the relevant terminology.
Since the header files are both included in both *.c files, an obvious
possibility is that the duplicate thing it's referring to is something
in the header files that qualifies as an external definition of an
object or function. External definitions should only appear in *.c
files; what should appear in the corresponding *.h file is a
declaration. People being unclear about the distinction between a
declaration and a definition is a common cause of such problems.

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

#103370

On Tuesday, February 7, 2017 at 6:08:02 PM UTC+3, James Kuyper wrote:
> On 02/07/2017 09:10 AM, Alla _ wrote:
> > Hello!
> > 
> > I have a program, which I would like to separate into two C files,
> > and two .h files. The non-separated version works, but it would
> > be logically correct to separate it into two parts.
> > Actually, I already have done so. When I tried to
> > compile two parts, I got a cryptic message saying that there were 
> > some duplicates. Before digging deeper into that error message,
> > I would like to found out if I correctly compile both files, and what 
> > are the rules. 
> > First file is named proforma.c; second one sql.c :
> ...
> > (1) I include both header files in proforma.c and in sql.c
> > (2) run in Terminal:
> > gcc -Wall -Werror -Wextra  -std=c99  `mysql_config --cflags --libs` proforma.c sql.c -o
> 
> I cannot say whether the mysql_config part is correct, but the rest
> seems fine, except for one detail: the -o option always requires a
> filename argument. It tells gcc what name you want the output file to
> have; if you don't want to override the default file name (a.out, in
> this case), you don't need the -o option.
> 
> The exact text of the error message would be helpful. From my experience
> with gcc, I suspect that it's cryptic only because you're unfamiliar
> with the relevant terminology.
> Since the header files are both included in both *.c files, an obvious
> possibility is that the duplicate thing it's referring to is something
> in the header files that qualifies as an external definition of an
> object or function. External definitions should only appear in *.c
> files; what should appear in the corresponding *.h file is a
> declaration. People being unclear about the distinction between a
> declaration and a definition is a common cause of such problems.

First, thank you everyone for these very helpful comments.

As to the paragraph above, yes, it seems to the be the case. I will
have to look more thoroughly into this. 
I have put all typedefs in proforma.h, as well as all function declarations,
and I have also added structures' declarations and pointers to those 
structures, because those are used by proforma.c and by sql.c

Here is how it looks like (I am not yet posting the gcc error message
because, first, I want to try it again, and if I get the same error I will
post it):
proforma.h
/** Proforma header file **/

#ifndef H_PROFORMA_
#define H_PROFORMA_

#define LINE_SIZE 1024
#define YEARS 15
#define INPUT_YEARS 5
#define INC_LINES 12
#define BALANCE_LINES 21
#define NAME_SIZE 40
#define STAT_TAX 0.38
#define FORECAST_INTEREST 0.10 //WACC
#define MAX_FIELD_WIDTH 9

typedef struct data_1 {
    int       year;
    double    sales;
    double    cogs;
    double    gross_profit;
    double    sga;
    double    oper_inc;
    double    dep_amor;
    double    oper_prof;
    double    int_exp;
    double    gain_loss;
    double    pretax_inc;
    double    tax_exp;
    double    net_inc;
} income_st;

typedef struct data_2 {
    int       cs_year;
    double    cs_sales;
    double    cs_cogs;
    double    cs_gross_profit;
    double    cs_sga;
    double    cs_oper_inc;
    double    cs_dep_amor;
    double    cs_oper_prof;
    double    cs_int_exp;
    double    cs_gain_loss;
    double    cs_pretax_inc;
    double    cs_tax_exp;
    double    cs_net_inc;
} cs_income_st;

typedef struct balance_sheet {
    double    cash;
    double    ar;
    double    inv;
    double    o_cur_a;
    double    t_cur_a;
    double    gross_ppe;
    double    acc_dep;
    double    net_ppe;
    double    intang;
    double    ta;
    double    ap;
    double    tp;
    double    o_cur_l;
    double    t_cur_l;
    double    ltd;
    double    o_l;
    double    tl;
    double    se;
    double    tle;
    double average_ta;
} balance;

typedef struct cs_balance_sheet {
    double    cs_cash;
    double    cs_ar;
    double    cs_inv;
    double    cs_o_cur_a;
    double    cs_t_cur_a;
    double    cs_gross_ppe;
    double    cs_acc_dep;
    double    cs_net_ppe;
    double    cs_intang;
    double    cs_ta;
    double    cs_ap;
    double    cs_tp;
    double    cs_o_cur_l;
    double    cs_t_cur_l;
    double    cs_ltd;
    double    cs_o_l;
    double    cs_tl;
    double    cs_se;
    double    cs_tle;
} cs_balance;

typedef struct assumptions {
    double gr_sales;
    double av_cogs;
    double av_gross_profit;
    double av_sga;
    double av_oper_inc;
    double av_dep_amor;
    double av_oper_prof;
    double av_int_exp;
    double av_gain_loss;
    double av_pretax_inc;
    double av_tax_exp;
    double av_net_inc;
    double industry_rate;
    double ta_turn;
} assumptions;

typedef struct offsets {
    int offset_income;
    int offset_cs_income;
    int offset_balance;
} offsets;

//Structures
income_st income[YEARS];
cs_income_st cs_income[YEARS];
balance bal[YEARS];
cs_balance cs_bal;
assumptions av;

//Pointers to structures
income_st *income_ptr = income;
cs_income_st *cs_income_ptr = cs_income;
balance *bs_ptr = bal;
cs_balance *cs_bs_ptr = &cs_bal;
assumptions *rates = &av;


bool process_files (FILE *input_file_1, FILE *input_file_2,
                    income_st *income_ptr,
                    cs_income_st *cs_income_ptr,
                    balance *bs_ptr,
                    cs_balance *cs_bs_ptr,
                    assumptions *rates);

bool process_inc  (FILE *input_file_1, char *line,
                   income_st *income_ptr,
                   cs_income_st *cs_income_ptr,
                   assumptions *rates,
                   offsets *offset_ptr);

bool process_bal  (FILE *input_file_2, char *line,
                   income_st *income_ptr,
                   balance *bs_ptr,
                   cs_balance *cs_bs_ptr,
                   assumptions *rates,
                   offsets *offset_ptr);

int valid_names   (char *line, const char *names_1[],
                   const char *names_2[],
                   size_t line_num, char *name);

char *skip_spaces (char *line);

int get_year(void);

bool check_input_years(char *line, income_st *income_ptr,
                       cs_income_st *cs_income_ptr,
                       int cur_year);

bool parse_inc_num (char *line, size_t line_num,
                    int offset_income,
                    int offset_cs_income,
                    income_st *income_ptr,
                    cs_income_st *cs_income_ptr,
                    double *member_product);

bool parse_bal_num (char *line, int offset_balance,
                    balance *bs_ptr);

offsets find_struct_member(char *name,
                           offsets *offset_ptr);

double rate_depamor_exp(income_st *income_ptr,
                        balance *bs_ptr);

double rate_int_exp(income_st *income_ptr,
                      balance *bs_ptr);

void pf_sales      (income_st *income_ptr,
                    assumptions *rates);

void pf_ta         (income_st *income_ptr,
                    balance *bs_ptr,
                    assumptions *rates);

void pf_balance    (balance *bs_ptr, cs_balance *cs_bs_ptr);

void pf_income     (income_st *income_ptr, assumptions *rates,
                    balance *bs_ptr);

double ta_turnover(income_st *income_ptr, balance *bs_ptr);

void ta_proforma_rate(income_st *income_ptr,
                      balance *bs_ptr,
                      assumptions *rates,
                      double *rate_1, double *rate_2);

void csbalance_rates(balance *bs_ptr, cs_balance *cs_bs_ptr);

char *line_alloc(void);
char *name_alloc(void);
double industry_rate();
#endif 

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

#103374

On Tuesday, February 7, 2017 at 6:56:36 PM UTC+3, Alla _ wrote:
> On Tuesday, February 7, 2017 at 6:08:02 PM UTC+3, James Kuyper wrote:
> > On 02/07/2017 09:10 AM, Alla _ wrote:
> > > Hello!
> > > 
> > > I have a program, which I would like to separate into two C files,
> > > and two .h files. The non-separated version works, but it would
> > > be logically correct to separate it into two parts.
> > > Actually, I already have done so. When I tried to
> > > compile two parts, I got a cryptic message saying that there were 
> > > some duplicates. Before digging deeper into that error message,
> > > I would like to found out if I correctly compile both files, and what 
> > > are the rules. 
> > > First file is named proforma.c; second one sql.c :
> > ...
> > > (1) I include both header files in proforma.c and in sql.c
> > > (2) run in Terminal:
> > > gcc -Wall -Werror -Wextra  -std=c99  `mysql_config --cflags --libs` proforma.c sql.c -o
> > 
> > I cannot say whether the mysql_config part is correct, but the rest
> > seems fine, except for one detail: the -o option always requires a
> > filename argument. It tells gcc what name you want the output file to
> > have; if you don't want to override the default file name (a.out, in
> > this case), you don't need the -o option.
> > 
> > The exact text of the error message would be helpful. From my experience
> > with gcc, I suspect that it's cryptic only because you're unfamiliar
> > with the relevant terminology.
> > Since the header files are both included in both *.c files, an obvious
> > possibility is that the duplicate thing it's referring to is something
> > in the header files that qualifies as an external definition of an
> > object or function. External definitions should only appear in *.c
> > files; what should appear in the corresponding *.h file is a
> > declaration. People being unclear about the distinction between a
> > declaration and a definition is a common cause of such problems.
> 
> First, thank you everyone for these very helpful comments.
> 
> As to the paragraph above, yes, it seems to the be the case. I will
> have to look more thoroughly into this. 
> I have put all typedefs in proforma.h, as well as all function declarations,
> and I have also added structures' declarations and pointers to those 
> structures, because those are used by proforma.c and by sql.c
> 
> Here is how it looks like (I am not yet posting the gcc error message
> because, first, I want to try it again, and if I get the same error I will
> post it):
> proforma.h
> /** Proforma header file **/
> 
> #ifndef H_PROFORMA_
> #define H_PROFORMA_
> 
> #define LINE_SIZE 1024
> #define YEARS 15
> #define INPUT_YEARS 5
> #define INC_LINES 12
> #define BALANCE_LINES 21
> #define NAME_SIZE 40
> #define STAT_TAX 0.38
> #define FORECAST_INTEREST 0.10 //WACC
> #define MAX_FIELD_WIDTH 9
> 
> typedef struct data_1 {
>     int       year;
>     double    sales;
>     double    cogs;
>     double    gross_profit;
>     double    sga;
>     double    oper_inc;
>     double    dep_amor;
>     double    oper_prof;
>     double    int_exp;
>     double    gain_loss;
>     double    pretax_inc;
>     double    tax_exp;
>     double    net_inc;
> } income_st;
> 
> typedef struct data_2 {
>     int       cs_year;
>     double    cs_sales;
>     double    cs_cogs;
>     double    cs_gross_profit;
>     double    cs_sga;
>     double    cs_oper_inc;
>     double    cs_dep_amor;
>     double    cs_oper_prof;
>     double    cs_int_exp;
>     double    cs_gain_loss;
>     double    cs_pretax_inc;
>     double    cs_tax_exp;
>     double    cs_net_inc;
> } cs_income_st;
> 
> typedef struct balance_sheet {
>     double    cash;
>     double    ar;
>     double    inv;
>     double    o_cur_a;
>     double    t_cur_a;
>     double    gross_ppe;
>     double    acc_dep;
>     double    net_ppe;
>     double    intang;
>     double    ta;
>     double    ap;
>     double    tp;
>     double    o_cur_l;
>     double    t_cur_l;
>     double    ltd;
>     double    o_l;
>     double    tl;
>     double    se;
>     double    tle;
>     double average_ta;
> } balance;
> 
> typedef struct cs_balance_sheet {
>     double    cs_cash;
>     double    cs_ar;
>     double    cs_inv;
>     double    cs_o_cur_a;
>     double    cs_t_cur_a;
>     double    cs_gross_ppe;
>     double    cs_acc_dep;
>     double    cs_net_ppe;
>     double    cs_intang;
>     double    cs_ta;
>     double    cs_ap;
>     double    cs_tp;
>     double    cs_o_cur_l;
>     double    cs_t_cur_l;
>     double    cs_ltd;
>     double    cs_o_l;
>     double    cs_tl;
>     double    cs_se;
>     double    cs_tle;
> } cs_balance;
> 
> typedef struct assumptions {
>     double gr_sales;
>     double av_cogs;
>     double av_gross_profit;
>     double av_sga;
>     double av_oper_inc;
>     double av_dep_amor;
>     double av_oper_prof;
>     double av_int_exp;
>     double av_gain_loss;
>     double av_pretax_inc;
>     double av_tax_exp;
>     double av_net_inc;
>     double industry_rate;
>     double ta_turn;
> } assumptions;
> 
> typedef struct offsets {
>     int offset_income;
>     int offset_cs_income;
>     int offset_balance;
> } offsets;
> 
> //Structures
> income_st income[YEARS];
> cs_income_st cs_income[YEARS];
> balance bal[YEARS];
> cs_balance cs_bal;
> assumptions av;
> 
> //Pointers to structures
> income_st *income_ptr = income;
> cs_income_st *cs_income_ptr = cs_income;
> balance *bs_ptr = bal;
> cs_balance *cs_bs_ptr = &cs_bal;
> assumptions *rates = &av;
> 
> 
> bool process_files (FILE *input_file_1, FILE *input_file_2,
>                     income_st *income_ptr,
>                     cs_income_st *cs_income_ptr,
>                     balance *bs_ptr,
>                     cs_balance *cs_bs_ptr,
>                     assumptions *rates);
> 
> bool process_inc  (FILE *input_file_1, char *line,
>                    income_st *income_ptr,
>                    cs_income_st *cs_income_ptr,
>                    assumptions *rates,
>                    offsets *offset_ptr);
> 
> bool process_bal  (FILE *input_file_2, char *line,
>                    income_st *income_ptr,
>                    balance *bs_ptr,
>                    cs_balance *cs_bs_ptr,
>                    assumptions *rates,
>                    offsets *offset_ptr);
> 
> int valid_names   (char *line, const char *names_1[],
>                    const char *names_2[],
>                    size_t line_num, char *name);
> 
> char *skip_spaces (char *line);
> 
> int get_year(void);
> 
> bool check_input_years(char *line, income_st *income_ptr,
>                        cs_income_st *cs_income_ptr,
>                        int cur_year);
> 
> bool parse_inc_num (char *line, size_t line_num,
>                     int offset_income,
>                     int offset_cs_income,
>                     income_st *income_ptr,
>                     cs_income_st *cs_income_ptr,
>                     double *member_product);
> 
> bool parse_bal_num (char *line, int offset_balance,
>                     balance *bs_ptr);
> 
> offsets find_struct_member(char *name,
>                            offsets *offset_ptr);
> 
> double rate_depamor_exp(income_st *income_ptr,
>                         balance *bs_ptr);
> 
> double rate_int_exp(income_st *income_ptr,
>                       balance *bs_ptr);
> 
> void pf_sales      (income_st *income_ptr,
>                     assumptions *rates);
> 
> void pf_ta         (income_st *income_ptr,
>                     balance *bs_ptr,
>                     assumptions *rates);
> 
> void pf_balance    (balance *bs_ptr, cs_balance *cs_bs_ptr);
> 
> void pf_income     (income_st *income_ptr, assumptions *rates,
>                     balance *bs_ptr);
> 
> double ta_turnover(income_st *income_ptr, balance *bs_ptr);
> 
> void ta_proforma_rate(income_st *income_ptr,
>                       balance *bs_ptr,
>                       assumptions *rates,
>                       double *rate_1, double *rate_2);
> 
> void csbalance_rates(balance *bs_ptr, cs_balance *cs_bs_ptr);
> 
> char *line_alloc(void);
> char *name_alloc(void);
> double industry_rate();
> #endif
Oh dear. I have just realized that I have not deleted those,
now global, arguments in functions' declarations. I am not 
sure you will see this message before reading my previous
post. I should have not posted that header before checking
it all over again, as I initially intended ) Apologies. 

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

#103380

Alla _ <modelling.data@gmail.com> writes:

> On Tuesday, February 7, 2017 at 6:56:36 PM UTC+3, Alla _ wrote:
<snip>
>> Here is how it looks like (I am not yet posting the gcc error message
>> because, first, I want to try it again, and if I get the same error I will
>> post it):
>> proforma.h
>> /** Proforma header file **/
<snip>
>> //Structures
>> income_st income[YEARS];
>> cs_income_st cs_income[YEARS];
>> balance bal[YEARS];
>> cs_balance cs_bal;
>> assumptions av;
>> 
>> //Pointers to structures
>> income_st *income_ptr = income;
>> cs_income_st *cs_income_ptr = cs_income;
>> balance *bs_ptr = bal;
>> cs_balance *cs_bs_ptr = &cs_bal;
>> assumptions *rates = &av;

These are a problem.  If this file is included into two translation
units you will get multiple definitions of these objects.

<snip>
> Oh dear. I have just realized that I have not deleted those,
> now global, arguments in functions' declarations.

I don't know what that means, but it does not sound as if it is related
to what I've commented on so I think my comment is still useful.

<snip>
-- 
Ben.

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

#103383

On Tuesday, February 7, 2017 at 7:45:06 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > On Tuesday, February 7, 2017 at 6:56:36 PM UTC+3, Alla _ wrote:
> <snip>
> >> Here is how it looks like (I am not yet posting the gcc error message
> >> because, first, I want to try it again, and if I get the same error I will
> >> post it):
> >> proforma.h
> >> /** Proforma header file **/
> <snip>
> >> //Structures
> >> income_st income[YEARS];
> >> cs_income_st cs_income[YEARS];
> >> balance bal[YEARS];
> >> cs_balance cs_bal;
> >> assumptions av;
> >> 
> >> //Pointers to structures
> >> income_st *income_ptr = income;
> >> cs_income_st *cs_income_ptr = cs_income;
> >> balance *bs_ptr = bal;
> >> cs_balance *cs_bs_ptr = &cs_bal;
> >> assumptions *rates = &av;
> 
> These are a problem.  If this file is included into two translation
> units you will get multiple definitions of these objects.
> 
> <snip>
> > Oh dear. I have just realized that I have not deleted those,
> > now global, arguments in functions' declarations.
> 
> I don't know what that means, but it does not sound as if it is related
> to what I've commented on so I think my comment is still useful.
Thank you! My comment means that albeit I have moved all 
declarations into scope (all structures and pointers to them), I still
have them as functions' parameters and still pass them to all 
functions, which is redundant as all those structures and pointers
are in scope now. And, yes, by doing so, I have broken the rule
I have been following, i.e. the rule of never putting any variables
into scope. But here I have two files, and numerous functions in
both; the majority of these functions need access to same 
structures. Therefore I thought that it is better to have all 
structures in one place. While writing this, I realized that I still
can define pointers to those structures in both .c files, even
if those pointers point to exact same place. 

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

#103390

On 02/07/2017 11:54 AM, Alla _ wrote:
> On Tuesday, February 7, 2017 at 7:45:06 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>>> On Tuesday, February 7, 2017 at 6:56:36 PM UTC+3, Alla _ wrote:
>> <snip>
>>>> Here is how it looks like (I am not yet posting the gcc error message
>>>> because, first, I want to try it again, and if I get the same error I will
>>>> post it):
>>>> proforma.h
>>>> /** Proforma header file **/
>> <snip>
>>>> //Structures
>>>> income_st income[YEARS];
>>>> cs_income_st cs_income[YEARS];
>>>> balance bal[YEARS];
>>>> cs_balance cs_bal;
>>>> assumptions av;
>>>>
>>>> //Pointers to structures
>>>> income_st *income_ptr = income;
>>>> cs_income_st *cs_income_ptr = cs_income;
>>>> balance *bs_ptr = bal;
>>>> cs_balance *cs_bs_ptr = &cs_bal;
>>>> assumptions *rates = &av;
>>
>> These are a problem.  If this file is included into two translation
>> units you will get multiple definitions of these objects.
>>
>> <snip>
>>> Oh dear. I have just realized that I have not deleted those,
>>> now global, arguments in functions' declarations.
>>
>> I don't know what that means, but it does not sound as if it is related
>> to what I've commented on so I think my comment is still useful.
> Thank you! My comment means that albeit I have moved all
> declarations into scope (all structures and pointers to them), I still

You're using the terminology wrong, so I'm not quite sure what you mean. 
"into scope" is meaningless. I believe you mean "into X scope", where X 
could be any of the following: function, file, block, and function 
prototype. In context, it's probably "into file scope". But scope is not 
sufficient to cover what you've done. You've also given them external 
linkage, which means they can be accessed anywhere in your program. You 
could have given them internal linkage, by declaring them "static".
You've also defined them multiple times, which has undefined behavior. 
The other issues are simply matters of bad design, but the undefined 
behavior is a major problem.

> have them as functions' parameters and still pass them to all
> functions, which is redundant as all those structures and pointers
> are in scope now. And, yes, by doing so, I have broken the rule
> I have been following, i.e. the rule of never putting any variables
> into scope.

I think that this means that you originally had your code written 
correctly, and have now disimproved it by removing pointers from 
function parameter lists, and made both the things they pointed at, and 
the pointers themselves, objects with external linkage and file scope. 
This is a breathtakingly bad idea.

> ... But here I have two files, and numerous functions in
> both; the majority of these functions need access to same
> structures.

That's an argument for collecting the structures together into one 
larger structure, and passing around a pointer to that structure. It's 
not an argument for what you've actually done.

> ... Therefore I thought that it is better to have all
> structures in one place. While writing this, I realized that I still
> can define pointers to those structures in both .c files, even
> if those pointers point to exact same place.

Those pointers are almost certainly pointless. As far as I can tell, in 
any context where you use one of those pointers, your code would be 
better off accessing the pointed-at object directly. The only good 
reason for using pointers is if you're passing around the object by 
passing pointers to the object as function parameters - but from what 
you're saying, it seems like you've eliminated that.

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

#103399

On Tuesday, February 7, 2017 at 8:21:06 PM UTC+3, James R. Kuyper wrote:
> On 02/07/2017 11:54 AM, Alla _ wrote:
> > On Tuesday, February 7, 2017 at 7:45:06 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> >>> On Tuesday, February 7, 2017 at 6:56:36 PM UTC+3, Alla _ wrote:
> >> <snip>
> >>>> Here is how it looks like (I am not yet posting the gcc error message
> >>>> because, first, I want to try it again, and if I get the same error I will
> >>>> post it):
> >>>> proforma.h
> >>>> /** Proforma header file **/
> >> <snip>
> >>>> //Structures
> >>>> income_st income[YEARS];
> >>>> cs_income_st cs_income[YEARS];
> >>>> balance bal[YEARS];
> >>>> cs_balance cs_bal;
> >>>> assumptions av;
> >>>>
> >>>> //Pointers to structures
> >>>> income_st *income_ptr = income;
> >>>> cs_income_st *cs_income_ptr = cs_income;
> >>>> balance *bs_ptr = bal;
> >>>> cs_balance *cs_bs_ptr = &cs_bal;
> >>>> assumptions *rates = &av;
> >>
> >> These are a problem.  If this file is included into two translation
> >> units you will get multiple definitions of these objects.
> >>
> >> <snip>
> >>> Oh dear. I have just realized that I have not deleted those,
> >>> now global, arguments in functions' declarations.
> >>
> >> I don't know what that means, but it does not sound as if it is related
> >> to what I've commented on so I think my comment is still useful.
> > Thank you! My comment means that albeit I have moved all
> > declarations into scope (all structures and pointers to them), I still
> 
> You're using the terminology wrong, so I'm not quite sure what you mean. 
> "into scope" is meaningless. I believe you mean "into X scope", where X 
> could be any of the following: function, file, block, and function 
> prototype. In context, it's probably "into file scope". But scope is not 
> sufficient to cover what you've done. You've also given them external 
> linkage, which means they can be accessed anywhere in your program. You 
> could have given them internal linkage, by declaring them "static".
> You've also defined them multiple times, which has undefined behavior. 
> The other issues are simply matters of bad design, but the undefined 
> behavior is a major problem.
> 
> > have them as functions' parameters and still pass them to all
> > functions, which is redundant as all those structures and pointers
> > are in scope now. And, yes, by doing so, I have broken the rule
> > I have been following, i.e. the rule of never putting any variables
> > into scope.
> 
> I think that this means that you originally had your code written 
> correctly, and have now disimproved it by removing pointers from 
> function parameter lists, and made both the things they pointed at, and 
> the pointers themselves, objects with external linkage and file scope. 
> This is a breathtakingly bad idea.
> 
Yes, I see that it was a bad idea, and it was only a version, so
I am not back to the original one, and I even don't split two
pieces anymore, i.e. I have the sql part in the main program.
Now I have only one header, and one .c file. Splitting turned 
out to be not such a pleasant task given the need for both
.c files to access same structures, thus creating the need 
for global objects, which, as have been discussed many times,
usually a bad idea. 
> > ... But here I have two files, and numerous functions in
> > both; the majority of these functions need access to same
> > structures.
> 
> That's an argument for collecting the structures together into one 
> larger structure, and passing around a pointer to that structure. It's 
> not an argument for what you've actually done.
> 
> > ... Therefore I thought that it is better to have all
> > structures in one place. While writing this, I realized that I still
> > can define pointers to those structures in both .c files, even
> > if those pointers point to exact same place.
> 
> Those pointers are almost certainly pointless. As far as I can tell, in 
> any context where you use one of those pointers, your code would be 
> better off accessing the pointed-at object directly. The only good 
> reason for using pointers is if you're passing around the object by 
> passing pointers to the object as function parameters - but from what 
> you're saying, it seems like you've eliminated that.

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

#103404

On 07/02/17 18:05, Alla _ wrote:

<snip>

> Now I have only one header, and one .c file. Splitting turned
> out to be not such a pleasant task given the need for both
> .c files to access same structures, thus creating the need
> for global objects,

No no no no NO! It does /not/ create such a need. The structure /types/ 
can be shared (which is one major reason we have headers). The /objects/ 
can be passed around as parameters.

Nevertheless: I think you've made a good decision. Multiple-file 
projects can wait until you have more time available to learn how to do 
them properly.

-- 
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]

#103407

On 07/02/17 18:27, Richard Heathfield wrote:
> The /objects/ can be passed around as parameters.

The addresses of the objects.

-- 
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]

#103416

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 07/02/17 18:05, Alla _ wrote:
>
> <snip>
>
>> Now I have only one header, and one .c file. Splitting turned
>> out to be not such a pleasant task given the need for both
>> .c files to access same structures, thus creating the need
>> for global objects,
>
> No no no no NO! It does /not/ create such a need. The structure /types/ 
> can be shared (which is one major reason we have headers). The /objects/ 
> can be passed around as parameters.
>
> Nevertheless: I think you've made a good decision. Multiple-file 
> projects can wait until you have more time available to learn how to do 
> them properly.

The word "structure" should be treated as an adjective, not a noun.  You
can have a structure object or a structure type.  If you say you need to
access the same structures, it's not clear which one you're talking
about.

The same applies to "array", "pointer", et al.

-- 
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]

#103438

On 07/02/17 19:27, Richard Heathfield wrote:
> On 07/02/17 18:05, Alla _ wrote:
> 
> <snip>
> 
>> Now I have only one header, and one .c file. Splitting turned
>> out to be not such a pleasant task given the need for both
>> .c files to access same structures, thus creating the need
>> for global objects,
> 
> No no no no NO! It does /not/ create such a need. The structure /types/
> can be shared (which is one major reason we have headers). The /objects/
> can be passed around as parameters.
> 
> Nevertheless: I think you've made a good decision. Multiple-file
> projects can wait until you have more time available to learn how to do
> them properly.
> 

And when you do try it, do so with a minimal test program.  Don't try it
first on a program that is so big that it makes sense to split it into
multiple files - start small so that you can see what is happening.

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

#103484

On Wednesday, February 8, 2017 at 12:33:40 PM UTC+3, David Brown wrote:
> On 07/02/17 19:27, Richard Heathfield wrote:
> > On 07/02/17 18:05, Alla _ wrote:
> > 
> > <snip>
> > 
> >> Now I have only one header, and one .c file. Splitting turned
> >> out to be not such a pleasant task given the need for both
> >> .c files to access same structures, thus creating the need
> >> for global objects,
> > 
> > No no no no NO! It does /not/ create such a need. The structure /types/
> > can be shared (which is one major reason we have headers). The /objects/
> > can be passed around as parameters.
> > 
> > Nevertheless: I think you've made a good decision. Multiple-file
> > projects can wait until you have more time available to learn how to do
> > them properly.
> > 
> 
> And when you do try it, do so with a minimal test program.  Don't try it
> first on a program that is so big that it makes sense to split it into
> multiple files - start small so that you can see what is happening.

Yes, I will do so. 

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

#103385

Alla _ <modelling.data@gmail.com> writes:
[...]
> proforma.h
> /** Proforma header file **/
>
> #ifndef H_PROFORMA_
> #define H_PROFORMA_
>
[...]
>
> typedef struct data_1 {
[...]
> } income_st;
>
> typedef struct data_2 {
[...]
> } cs_income_st;
>
> typedef struct balance_sheet {
[...]
> } balance;
>
> typedef struct cs_balance_sheet {
[...]
> } cs_balance;
>
> typedef struct assumptions {
[...]
> } assumptions;
>
> typedef struct offsets {
[...]
> } offsets;

There is no coherent relationship between your typedef names and your
struct tag names.  I suggest that you consistently use the same name for
both.  Either that, or use some consistent pattern like, say, appending
"_s" to the struct tag name.  (Personally I wouldn't bother with the
typedefs, but using typedefs for structs is a common style.)

> //Structures
> income_st income[YEARS];
> cs_income_st cs_income[YEARS];
> balance bal[YEARS];
> cs_balance cs_bal;
> assumptions av;
>
> //Pointers to structures
> income_st *income_ptr = income;
> cs_income_st *cs_income_ptr = cs_income;
> balance *bs_ptr = bal;
> cs_balance *cs_bs_ptr = &cs_bal;
> assumptions *rates = &av;

You're defining (as opposed to just declaring) objects in a header file.
Don't do that.  If the header is included by more than one ".c" file,
you'll have multiple definitions, and your program will fail to link.

If you really need "global" objects, variables that are visible from
more than one source file, you should *declare* them in a .h file (with
"extern") and *define* then in a .c file (which includes the
corresponding .h file).

Better yet, try to avoid having global objects at all.  At least isolate
these variables and their use to a single .c file.  If you need to
access them in other .c files, pass them as function arguments (directly
or via pointers).

[...]
> #endif 

-- 
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]

#103386

On 02/07/2017 10:56 AM, Alla _ wrote:
> On Tuesday, February 7, 2017 at 6:08:02 PM UTC+3, James Kuyper wrote:
...
>> Since the header files are both included in both *.c files, an obvious
>> possibility is that the duplicate thing it's referring to is something
>> in the header files that qualifies as an external definition of an
>> object or function. External definitions should only appear in *.c
>> files; what should appear in the corresponding *.h file is a
>> declaration. People being unclear about the distinction between a
>> declaration and a definition is a common cause of such problems.
>
> First, thank you everyone for these very helpful comments.
>
> As to the paragraph above, yes, it seems to the be the case. I will
> have to look more thoroughly into this.
> I have put all typedefs in proforma.h, as well as all function declarations,
> and I have also added structures' declarations and pointers to those
> structures, because those are used by proforma.c and by sql.c

You could declare such pointers in the headers (which is a bad idea, you 
should be passing them to the relevant functions as function arguments). 
You most definitely should NOT define any pointers there.


> Here is how it looks like (I am not yet posting the gcc error message
> because, first, I want to try it again, and if I get the same error I will
> post it):
> proforma.h

All of the following are object definitions. They do NOT belong in a 
header file - you need to move each of these definitions to one or the 
other of the *.c files. If an object's name is used in both *.c file, 
you should have a declaration for that object in one of the two header 
files. But that declaration would look different from from these 
definitions. At a minimum, you would put "extern" at the beginning of 
each declaration. Also, for the arrays, it's not necessary to put the 
actual number of elements in the object declaration, only in the object 
definition.

> //Structures
> income_st income[YEARS];
> cs_income_st cs_income[YEARS];
> balance bal[YEARS];
> cs_balance cs_bal;
> assumptions av;
>
> //Pointers to structures
> income_st *income_ptr = income;
> cs_income_st *cs_income_ptr = cs_income;
> balance *bs_ptr = bal;
> cs_balance *cs_bs_ptr = &cs_bal;
> assumptions *rates = &av;

Do you have any plans to ever change the values of these pointers? If 
not, there's no point in defining them. Anywhere where your code 
currently uses "income_ptr", it should be changed to use "income", which 
will automatically be converted into a pointer to the first element of 
the income array. Any time your code uses cs_bs_ptr, it should be 
changed to use &cs_bal. Similar statements can be made about each of the 
other pointers.

It is, in general, a bad idea to define objects with external linkage 
like this. It makes it excessively easy to write code which is 
excessively difficult to debug. In general, every object should reside 
in one particular *.c files. Functions inside that file should pass a 
pointer to that object as an argument to any other functions that need 
access to it. By retaining tight control over which parts of your code 
have access to each object, you'll make it a lot easier to debug your code.

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

#103387

On Tuesday, February 7, 2017 at 8:07:57 PM UTC+3, James R. Kuyper wrote:
> On 02/07/2017 10:56 AM, Alla _ wrote:
> > On Tuesday, February 7, 2017 at 6:08:02 PM UTC+3, James Kuyper wrote:
> ...
> >> Since the header files are both included in both *.c files, an obvious
> >> possibility is that the duplicate thing it's referring to is something
> >> in the header files that qualifies as an external definition of an
> >> object or function. External definitions should only appear in *.c
> >> files; what should appear in the corresponding *.h file is a
> >> declaration. People being unclear about the distinction between a
> >> declaration and a definition is a common cause of such problems.
> >
> > First, thank you everyone for these very helpful comments.
> >
> > As to the paragraph above, yes, it seems to the be the case. I will
> > have to look more thoroughly into this.
> > I have put all typedefs in proforma.h, as well as all function declarations,
> > and I have also added structures' declarations and pointers to those
> > structures, because those are used by proforma.c and by sql.c
> 
> You could declare such pointers in the headers (which is a bad idea, you 
> should be passing them to the relevant functions as function arguments). 
> You most definitely should NOT define any pointers there.
> 
> 
> > Here is how it looks like (I am not yet posting the gcc error message
> > because, first, I want to try it again, and if I get the same error I will
> > post it):
> > proforma.h
> 
> All of the following are object definitions. They do NOT belong in a 
> header file - you need to move each of these definitions to one or the 
> other of the *.c files. If an object's name is used in both *.c file, 
> you should have a declaration for that object in one of the two header 
> files. But that declaration would look different from from these 
> definitions. At a minimum, you would put "extern" at the beginning of 
> each declaration. Also, for the arrays, it's not necessary to put the 
> actual number of elements in the object declaration, only in the object 
> definition.
> 
> > //Structures
> > income_st income[YEARS];
> > cs_income_st cs_income[YEARS];
> > balance bal[YEARS];
> > cs_balance cs_bal;
> > assumptions av;
> >
> > //Pointers to structures
> > income_st *income_ptr = income;
> > cs_income_st *cs_income_ptr = cs_income;
> > balance *bs_ptr = bal;
> > cs_balance *cs_bs_ptr = &cs_bal;
> > assumptions *rates = &av;
> 
> Do you have any plans to ever change the values of these pointers? If 
> not, there's no point in defining them. Anywhere where your code 
> currently uses "income_ptr", it should be changed to use "income", which 
> will automatically be converted into a pointer to the first element of 
> the income array. Any time your code uses cs_bs_ptr, it should be 
> changed to use &cs_bal. Similar statements can be made about each of the 
> other pointers.
> 
> It is, in general, a bad idea to define objects with external linkage 
> like this. It makes it excessively easy to write code which is 
> excessively difficult to debug. In general, every object should reside 
> in one particular *.c files. Functions inside that file should pass a 
> pointer to that object as an argument to any other functions that need 
> access to it. By retaining tight control over which parts of your code 
> have access to each object, you'll make it a lot easier to debug your code.

Thank you very much. Not yet clear, but I will now re-read and try to
implement your comments. I truly didn't want to use globals, but then
I decided that it might be not such a bad idea in this case. I will correct
that now. 

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

#103391

On 07/02/17 17:14, Alla _ wrote:
<snip>
> I truly didn't want to use globals,

Correct.

> but then
> I decided that it might be not such a bad idea in this case.

Incorrect.

> I will correct that now.

Correct.

Anecdote time: a colleague asked me for help with a recursive call that 
wasn't behaving as expected. He showed me the code, and I couldn't see 
anything particularly wrong with it, except that there was one 
identifier for which I couldn't see a definition. I asked him about it, 
and he said it was at the top (i.e. at file scope). When I'd finished 
slapping him about the head, I asked him why he'd done that, and he said 
that he'd just put it there while he got the code working. I moved the 
definition into the recursive function, and bingo! Everything worked fine.

RULE ONE: DO NOT USE FILE SCOPE OBJECTS!

RULE TWO (for experts only): DO NOT USE FILE SCOPE OBJECTS YET!

-- 
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]

#103401

On Tuesday, February 7, 2017 at 8:22:00 PM UTC+3, Richard Heathfield wrote:
> On 07/02/17 17:14, Alla _ wrote:
> <snip>
> > I truly didn't want to use globals,
> 
> Correct.
> 
> > but then
> > I decided that it might be not such a bad idea in this case.
> 
> Incorrect.
> 
> > I will correct that now.
> 
> Correct.
> 
> Anecdote time: a colleague asked me for help with a recursive call that 
> wasn't behaving as expected. He showed me the code, and I couldn't see 
> anything particularly wrong with it, except that there was one 
> identifier for which I couldn't see a definition. I asked him about it, 
> and he said it was at the top (i.e. at file scope). When I'd finished 
> slapping him about the head, I asked him why he'd done that, and he said 
> that he'd just put it there while he got the code working. I moved the 
> definition into the recursive function, and bingo! Everything worked fine.
> 
> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!
> 
> RULE TWO (for experts only): DO NOT USE FILE SCOPE OBJECTS YET!
> 
You've successfully drummed this idea into me a rather 
long time ago, very long time )

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

#103405

On Tuesday, February 7, 2017 at 8:22:00 PM UTC+3, Richard Heathfield wrote:
> On 07/02/17 17:14, Alla _ wrote:
> <snip>
> > I truly didn't want to use globals,
> 
> Correct.
> 
> > but then
> > I decided that it might be not such a bad idea in this case.
> 
> Incorrect.
> 
> > I will correct that now.
> 
> Correct.
> 
> Anecdote time: a colleague asked me for help with a recursive call that 
> wasn't behaving as expected. He showed me the code, and I couldn't see 
> anything particularly wrong with it, except that there was one 
> identifier for which I couldn't see a definition. I asked him about it, 
> and he said it was at the top (i.e. at file scope). When I'd finished 
> slapping him about the head, I asked him why he'd done that, and he said 
> that he'd just put it there while he got the code working. I moved the 
> definition into the recursive function, and bingo! Everything worked fine.
> 
> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!
> 
> RULE TWO (for experts only): DO NOT USE FILE SCOPE OBJECTS YET!
> 

Anyway, as I pointed out in my reply to James, I have moved everything
back again, so no more globals. 

Yet I do have my table )))) I know it's nothing for you, especially given
my bad code design, but I did manage to connect to mysql, 
create database, create a new user (that was a head scratcher!), 
and grant it privileges for the new database (though I have no idea
yet how to use that new user :)), create a table with columns, output
all computed values into it. Neat. Even though I am aware, thanks to
you, how bad my coding is, I am happy that I have managed to 
write this whole program. I can't believe I did that, honestly. 
And for a person like me, who has been so far from programming
and any technical stuff, it is a huge result ) Happily staring at my 
sql table )

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

#103408

On 07/02/17 18:28, Alla _ wrote:

<snip>

> Yet I do have my table )))) I know it's nothing for you

On the contrary, I know the feeling and I'm really glad for you.

> Happily staring at my sql table )

Understood. It's moments like that that keep us doing what we do.

-- 
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]

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

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

csiph-web