twitter: comp.lang.c - 25 new messages in 8 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Container library (continued) - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* Letter sent to Apress with concerns about Peter Seebach's online behavior -
3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 7
messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* a hunk of not-very-portable code I've been working on - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/24988ee765b75811?hl=en
* Casting function pointers - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ecaa51ff82b04d33?hl=en
* Is allocating large objects on the stack a good practice? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
* Idiotic programming style edicts - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* c99 multidimensional arrays contiguous? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en

==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Mar 17 2010 9:50 am
From: Seebs

On 2010-03-17, jacob navia <jacob@spamsink.net> wrote:
> Seebs a �crit :
>> I honestly don't think that generalizing to "container" is going to be
>> useful in C. In a language that doesn't have meaningful inheritance,
>> it's very unusual for this kind of approach to get widespread adoption.

> I do not know of any other attempt in C.

I don't know of another generalization to container in C. I know of
many lists and vectors and the like.

> Inheritance is not necessary at all. The code works without it.

But without inheritance, "container" is not a useful level of abstraction.

The thing that makes "container" useful is that it provides for commonality
between "list" and "hash". But that's only useful when list and hash are
the types you actually work with, but because of inheritance, you can treat
them both as containers.

Without inheritance, either you have to call things "container" regardless
of which they are, and thus have access to an API that only makes sense for
a list when you're using a hash, and an API that only makes sense for a hash
when you're using a list, or you lose the ability to write a function which
just takes a "container".

I have often used list libraries. I'd use hash libraries if I needed a hash.
In neither case would I use a "container" library in C -- it's the wrong
level of abstraction for C, so far as I can tell. I've never in any language
wanted "a container". In OO languages, it's useful that the specific things
I request are also generically "containers". In C, it's not useful, because
I can't do anything with it.

== 2 of 7 ==
Date: Wed, Mar 17 2010 10:43 am
From: Andrew Poelstra

On 2010-03-17, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-03-17, jacob navia <jacob@spamsink.net> wrote:
>
>> I do not know of any other attempt in C.
>
> I don't know of another generalization to container in C. I know of
> many lists and vectors and the like.
>
>> Inheritance is not necessary at all. The code works without it.
>
> But without inheritance, "container" is not a useful level of abstraction.
>
> The thing that makes "container" useful is that it provides for commonality
> between "list" and "hash". But that's only useful when list and hash are
> the types you actually work with, but because of inheritance, you can treat
> them both as containers.
>
> Without inheritance, either you have to call things "container" regardless
> of which they are, and thus have access to an API that only makes sense for
> a list when you're using a hash, and an API that only makes sense for a hash
> when you're using a list, or you lose the ability to write a function which
> just takes a "container".
>
> I have often used list libraries. I'd use hash libraries if I needed a hash.
> In neither case would I use a "container" library in C -- it's the wrong
> level of abstraction for C, so far as I can tell. I've never in any language
> wanted "a container". In OO languages, it's useful that the specific things
> I request are also generically "containers". In C, it's not useful, because
> I can't do anything with it.
>

You can do OO in C. I think most people don't because they have
it drilled into their heads that "C is not an object-oriented"
language. Which to be fair, it isn't, but that doesn't mean that
there are reasonably-elegant[1] ways to do OO.

What Jacob has described doing (for a couple of projects) is
making the first element of his structs a vptr table, and interally
casting all his containers to this vtpr table, then calling the
appropriate "method" from there.

So that's inheritance. But from the user's perspective, it requires
casting each list/vector/hash/whatever to a Container * before
passing it to a function.

eg.
int data = 5;
List mylist = new_list();
append((Container *) mylist, &data);

Which is kinda ugly, but the cast can be hidden by a macro around
the function, and then you're golden:

#define append(a, b) (append((Container *)a, b)

append(mylist, &data);

I think this is a nice interface, has appropriate data-hiding, and
provides genericity. If he published the vptr structure, it would
also be extensible by other libraries.

[1] And "Reasonably elegent" often means "more elegant than C++"

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 3 of 7 ==
Date: Wed, Mar 17 2010 10:47 am
From: Seebs

On 2010-03-17, Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
> You can do OO in C. I think most people don't because they have
> it drilled into their heads that "C is not an object-oriented"
> language. Which to be fair, it isn't, but that doesn't mean that
> there are reasonably-elegant[1] ways to do OO.

Oh, certainly. I just don't think that it's a good enough fit to reward
the kind of hierarchy the "container" library implies.

