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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#103409

On Tuesday, February 7, 2017 at 9:43:24 PM UTC+3, Richard Heathfield wrote:
> 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.

Thank you very much ) Truly, I won't have that if not everyone's help here.

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

#103412

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

> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!

I think it would be better to unravel these intertwined concepts.
Objects don't have scope, they have lifetime.  It's names that have
scope (and sometimes linkage).  What most people call "globals" are
names of objects defined at file scope.  This gives the objects static
storage duration (even if not declared static) and gives the names (if
not declared static) external linkage.

It's almost impossible to write C without using objects with static
storage duration (printf("hello world!\n");) and names with file scope
are common and not usually frowned upon (enum { ERROR_NO_INPUT = -1 };).
The problems usually come from using named objects to communicate
between functions.

I think the best rule is that functions should not modify objects via
file-scope names.  Some may object that this permits reading such data,
but file-scope data tables are so common that I don't think they can be
banned by fiat.

-- 
Ben.

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

#103414

On 07/02/17 19:28, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>
>> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!
>
> I think it would be better to unravel these intertwined concepts.
> Objects don't have scope, they have lifetime.

I plead guilty. But I couldn't say file scope identifiers, because that 
would include functions. And so on and so forth. Still, when you're 
right you're right.

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

#103440

On 07/02/17 20:28, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
> 
>> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!
> 
> I think it would be better to unravel these intertwined concepts.
> Objects don't have scope, they have lifetime.  It's names that have
> scope (and sometimes linkage).  What most people call "globals" are
> names of objects defined at file scope.  This gives the objects static
> storage duration (even if not declared static) and gives the names (if
> not declared static) external linkage.

There is a big distinction between objects defined at file scope with
"static", and those defined at file scope /without/ "static".  The
lifetime is the same, the scope of the identifier is the same, but the
linkage is different.

File static data can often be extremely useful.  It lets you have
controlled access to the data from a known set of functions (those in
the same file), without having lots of pointers passed around as
function parameters.  It is somewhat like having a singleton class in
C++, with the static data being the data members, static functions being
private methods, and non-static functions being public methods.

"globals" usually (IME) refers to file scope data that is /not/ static,
and thus has external linkage and can be access from other files.  That
is when you need to be very wary - any other files can access the data
so you have lost that control.  Global data like this is often viewed as
"evil", and that's not a bad first approximation.  It can be useful when
used correctly - but you need to be very careful.

Global constant data is much less of a problem, but like non-static
functions the identifiers use a program-wide namespace.  Defining a
non-static const array with the name "data" is a bad idea - though it
might be okay for static const data.

> 
> It's almost impossible to write C without using objects with static
> storage duration (printf("hello world!\n");) and names with file scope
> are common and not usually frowned upon (enum { ERROR_NO_INPUT = -1 };).
> The problems usually come from using named objects to communicate
> between functions.
> 
> I think the best rule is that functions should not modify objects via
> file-scope names.  Some may object that this permits reading such data,
> but file-scope data tables are so common that I don't think they can be
> banned by fiat.
> 

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

#103452

On 08/02/17 10:25, David Brown wrote:
> On 07/02/17 20:28, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>
>>> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!