> I think this is a nice interface, has appropriate data-hiding, and
> provides genericity. If he published the vptr structure, it would
> also be extensible by other libraries.

True. But I think there's a limit -- every library needs to know what could
be in the vptr structure, and you can't easily add or remove things. I
suppose some kind of type indicator could help.

But at this point, you end up with things that have a fair bit of overhead,
and most of the time when I see lists used in C, they're used directly
so they don't have to pay the overhead of function calls at all, let alone
indirection through function pointers...

> [1] And "Reasonably elegent" often means "more elegant than C++"

== 4 of 7 ==
Date: Wed, Mar 17 2010 10:58 am
From: ImpalerCore

On Mar 16, 7:07 pm, jacob navia <ja...@spamsink.net> wrote:
> Data allocation strategies for containers can vary wildly, depending on
> the specific container and on the application. Environment
> considerations play also a major role: if there is enough RAM many
> things can be handled QUITE differently than when there isn't.
>
> It is impossible to find a strategy that can be always good in all
> situations, so naturally, we need an object with (roughly) 3 function
> pointers:
>
> (1) MALLOC
> (2) FREE
> (3) REALLOC
>
> This table of functions will be used by a container for
> allocating/releasing memory. It will default to the standard C
> functions, but can be changed so that a GC is used, for instance. In
> that case we would have
>
> MALLOC --> GC_malloc
> FREE --> no operation
> REALLOC --> GC_realloc.
>
> Now, should this object be a global part of the library, i.e. a single
> allocation object for the whole library, or should each container class
> (hash tables, lists, dictionaries) have one, or should each individual
> container have one?
>
> If we have a single global object, changing the behavior of our
> containers is very easy, we have a single object to change and we are
> done. Obviously, this is VERY global and forces the user to have always
> the same allocation strategy for all containers.
>
> If we have a per class of container design, we have more flexibility, we
> could use the GC for hash tables but not for lists, etc. The price to
> pay is increased difficulty to change the behavior of all objects... To
> change from the default object to the GC, for instance, we would have to
> go through all container classes. True, the library could provide a
> function to do that, but if we add a container we would have to modify
> that function again and again.
>
> If we have an allocation object per individual container we have the
> maximum flexibility but changing the allocation strategy becomes QUITE
> complicated.
>
> Personally, I think that is easier to understand the first option:
> having a single object that allocates/frees memory. It is rare that we
> would want to use a GC, say, and at the same time malloc/free at the
> same time.
>
> Obviously I am not sure, hence this message. What do you think?
>
> jacob

One option is to just use malloc, wait for user complaints and see
what areas in performance they are complaining about and address
them. If the interface is easy enough to use and there are enough
examples to lead them in how to use your library, there will be
interest in improving the performance issues, which can be argued and
fleshed out as a community.

I simply use malloc for my stuff since I have a very small frame of
reference (just myself) for my container code and it works for me.
I'd release it that way if I decided to jump in the pool, as I
personally would like to get a broader user experience (if anyone
would be willing to use it) to make an more informed decision between
the trade-offs of complexity and efficiency before making that kind of
choice (and hopefully you'd have a following of willing test subjects
to try out your changes in "real world" applications).

Again, you likely have a more robust background in this stuff than I.
I've never used a garbage collector in C or even C++, and haven't been
pushed to the point where efficiency was that critical to require
writing special allocators. All I've done is create a wrapper that
allows me to inject faults after specified number of malloc, calloc,
or realloc function calls to test my internal container allocation
error handling.

I don't intend this to discourage the allocator discussion at all, but
just to point out that if I'm not using the library, I have no vantage
point to make any informed suggestion. While I think that the
semantics of memory allocation is important, I just feel it's not
important to a library that no one is committed to using *yet*.

Best regards,
John D.

== 5 of 7 ==
Date: Wed, Mar 17 2010 11:24 am
From: ImpalerCore

On Mar 17, 1:47 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-17, Andrew Poelstra <apoels...@localhost.localdomain> wrote:
>
> > You can do OO in C. I think most people don't because they have
> > it drilled into their heads that "C is not an object-oriented"
> > language. Which to be fair, it isn't, but that doesn't mean that
> > there are reasonably-elegant[1] ways to do OO.
>
> Oh, certainly. I just don't think that it's a good enough fit to reward
> the kind of hierarchy the "container" library implies.
>
> > I think this is a nice interface, has appropriate data-hiding, and
> > provides genericity. If he published the vptr structure, it would
> > also be extensible by other libraries.
>
> True. But I think there's a limit -- every library needs to know what could
> be in the vptr structure, and you can't easily add or remove things. I
> suppose some kind of type indicator could help.
>
> But at this point, you end up with things that have a fair bit of overhead,
> and most of the time when I see lists used in C, they're used directly
> so they don't have to pay the overhead of function calls at all, let alone
> indirection through function pointers...

Imo, there's probably a few people willing to allow the overhead if

1. It's easy to use correctly.
2. Rolling their own version is significantly more difficult and
expensive.
3. It's free.
4. The performance overhead is not detrimental to the application.

For example, I would gladly use a correct but slowish hash-table to
build a working demo of an application just to verify the proof of
concept. At the very least, it would allow developers to prototype a
design faster and fine tune with more type-specific/efficient data
structures if need be.

Best regards,
John D.

> > [1] And "Reasonably elegent" often means "more elegant than C++"
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 6 of 7 ==
Date: Wed, Mar 17 2010 11:48 am
From: Ian Collins

On 03/18/10 05:50 AM, Seebs wrote:
> On 2010-03-17, jacob navia<jacob@spamsink.net> wrote:
>> Seebs a écrit :
>>> I honestly don't think that generalizing to "container" is going to be
>>> useful in C. In a language that doesn't have meaningful inheritance,
>>> it's very unusual for this kind of approach to get widespread adoption.
>
>> I do not know of any other attempt in C.
>
> I don't know of another generalization to container in C. I know of
> many lists and vectors and the like.
>
>> Inheritance is not necessary at all. The code works without it.
>
> But without inheritance, "container" is not a useful level of abstraction.

I don't think it's inheritance that makes "container" a useful level of
abstraction. The most important language feature for containers is
support for generics. For example, the containers part of the C++
standard library makes very little use of inheritance but relies heavily
on templates (hence the old name of standard template library).

> The thing that makes "container" useful is that it provides for commonality
> between "list" and "hash". But that's only useful when list and hash are
> the types you actually work with, but because of inheritance, you can treat
> them both as containers.

Or because of generics support.

> Without inheritance, either you have to call things "container" regardless
> of which they are, and thus have access to an API that only makes sense for
> a list when you're using a hash, and an API that only makes sense for a hash
> when you're using a list, or you lose the ability to write a function which
> just takes a "container".

Again, generics enables you to use the common subset of container
interfaces.

So the interface can be done in C, just not very cleanly.

--
Ian Collins

== 7 of 7 ==
Date: Wed, Mar 17 2010 11:51 am
From: Ian Collins

On 03/17/10 12:07 PM, jacob navia wrote:
> Data allocation strategies for containers can vary wildly, depending on
> the specific container and on the application. Environment
> considerations play also a major role: if there is enough RAM many
> things can be handled QUITE differently than when there isn't.
>
> It is impossible to find a strategy that can be always good in all
> situations, so naturally, we need an object with (roughly) 3 function
> pointers:
>
> (1) MALLOC
> (2) FREE
> (3) REALLOC
>
> This table of functions will be used by a container for
> allocating/releasing memory. It will default to the standard C
> functions, but can be changed so that a GC is used, for instance. In
> that case we would have
>
> MALLOC --> GC_malloc
> FREE --> no operation
> REALLOC --> GC_realloc.
>
> Now, should this object be a global part of the library, i.e. a single
> allocation object for the whole library, or should each container class
> (hash tables, lists, dictionaries) have one, or should each individual
> container have one?

If possible, provide both. That's the was C++ does it and it works
well. It's uncommon to provide a specific allocator to a container
instance, but when this is required, it is very useful.

--
Ian Collins

==============================================================================
TOPIC: Letter sent to Apress with concerns about Peter Seebach's online
behavior
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 17 2010 9:53 am
From: Lubow

On Mar 17, 12:30 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
>

Kindly stop X-posting in misc.invest.stocks.

Thank you.

== 2 of 3 ==
Date: Wed, Mar 17 2010 1:10 pm
From: Lubow

On Mar 16, 2:56 pm, Chad <cdal...@gmail.com> wrote:

>
> The person that wrote the early *nix versions of Netscape, XEmacs,
> XScreensavers, and Mozilla only had a high school diploma. His "email
> algorithm" is used in alot of the modern email clients. In an old
> interview, he told the person interviewing him that he almost
> considered dropping out of high school in the 11th grade because
> school just wasn't working out for him.

Did that guy also murder his wife?

http://tinyurl.com/v5sez