(or rather, don't identify objects at file scope!)

> There is a big distinction between objects defined at file scope with
> "static", and those defined at file scope /without/ "static".  The
> lifetime is the same, the scope of the identifier is the same, but the
> linkage is different.

True. With internal linkage, the mess is limited to one translation 
unit. With external linkage, it could be anywhere.

> File static data can often be extremely useful.  It lets you have
> controlled access to the data from a known set of functions (those in
> the same file), without having lots of pointers passed around as
> function parameters.  It is somewhat like having a singleton class in
> C++, with the static data being the data members, static functions being
> private methods, and non-static functions being public methods.

I always wondered about static data in C++ classes. The whole point of a 
class is that each object knows all it needs to know about *itself*. A 
static object in a C++ class has just one value that is shared across 
all objects of that class.

A friend of mine, who was a student at the time, once tried to explain 
to me why it was a good idea. "Imagine a 'Student' class," he said. (I 
suspect it was a familiar example to him at the time!) He explained that 
it would be very useful for there to be a static member called, say, 
NumStudents, which would record how many students there actually are, so 
that every Student object would always know how many Student objects exist.

"You're a student, right?"

He acknowledged the fact.

"Exactly how many students are there at your university?"

"How should I know? Oh, I see."

> "globals" usually (IME) refers to file scope data that is /not/ static,
> and thus has external linkage and can be access from other files.  That
> is when you need to be very wary - any other files can access the data
> so you have lost that control.  Global data like this is often viewed as
> "evil", and that's not a bad first approximation.  It can be useful when
> used correctly - but you need to be very careful.

Yes. Sometimes one has no choice - one arrives on a project to find that 
they /already/ have a zillion such identifiers, and there isn't the time 
or the budget to fix the problem (although there always seems to be 
plenty of time and budget to fix the second-generation problems that 
ensue!).

I /have/ defined a file scope non-const with external linkage in real 
world code. Once ever, I think. It was very, very evil, but for that 
particular project it was still the lesser of two evils. The alternative 
was to add an extra parameter to every single function in the library, 
and that included rewriting qsort() and bsearch() to support comparison 
functions with three parameters.

<snip>

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

#103465

On 08/02/17 13:11, Richard Heathfield wrote:
> On 08/02/17 10:25, David Brown wrote:
>> On 07/02/17 20:28, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> <snip>
>>>
>>>> RULE ONE: DO NOT USE FILE SCOPE OBJECTS!
> 
> (or rather, don't identify objects at file scope!)
> 
>> There is a big distinction between objects defined at file scope with
>> "static", and those defined at file scope /without/ "static".  The
>> lifetime is the same, the scope of the identifier is the same, but the
>> linkage is different.
> 
> True. With internal linkage, the mess is limited to one translation
> unit. With external linkage, it could be anywhere.
> 
>> File static data can often be extremely useful.  It lets you have
>> controlled access to the data from a known set of functions (those in
>> the same file), without having lots of pointers passed around as
>> function parameters.  It is somewhat like having a singleton class in
>> C++, with the static data being the data members, static functions being
>> private methods, and non-static functions being public methods.
> 
> I always wondered about static data in C++ classes. The whole point of a
> class is that each object knows all it needs to know about *itself*. A
> static object in a C++ class has just one value that is shared across
> all objects of that class.

Yes, and that can be very useful.  (Since a C file with static data is
roughly like a singleton class, it does not matter if you view that data
as class static data or normal class data.)

> 
> A friend of mine, who was a student at the time, once tried to explain
> to me why it was a good idea. "Imagine a 'Student' class," he said. (I
> suspect it was a familiar example to him at the time!) He explained that
> it would be very useful for there to be a static member called, say,
> NumStudents, which would record how many students there actually are, so
> that every Student object would always know how many Student objects exist.
> 
> "You're a student, right?"
> 
> He acknowledged the fact.
> 
> "Exactly how many students are there at your university?"
> 
> "How should I know? Oh, I see."

Maybe it's a very social university, and you want methods like
"send_party_invitations_to_everyone".

Often the static data will be for internal use, rather than public.  The
static "NumStudents" member could be private and used to create unique
student ids.

Sometimes it would make more sense to have a "university" class, and
have every "student" object be attached to a "university" object in some
way - the "university" object would then track the number of students.

In effect, static member data simply gives you a convenient place to
have a singleton object that is automatically attached to all members of
the class, without having to define that "master" class.

(Static member functions and static const/constexpr data have plenty of
uses.)

> 
>> "globals" usually (IME) refers to file scope data that is /not/ static,
>> and thus has external linkage and can be access from other files.  That
>> is when you need to be very wary - any other files can access the data
>> so you have lost that control.  Global data like this is often viewed as
>> "evil", and that's not a bad first approximation.  It can be useful when
>> used correctly - but you need to be very careful.
> 
> Yes. Sometimes one has no choice - one arrives on a project to find that
> they /already/ have a zillion such identifiers, and there isn't the time
> or the budget to fix the problem (although there always seems to be
> plenty of time and budget to fix the second-generation problems that
> ensue!).

Ah, yes - "blame it on the predecessor" is a good reason for any dodgy
programming practice :-)

> 
> I /have/ defined a file scope non-const with external linkage in real
> world code. Once ever, I think. It was very, very evil, but for that
> particular project it was still the lesser of two evils. The alternative
> was to add an extra parameter to every single function in the library,
> and that included rewriting qsort() and bsearch() to support comparison
> functions with three parameters.
> 

In my type of programming, it is a good deal more common.  But that is
because I have complete control of the files that will use the data,
because I write them too, and because passing things around with
function parameters and pointers can be too much overhead on small
microcontrollers.  Reading a variable "currentSpeed" that has external
linkage might take one clock cycles - calling the function
"getCurrentSpeed" to read a static (internal linkage) variable in
another module might take a dozen clock cycles and lose more due to
register shuffling and lost optimisations on the caller site.  That can
matter in my line of work.  It might be evil, but it can be a necessary
evil.

(Improvements in link-time optimisation are reducing this sort of
overhead - I hope in the future to be able to use LTO so that I can use
an inter-module getCurrentSpeed function that results in the same
optimal code as using globals.)

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

#103467

On 08/02/17 13:58, David Brown wrote:
> On 08/02/17 13:11, Richard Heathfield wrote:

<snip>

>> A friend of mine, who was a student at the time, once tried to explain
>> to me why it was a good idea. "Imagine a 'Student' class," he said. (I
>> suspect it was a familiar example to him at the time!) He explained that
>> it would be very useful for there to be a static member called, say,
>> NumStudents, which would record how many students there actually are, so
>> that every Student object would always know how many Student objects exist.
>>
>> "You're a student, right?"
>>
>> He acknowledged the fact.
>>
>> "Exactly how many students are there at your university?"
>>
>> "How should I know? Oh, I see."
>
> Maybe it's a very social university, and you want methods like
> "send_party_invitations_to_everyone".

Yes, which means the *university* needs to keep track of how many 
students there are - and not just for sending out party invitations 
either. So the object that records the number of students belongs in the 
University class, not the Student class. And, that way, you can have 
more than one university, each with a different number of students 
(which, I am given to understand, is a closer model of the real world).

> Often the static data will be for internal use, rather than public.  The
> static "NumStudents" member could be private and used to create unique
> student ids.

Again, it's not the student's job to create a unique student ID. It's 
the university's job.

>
> Sometimes it would make more sense to have a "university" class,

Ah! We're back on the same page.

<snip>

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

#103472

On Wednesday, February 8, 2017 at 8:24:09 AM UTC-6, Richard Heathfield wrote:
> Yes, which means the *university* needs to keep track of how many 
> students there are - and not just for sending out party invitations 
> either. So the object that records the number of students belongs in the 
> University class, not the Student class. And, that way, you can have 
> more than one university, each with a different number of students 
> (which, I am given to understand, is a closer model of the real world).

Who creates Student objects?  If the Student class is given the responsibility
of creating its own instances, then it would make sense to have it also be
responsibility for keeping track of how many were created.  If, however,
instances of Student are created by some other class (e.g. University), then
that class would likely be responsible for keeping tack of how many instances
it created.

If Student instances could be created without involving any other classes,
who else but the Student class could keep track of how many instances
existed?

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

#103473

On 08/02/17 15:48, supercat@casperkitty.com wrote:
> On Wednesday, February 8, 2017 at 8:24:09 AM UTC-6, Richard Heathfield wrote:
>> Yes, which means the *university* needs to keep track of how many
>> students there are - and not just for sending out party invitations
>> either. So the object that records the number of students belongs in the
>> University class, not the Student class. And, that way, you can have
>> more than one university, each with a different number of students
>> (which, I am given to understand, is a closer model of the real world).
>
> Who creates Student objects?

Parents.

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

#103475

On 08/02/17 17:09, Richard Heathfield wrote:
> On 08/02/17 15:48, supercat@casperkitty.com wrote:
>> On Wednesday, February 8, 2017 at 8:24:09 AM UTC-6, Richard Heathfield
>> wrote:
>>> Yes, which means the *university* needs to keep track of how many
>>> students there are - and not just for sending out party invitations
>>> either. So the object that records the number of students belongs in the
>>> University class, not the Student class. And, that way, you can have
>>> more than one university, each with a different number of students
>>> (which, I am given to understand, is a closer model of the real world).
>>
>> Who creates Student objects?
> 
> Parents.
> 

I find students are quite good at objecting by themselves :-)

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