== 3 of 3 ==
Date: Wed, Mar 17 2010 1:24 pm
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <17152fb7-aaf9-4da7-8483-3b91edde830c@g26g2000yqn.googlegroups.com>,
Lubow <dynamitemike@hotmail.com> wrote:
>On Mar 16, 2:56�pm, Chad <cdal...@gmail.com> wrote:
>
>>
>> The person that wrote the early *nix versions of Netscape, XEmacs,
>> XScreensavers, and Mozilla only had a high school diploma. His "email
>> algorithm" is used in alot of the modern email clients. �In an old
>> interview, he told the person interviewing him that he almost
>> considered dropping out of high school in the 11th grade because
>> school just wasn't working out for him.

The point that we are trying to make here is that those days are gone.
Programming has become, as spinoza puts it, overly-socialized. The
maverick days are over.

The denizens of this NG want to go on pretending that this isn't so.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Mar 17 2010 10:02 am
From: Seebs

On 2010-03-17, James Kuyper <jameskuyper@verizon.net> wrote:
> What function would you recommend I use to prepare the output buffer for
> fwrite(), other than strncpy()?

Okay, I am convinced. There does still exist a use for strncpy. And a
pretty well considered one.

What it isn't, though, is a "safe replacement for strcpy". :) By contrast,
strlcpy sort of is. (Not totally, but enough better that I'd use it by
preference if it were in the spec.)

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 7 ==
Date: Wed, Mar 17 2010 10:03 am
From: Richard Delorme

Le 16/03/2010 20:10, Keith Thompson a écrit :

> In your hypothetical C without "function forward declarations", how
> would this work? How would the compiler figure out that square()
> takes a float argument and returns a float result?
>
> I'm not saying it can't be done. I'm asking how you suggest doing it.

The problem is for the compiler to know the type of a function without
asking the programmer to explicitly write a function declaration. If the
function is defined in the same compilation unit I guess there is no
much problem. When using several compilation units, we need to tell the
compiler on how to find the information by itself. We can imagine
several ways to achieve this:
- In the source file, use a new instruction that indicates where to
find the function type. For example:

#interface "square.c"

int main()
{
/*... code using the function square... */
}

So #interface will open the square.c file and decipher the function type
from its definition.

- In the command line invoking the compiler, we can tell the compiler
to seek for function type in a file through a command line option.
Similar to the -llibrary_name used during linkage, we can use a
-ifile_name telling the compiler where to find the information.

- We can let the compiler doing all the work by itself. It means
delaying part of the compilation during the linkage, once all
information has been gathered.

- We can also introduce the notion of project, which is a set of
source files & libraries necessary to build an application (or a
library). One of the first step for the compiler will be to read all the
file of the project to build an interface file (a kind of precompiled
header) usable by all the file of the project.

So there are many way to accomplish such a task. The only important
things, IMHO, is to facilitate the task of the programmer (the language
user) whatever the consequence for the complexity of the compiler could be.

--
Richard
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 3 of 7 ==
Date: Wed, Mar 17 2010 10:44 am
From: Keith Thompson

Richard Delorme <abulmo@nospam.fr> writes:
> Le 16/03/2010 20:10, Keith Thompson a écrit :
>> In your hypothetical C without "function forward declarations", how
>> would this work? How would the compiler figure out that square()
>> takes a float argument and returns a float result?
>>
>> I'm not saying it can't be done. I'm asking how you suggest doing it.
>
> The problem is for the compiler to know the type of a function without
> asking the programmer to explicitly write a function declaration. If
> the function is defined in the same compilation unit I guess there is
> no much problem. When using several compilation units, we need to tell
> the compiler on how to find the information by itself. We can imagine
> several ways to achieve this:
> - In the source file, use a new instruction that indicates where to
> find the function type. For example:
>
> #interface "square.c"
>
> int main()
> {
> /*... code using the function square... */
> }
>
> So #interface will open the square.c file and decipher the function
> type from its definition.

Currently, I can have a file "square.c" that defines a number
of functions, and another file "square.h" that provides visible
declarations for *some* of them. Given your #interface proposal,
how do I specify that some functions in "square.c" are intended to
be used by client code, and some are internal?

Is #interface supposed to replace #include? If so, what about
declarations for things other than functions (constants, typedefs,
etc.)?

> - In the command line invoking the compiler, we can tell the compiler
> to seek for function type in a file through a command line
> option. Similar to the -llibrary_name used during linkage, we can use
> a -ifile_name telling the compiler where to find the information.

Ok, though this means that some of the information about the program
is in the compiler command line rather than in the source, with a
syntax that can vary wildly from one compiler to another. Admittedly
this is already somewhat true for existing options that specify
libraries.

> - We can let the compiler doing all the work by itself. It means
> delaying part of the compilation during the linkage, once all
> information has been gathered.

If I call square(), how does the compiler know where to find it?

> - We can also introduce the notion of project, which is a set of
> source files & libraries necessary to build an application (or a
> library). One of the first step for the compiler will be to read all
> the file of the project to build an interface file (a kind of
> precompiled header) usable by all the file of the project.

Do you propose imposing this on all implementations?

> So there are many way to accomplish such a task. The only important
> things, IMHO, is to facilitate the task of the programmer (the
> language user) whatever the consequence for the complexity of the
> compiler could be.

All this to avoid having to write a function declaration? I thought
you were trying to simplify things.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 4 of 7 ==
Date: Wed, Mar 17 2010 11:15 am
From: Willem

Keith Thompson wrote:
) Currently, I can have a file "square.c" that defines a number
) of functions, and another file "square.h" that provides visible
) declarations for *some* of them. Given your #interface proposal,
) how do I specify that some functions in "square.c" are intended to
) be used by client code, and some are internal?

Err... You could use the 'static' keyword ?

) Is #interface supposed to replace #include? If so, what about
) declarations for things other than functions (constants, typedefs,
) etc.)?

It could pick up all constants, typedefs, variables and macros that
are not declared 'static' ?

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 5 of 7 ==
Date: Wed, Mar 17 2010 1:16 pm
From: "bartc"

Keith Thompson wrote:
> Richard Delorme <abulmo@nospam.fr> writes:

>> When using several compilation
>> units, we need to tell the compiler on how to find the information
>> by itself. We can imagine several ways to achieve this:
>> - In the source file, use a new instruction that indicates where to
>> find the function type. For example:
>>
>> #interface "square.c"
>>
>> int main()
>> {
>> /*... code using the function square... */
>> }
>>
>> So #interface will open the square.c file and decipher the function
>> type from its definition.
>
> Currently, I can have a file "square.c" that defines a number
> of functions, and another file "square.h" that provides visible
> declarations for *some* of them. Given your #interface proposal,
> how do I specify that some functions in "square.c" are intended to
> be used by client code, and some are internal?

Global and Private attributes in square.c?

Anyway aren't all functions in square.c currently already Global?

> Is #interface supposed to replace #include?

I would keep both. #include just imports some text. #interface might be
higher level than that (and may not need the #), or it might just #include
some automatically created header.

> If so, what about
> declarations for things other than functions (constants, typedefs,
> etc.)?

Why not? For typedefs, structs, enums and variables, the definition is just
duplicated (although variable initialisers don't need to be). These entities
are generally defined in one place (a shared header), but if the mechanism
is there to this automatically, why not use it.

#defines might be a problem however: how do you apply a global attribute to
something which is just a preprocessor artifact? (This highlights why C
could do with a 'cleanup'.)

>> - In the command line invoking the compiler, we can tell the
>> compiler to seek for function type in a file through a command line
>> option. Similar to the -llibrary_name used during linkage, we can use
>> a -ifile_name telling the compiler where to find the information.
>
> Ok, though this means that some of the information about the program
> is in the compiler command line rather than in the source, with a
> syntax that can vary wildly from one compiler to another. Admittedly
> this is already somewhat true for existing options that specify
> libraries.

Apparently some applications are already quite fragile if the exact
compiler/linker options are not used.

>> So there are many way to accomplish such a task. The only important
>> things, IMHO, is to facilitate the task of the programmer (the
>> language user) whatever the consequence for the complexity of the
>> compiler could be.
>
> All this to avoid having to write a function declaration? I thought
> you were trying to simplify things.

No, to avoid writing, and maintaining identical twin versions of, a hundred
declarations, at a cost of specifying one import or interface module.

If you wanted to extend square.c, just define a new function and declare as
global or exported. Then it will be instantly available to all modules that
make use of square.c.

However it you change a function signature in square.c, it may not be as
obvious then you need to recompile everything, as it might with square.h.

--
Bartc

== 6 of 7 ==
Date: Wed, Mar 17 2010 3:01 pm
From: Richard Delorme

Le 17/03/2010 18:44, Keith Thompson a écrit :
> Richard Delorme<abulmo@nospam.fr> writes:

> All this to avoid having to write a function declaration? I thought
> you were trying to simplify things.

From the programmer point of view this is a simplification. What I
would appreciate, is to transfer some complexity from the programmer to
the compiler. This is exactly the opposite of what restrict is doing in
current implementations.

== 7 of 7 ==
Date: Wed, Mar 17 2010 3:01 pm
From: Richard Delorme

Le 17/03/2010 19:15, Willem a écrit :
> Keith Thompson wrote:
> ) Currently, I can have a file "square.c" that defines a number
> ) of functions, and another file "square.h" that provides visible
> ) declarations for *some* of them. Given your #interface proposal,
> ) how do I specify that some functions in "square.c" are intended to
> ) be used by client code, and some are internal?
>
> Err... You could use the 'static' keyword ?
>
> ) Is #interface supposed to replace #include? If so, what about
> ) declarations for things other than functions (constants, typedefs,
> ) etc.)?
>
> It could pick up all constants, typedefs, variables and macros that
> are not declared 'static' ?