#103469

Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> Yes. Sometimes one has no choice - one arrives on a project to find
> that they /already/ have a zillion such identifiers, and there isn't
> the time or the budget to fix the problem (although there always seems
> to be plenty of time and budget to fix the second-generation problems
> that ensue!).
>
> I /have/ defined a file scope non-const with external linkage in real
> world code. Once ever, I think. It was very, very evil, but for that
> particular project it was still the lesser of two evils.

It would help to be able to use const data more often but C has a
problem here: you can't alter a const object without undefined
behaviour, and you don't always have the right value at the point of
definition.  For example, you might want to say

  const char *const program_name;

so that your error reporting module can use it.   But in main() you'd
have to write

  program_name = argv[0] ? argv[0] : "unknown program";

and, of course, you can't.

You could (and I have done) any of these:

(a) provide a function const char *program_name(void); which will give
    you a lot of flexibility in the future but can seem a little over
    the top for simple programs.

(b) static const char *local_program_name;
    const char *const *const program_name = &local_program_name;

    and use *program_name outside of the main translation unit.

(c) break the type rules.

(d) just allow extern const *program_name;

What do you (generic you -- all of you) like to do in these situations?
(This example is many not a good one -- please suggest others where
you've wanted to share unchanging data between TUs.)

> The
> alternative was to add an extra parameter to every single function in
> the library, and that included rewriting qsort() and bsearch() to
> support comparison functions with three parameters.

I've had a similar situation but you don't (always) have to re-write
qsort and bsearch.  You can put a pointer to the configuration (or
whatever is it) into a static file-scope object just before the qsort
call and, just to be safe, you can nullify it after.  If the qsort call
is separated form the comparison function definition you will be forced
to use an extern pointer, but the danger becomes very limited -- only
for the length of the sort is the data globally available.

-- 
Ben.

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

#103474

On 08/02/17 16:01, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>> Yes. Sometimes one has no choice - one arrives on a project to find
>> that they /already/ have a zillion such identifiers, and there isn't
>> the time or the budget to fix the problem (although there always seems
>> to be plenty of time and budget to fix the second-generation problems
>> that ensue!).
>>
>> I /have/ defined a file scope non-const with external linkage in real
>> world code. Once ever, I think. It was very, very evil, but for that
>> particular project it was still the lesser of two evils.
> 
> It would help to be able to use const data more often but C has a
> problem here: you can't alter a const object without undefined
> behaviour, and you don't always have the right value at the point of
> definition.  For example, you might want to say
> 
>   const char *const program_name;
> 
> so that your error reporting module can use it.   But in main() you'd
> have to write
> 
>   program_name = argv[0] ? argv[0] : "unknown program";
> 
> and, of course, you can't.
> 
> You could (and I have done) any of these:
> 
> (a) provide a function const char *program_name(void); which will give
>     you a lot of flexibility in the future but can seem a little over
>     the top for simple programs.
> 
> (b) static const char *local_program_name;
>     const char *const *const program_name = &local_program_name;
> 
>     and use *program_name outside of the main translation unit.
> 
> (c) break the type rules.
> 
> (d) just allow extern const *program_name;
> 
> What do you (generic you -- all of you) like to do in these situations?
> (This example is many not a good one -- please suggest others where
> you've wanted to share unchanging data between TUs.)

I'd like to be able to write :

	extern const char *const program_name;

in a header, and have the definition as:

	const char* program_name;

in the one file that is allowed to set it.  In other words, I'd like to
be able to use "const" to mark a declaration as read-only, even though
the definition is writeable in one TU.  But that's not allowed in C.

What you can do, and I have done, is something like:

	// In one C file
	int counter_private;

	// In header file
	extern int counter_private;	// Do not use!
	#define counter ((const int) counter_private)

or
	static inline int readCounter(void) { return counter_private; }

These both prevent accidental changes to the variable while keeping the
efficiency of directly accessing the memory.

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

#103480

David Brown <david.brown@hesbynett.no> writes:
[...]
> What you can do, and I have done, is something like:
>
> 	// In one C file
> 	int counter_private;
>
> 	// In header file
> 	extern int counter_private;	// Do not use!
> 	#define counter ((const int) counter_private)

Note that the const in the cast is probably useful as documentation, but
it's not really necessary, since a cast expression is not an lvalue.

You could also have:

    #define counter (+counter_private)

[...]

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

#103482

On Wednesday, February 8, 2017 at 11:27:34 AM UTC-6, Keith Thompson wrote:
> Note that the const in the cast is probably useful as documentation, but
> it's not really necessary, since a cast expression is not an lvalue.
> 
> You could also have:
> 
>     #define counter (+counter_private)

I would think something like "#define counter (*(int const*)&counter_private)"
would be better, since it would allow counter_private to be used in contexts
where an lvalue is required (e.g. "memcpy(xx, &counter, sizeof counter);")
while preventing code from assigning to it.  I don't think that form of cast
should cause any aliasing problems.

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

#103489

supercat@casperkitty.com writes:

> On Wednesday, February 8, 2017 at 11:27:34 AM UTC-6, Keith Thompson wrote:
>> Note that the const in the cast is probably useful as documentation, but
>> it's not really necessary, since a cast expression is not an lvalue.
>> 
>> You could also have:
>> 
>>     #define counter (+counter_private)
>
> I would think something like "#define counter (*(int const*)&counter_private)"
> would be better, since it would allow counter_private to be used in contexts
> where an lvalue is required (e.g. "memcpy(xx, &counter, sizeof counter);")
> while preventing code from assigning to it.  I don't think that form of cast
> should cause any aliasing problems.

A compound literal is neater:

  #define counter ((const int){counter_private})

-- 
Ben.

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

#103490

On Wednesday, February 8, 2017 at 3:06:20 PM UTC-6, Ben Bacarisse wrote:
> A compound literal is neater:
> 
>   #define counter ((const int){counter_private})

Given the code:

    outside_function1(&counter);
    outside_function2(&counter);
    outside_function3(&counter);

a compiler would be required to create three different storage locations
which copy the values of counter_private at different times.  If the calls
to outside_function1 and outside_function2 were to save the passed-in
pointers to places that were accessible to outside_function3 and then
change the value of counter_private, then the call to outside_function3
should be able to look at the passed-in pointer from that call as well as
the two earlier ones and see three different values.  Consequently, a
compiler which can't see into the outside functions would have no choice but
to create three different storage locations and copy counter_private into
each one at a different time.

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

#103491

supercat@casperkitty.com writes:

> On Wednesday, February 8, 2017 at 3:06:20 PM UTC-6, Ben Bacarisse wrote:
>> A compound literal is neater:
>> 
>>   #define counter ((const int){counter_private})
>
> Given the code:
>
>     outside_function1(&counter);
>     outside_function2(&counter);
>     outside_function3(&counter);
>
> a compiler would be required to create three different storage locations
> which copy the values of counter_private at different times.

That's partly why it's neater, yes.

<snip>
-- 
Ben.

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

#103492

On Wednesday, February 8, 2017 at 3:40:27 PM UTC-6, Ben Bacarisse wrote:
> supercat writes:
> 
> > On Wednesday, February 8, 2017 at 3:06:20 PM UTC-6, Ben Bacarisse wrote:
> >> A compound literal is neater:
> >> 
> >>   #define counter ((const int){counter_private})
> >
> > Given the code:
> >
> >     outside_function1(&counter);
> >     outside_function2(&counter);
> >     outside_function3(&counter);
> >
> > a compiler would be required to create three different storage locations
> > which copy the values of counter_private at different times.
> 
> That's partly why it's neater, yes.

Do you see the extra copying as a good thing?  Or are you being sarcastic,
or self-effacing, or what?

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

#103499

supercat@casperkitty.com writes:

> On Wednesday, February 8, 2017 at 3:40:27 PM UTC-6, Ben Bacarisse wrote:
>> supercat writes:
>> 
>> > On Wednesday, February 8, 2017 at 3:06:20 PM UTC-6, Ben Bacarisse wrote:
>> >> A compound literal is neater:
>> >> 
>> >>   #define counter ((const int){counter_private})
>> >
>> > Given the code:
>> >
>> >     outside_function1(&counter);
>> >     outside_function2(&counter);
>> >     outside_function3(&counter);
>> >
>> > a compiler would be required to create three different storage locations
>> > which copy the values of counter_private at different times.
>> 
>> That's partly why it's neater, yes.
>
> Do you see the extra copying as a good thing?

Yes, in the sense that it's consequences are good.  If a compiler can,
in some circumstances, avoid it, great, but it prevents anyone using a
cast to alter the actual counter.

<snip>
-- 
Ben.

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

#103496

On 08/02/17 22:20, supercat@casperkitty.com wrote:
> On Wednesday, February 8, 2017 at 3:06:20 PM UTC-6, Ben Bacarisse wrote:
>> A compound literal is neater:
>>
>>   #define counter ((const int){counter_private})
>
> Given the code:
>
>     outside_function1(&counter);
>     outside_function2(&counter);
>     outside_function3(&counter);
>
> a compiler would be required to create three different storage locations
> which copy the values of counter_private at different times.  If the calls
> to outside_function1 and outside_function2 were to save the passed-in
> pointers to places that were accessible to outside_function3 and then
> change the value of counter_private, then the call to outside_function3
> should be able to look at the passed-in pointer from that call as well as
> the two earlier ones and see three different values.  Consequently, a
> compiler which can't see into the outside functions would have no choice but
> to create three different storage locations and copy counter_private into
> each one at a different time.
>

If this was the kind of variable that I'd be likely to pass around using 
a pointer or address, I would be unlikely to to be doing this macro 
stuff - I'd just use a const-pointer-to-const in the first place.

[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