Yes, this is exactly my opinion.

==============================================================================
TOPIC: a hunk of not-very-portable code I've been working on
http://groups.google.com/group/comp.lang.c/t/24988ee765b75811?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 10:05 am
From: Moi

On Wed, 17 Mar 2010 04:24:20 +0100, Ersek, Laszlo wrote:

> In article <slrnhq09ph.rpp.usenet-nospam@guild.seebs.net>, Seebs
> <usenet-nospam@seebs.net> writes:
>
>> http://github.com/wrpseudo/pseudo
>
> LGPL, wow, very generous!
>
>
>> Comments and feedback welcome, whether here or elsewhere. Obviously,
>> comments specific to the dynamic linker magic, filesystem code, and
>> such are probably better sent via email or posted as comments on the
>> github page, but I'd be happy to answer questions about the C aspects
>> of this, whether it's "how did you think of this" or "what the hell
>> were you thinking". Bug reports are also quite welcome.
>
> I hate to be that guy, but... :) pseudo_server.c, lines 131-133:
>
> pseudo_path = pseudo_prefix_path(PSEUDO_PIDFILE); fp =
> fopen(pseudo_path, "w");
> fprintf(fp, "%d\n", getpid());
>

More or less the same thing with getsizes:

printf("ThingyMember: %d\n" , offsetof(struct message, member));
printf("Whole Thing: %d\n" , sizeof(struct message));

-->> either %z or %u and cast to unsigned, or just cast to int.

AvK

==============================================================================
TOPIC: Casting function pointers
http://groups.google.com/group/comp.lang.c/t/ecaa51ff82b04d33?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 10:10 am
From: ImpalerCore

On Mar 17, 8:14 am, chrisbaz...@bigfoot.com wrote:
> On Mar 16, 4:52 pm, ImpalerCore <jadil...@gmail.com> wrote:
>
> > On Mar 15, 8:30 pm, chrisbaz...@bigfoot.com wrote:
> [snip]
> > > Surely this is slower and inflates the code size - especially if the
> > > compiler embeds function names and sets up a stack frame in the
> > > wrapper function. What advantage does it have over simply using the
> > > (strongly-typed) 'mstr' pointer within the my_string_vfree() function?
>
> > The C-FAQ recommends against casting because the result of the cast is
> > not guaranteed. The compiler may implement the "right" behavior, but
> > you do so at your own risk. This is assuming that you are intending
> > the dictionary to use the generic 'void (*)( void* )' as the free
> > interface function pointer type.
>
> Yes, I understood that point and found it interesting, because I
> hadn't previously considered the validity of casting function
> pointers.
>
> > The C-FAQ didn't recommend the option that I gave specifically, it was
> > my recommendation, based on my personal experience designing
> > containers. There are a couple other options that I considered.
>
> Okay, I went and looked at the FAQ and thought maybe I had missed it
> or I was looking in the wrong place.
>
> > 1. Just create a my_string_free with a void* parameter.
>
> > void my_string_free( void* mstr );
>
> > The risk is that if you pass in a pointer to a different type, bad
> > things can happen and the compiler will likely not warn you about it.
>
> As Eric said, 'That's The Way It Is in a language that doesn't have
> "generic types."'.
>
> > Not every string free will be a string in a container, so I want the
> > compiler to catch those errors.
>
> I agree, type-safety is very important.
>
> [snip]
>
> > 2. Create two separate functions, with nearly identical code.
> [snip]
> > In this scenario, you duplicate the code trading the performance
> > penalty of nesting a function within another with the cost of
> > maintaining two nearly identical pieces of code.
>
> I would never countenance that option. :-)
>
> > 3. The scenario I suggested used a nested call to avoid the
> > maintenance cost since it is likely that the overall gain in
> > performance is not worth having to maintain two separate copies of the
> > code.
>
> I would probably grimace and do likewise, but ONLY if the destructor
> were likely to be called in some other circumstance where type-safety
> could be enforced. I assumed that it had been written for the specific
> purpose of being called through a weakly-typed function pointer (which
> is why I couldn't see any point in your wrapper function).

I had originally just used a function pointer cast till I stumbled
across that C FAQ myself. I don't particularly like the solution, but
it's the one that plays the nicest imo.

> Cheers,
> --
> Christopher Bazley

==============================================================================
TOPIC: Is allocating large objects on the stack a good practice?
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 10:28 am
From: red floyd

On Mar 17, 5:22 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 3/17/2010 7:53 AM, chrisbaz...@bigfoot.com wrote:
>
>
>
> > On Mar 17, 9:37 am, Nick Keighley<nick_keighley_nos...@hotmail.com>
> > wrote:
> >> On 16 Mar, 15:31, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> >>> Additionally,
> >>> res_construct() can participate in an even-higher level _init() routine.
>
> >> isn't _init() in a reserved namespace? Or close to one anyway.
>
> > On Mar 17, 9:37 am, Nick Keighley<nick_keighley_nos...@hotmail.com>
> > wrote:
> >> On 16 Mar, 15:31, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> >>> Additionally,
> >>> res_construct() can participate in an even-higher level _init() routine.
>
> >> isn't _init() in a reserved namespace? Or close to one anyway.
>
> > No, I'm pretty sure that identifiers starting with an underscore are
> > only reserved if the following letter is another underscore or a
> > capital letter.
>
> For C, "All identifiers that begin with an underscore are
> always reserved for use as identifiers with file scope in both
> the ordinary and tag name spaces." (7.1.3p1). So you could use
> `_init' inside a function, but not as a name for anything outside
> a function. In particular, since "a higher-level routine" would
> necessarily be a file-scope entity, naming it _init would encroach
> on reserved space.
>
> I don't know whether C++ rules are the same.
>

17.4.3.1.2/1
-- Each name that contains a double underscore (__) or begins with an
underscore followed by an uppercase letter is reserved to the
implementation for any use.

-- Each name that begins with an underscore is reserved to the
implementation
for use as a name in the global namespace.

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 17 2010 10:51 am
From: Eric Chomko

On Mar 17, 9:33 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 17 Mar 2010 07:03:43 -0500
>
> jmfbahciv <jmfbahciv@aol> wrote:
> > Jonathan de Boyne Pollard wrote:
> > > Such edicts make one want to write code in the form
>
> > > x /* The variable x */
> > > = /* is assigned */
> > > x /* its value * /
> > > + /* plus * /
> > > 2 /* one */
> > > ; /* . */
>
> > And would make all tapes spill over to two magtapes.
>
> > Fortunately, your code would produce many detected errors.
>
> Nope that's perfectly valid C code - provided that x is declared in
> scope.
>

Isn't "in scope" redundant here? I mean scope only applies to binding
time, no? Locals vs. globals vs. non-locals which are not global,
etc. But I agree the code is fine from the stand point of the
compiler.

== 2 of 3 ==
Date: Wed, Mar 17 2010 11:50 am
From: Keith Thompson

Eric Chomko <pne.chomko@comcast.net> writes:
> On Mar 17, 9:33 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> On Wed, 17 Mar 2010 07:03:43 -0500
>>
>> jmfbahciv <jmfbahciv@aol> wrote:
>> > Jonathan de Boyne Pollard wrote:
>> > > Such edicts make one want to write code in the form
>>
>> > > x /* The variable x */
>> > > = /* is assigned */
>> > > x /* its value * /
>> > > + /* plus * /
>> > > 2 /* one */
>> > > ; /* . */
>>
>> > And would make all tapes spill over to two magtapes.
>>
>> > Fortunately, your code would produce many detected errors.
>>
>> Nope that's perfectly valid C code - provided that x is declared in
>> scope.
>>
>
> Isn't "in scope" redundant here? I mean scope only applies to binding
> time, no? Locals vs. globals vs. non-locals which are not global,
> etc. But I agree the code is fine from the stand point of the
> compiler.

Agreed. But note that the "its value" and "plus" comments aren't
properly terminated, so the "/*" on the "its value" line introduces a
comment that isn't terminated until the "*/" on the "one" line.
The net result is "x = x;"

== 3 of 3 ==
Date: Wed, Mar 17 2010 11:58 am
From: scott@slp53.sl.home (Scott Lurndal)

Eric Chomko <pne.chomko@comcast.net> writes:
>On Mar 17, 9:33=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> On Wed, 17 Mar 2010 07:03:43 -0500
>>
>> jmfbahciv <jmfbahciv@aol> wrote:
>> > Jonathan de Boyne Pollard wrote:
>> > > Such edicts make one want to write code in the form
>>
>> > > =A0 =A0 x =A0/* The variable x */
>> > > =A0 =A0 =3D =A0/* is assigned */
>> > > =A0 =A0 x =A0/* its value * /
>> > > =A0 =A0 + =A0/* plus * /
>> > > =A0 =A0 2 =A0/* one */
>> > > =A0 =A0 ; =A0 /* . */
>>
>> > And would make all tapes spill over to two magtapes.
>>
>> > Fortunately, your code would produce many detected errors.
>>
>> =A0 =A0 =A0 =A0 Nope that's perfectly valid C code - provided that x is d=
>eclared in
>> scope.
>>
>
>Isn't "in scope" redundant here? I mean scope only applies to binding
>time, no? Locals vs. globals vs. non-locals which are not global,
>etc. But I agree the code is fine from the stand point of the
>compiler.

except for the two occurances of '* /' instead of '*/'.

scott

==============================================================================
TOPIC: c99 multidimensional arrays contiguous?
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 17 2010 12:37 pm
From: "Johannes Schaub (litb)"

Seebs wrote:

> On 2010-03-16, pemo <peet.morris@gmail.com> wrote:
>> Maybe this was in a nightmare, but I seem to remember reading
>> something that said in C99 multidimensional arrays *need not* be laid
>> out contiguously in memory, i.e., that one should not treat them as a
>> single contiguous blob of memory!
>
>> Was this just a bad dream of mine please??
>
> Sorta yes, sorta no.
>
> 1. They must indeed be laid out contiguously in memory.
> 2. If you derive a pointer from one of the sub-arrays, you should not
> then try to derive pointers outside that sub-array from it.
>
> So:
>
> int a[10][10];
> int *p = &a[0][0];
> p = (int *) a;
> p[11] = 0; /* fine, writes to the 12th of 100 members */
> p = &a[0][0];
> p[11] = 0; /* bad, oversteps boundaries of a[0] */
>
> -s

I must be completely blind, but aren't both cases exactly the same? In fact,
the first may be worse since the cast may yield a different address (int(*)
[10] -> int* - the standard doesn't require the pointer value resulting from
the cast to stay the same, i think). And if it stays the same, it looks like
it does completely the same as the second case: Both are undefined behavior
in C.

What do you say is different here?

== 2 of 2 ==
Date: Wed, Mar 17 2010 3:01 pm
From: Seebs

On 2010-03-17, Johannes Schaub (litb) <schaub-johannes@web.de> wrote:
> Seebs wrote:
>> int a[10][10];
>> int *p = &a[0][0];

(the initializer here is irrelevant).

>> p = (int *) a;
>> p[11] = 0; /* fine, writes to the 12th of 100 members */
>> p = &a[0][0];
>> p[11] = 0; /* bad, oversteps boundaries of a[0] */

> I must be completely blind, but aren't both cases exactly the same?

No.

In one, p is being derived from the address of an object known to contain
at least 100*sizeof(int) bytes of storage, in the other, it's being derived
from the address of an object known to contain at least 10*sizeof(int) bytes
of storage.

> In fact,
> the first may be worse since the cast may yield a different address (int(*)
> [10] -> int* - the standard doesn't require the pointer value resulting from
> the cast to stay the same, i think).

It does. Pointers to the first member of an aggregate must compare equal.

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (including a pointer to an
object and a subobject at its beginning) or function, both are
pointers to one past the last element of the same array object, or
one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space.)

> And if it stays the same, it looks like
> it does completely the same as the second case: Both are undefined behavior
> in C.

I don't think so.

> What do you say is different here?

a is an array of 10 arrays of ints. The integers in each array are
necessarily contiguous, and the arrays are necessarily contiguous, so
it's going to point to a region containing 100 integers. If you derive
a pointer from a, it is a pointer into that whole object.

However, each of the sub-objects (a[0], a[1], etcetera) is also an object,
so if you derive a pointer from a[0], it is a pointer only into that
subobject.

The only way they can be in any way different is bounds checking; as
noted above, the standard does guarantee that &(a[0][10]) == &(a[1][0]).

But two pointers can be equal, and not be fully interchangeable, in that
they can have different bounds.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, March 17, 2010

comp.lang.c - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts