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

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

comp.lang.c@googlegroups.com

Today's topics:

* Has thought been given given to a cleaned up C? Possibly called C+. - 14
messages, 9 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* Stylistic questions on UNIX C coding. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* Letter sent to Apress with concerns about Peter Seebach's online behavior -
6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
* Beginner's guide to MinGW? - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e2cff1c3cf36ab5f?hl=en
* Correct way to write a wrapper for C functions that accept/return strings -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a933ecd78edafba1?hl=en
* An interview question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c93105672f793e63?hl=en

==============================================================================
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 14 ==
Date: Wed, Mar 10 2010 11:31 am
From: raltbos@xs4all.nl (Richard Bos)

"bartc" <bartc@freeuk.com> wrote:

> jacob navia wrote:
> > Ben Bacarisse a �crit :
> >> jacob navia <jacob@jacob.remcomp.fr> writes:
> >> <snip>
> >>> I am not convinced of any application of operator overloading that
> >>> is not (1) Done with new numeric types
> >>> (2) Done with access to containers (overloading [ ] )
> >>>
> >>> ALl others, like using + to "add" srings or << or >> to print stuff
> >>> are bad usages in my opinion.
> >>
> >> What about a library for doing symbolic manipulation of expressions
> >> -- for example polynomials. Would you not want to define + as the
> >> operation of addition on polynomials?
> >>
> >
> > In general we should have
> >
> > a+b <--> b+a
> > a*b <--> b*a
>
> What do you have against a-b and a/b?

And against vector multiplication?

Richard

== 2 of 14 ==
Date: Wed, Mar 10 2010 1:39 pm
From: "bartc"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln1vfsm662.fsf@nuthaus.mib.org...
> "bartc" <bartc@freeuk.com> writes:

>> Tidying up of C Language

>> I'm not necessarily providing any fixes here, just pointing out areas
>> that might cause raised eyebrows:
>
> As I'm sure you know, anything that will break existing code,
> particularly that will silently break existing code, has no chance of
> making it into a future C standard.

The OP suggested a new version called "C+" or some such name. That would be
a good opportunity to drop some baggage.

>> Type Declarations
>>
>> These are C's famous convoluted inside-out declarations. I've
>> already suggested a left-to-right alternative (which might just
>> co-exist with the old scheme)
>
> I'm skeptical that such a scheme could actually coexist with the
> current one. I'm even more skeptical that a new scheme could be
> *proven* to be compatible with the current scheme. In the best case,
> there would almost inevitably be cases where a casual reader would
> have difficult figuring out whether a given declaration uses the
> old scheme or the new one, and what it means.

The current syntax looks like this:

T x;

Where T is an existing type (standard or typedefed) and x is a name. And
optionally x can be surrounded by *,[] and () to build on top of T.

The left-to-right type-spec just sits in place of T, and you can still build
on it with *,[] and (), I think even when there is no name, as in a cast
(there might be a couple of loose-ends to do with the ambiguity of *, and ()
when a "function" keyword is not used").

The following would all be equivalent:

int x[10][20];
[20]int x[10];
[10][20]int x;

However this:

[10][20]int x,y;

would be: int x[10][20],y[10][20] in the old syntax.

>> Sizeof Operator

> It's easy enough to write a macro:
>
> #define ARRLEN(arr) (sizeof (arr) / sizeof (arr)[0])

That's fine but it should be built, otherwise everyone will use a slightly
different version.

> On the other hand, it's easy to misuse that by applying it to a
> pointer. Something that can only be applied to array expressions
> could be useful.

This is where a compiler-aware tag would be useful (in another language I
might use x.len, as well as x.upb, x.lwb, which can only be applied to
appropriate types, and x.bytes -- ie. sizeof -- which works on anything).

>> (Such as, perhaps, long.max or signed char'min, which together with
>> a set of standardised short type names would tidy things up
>> considerably.)
>
> Ada, for example, has a number of "attributes" that can be applied
> to various entities: Typename'Size, Object'Size, Typename'First,
> Typename'Last, Array'Length, and so forth. Something like that
> in C could replace sizeof, offsetof, the above ARRLEN macro, and
> probably a number of other things. On the other hand, creeping
> featurism is always dangerous.

These are not really features, just basic requirements I would have thought.
And it is mainly syntax that is easy to implement.

> I don't think the existing switch statement can be removed,
> but a new form of selection statement might be added. (Again,
> this runs into the creeping featurism problem.)

I liked the idea of using "switch!" (either from Ruby, or something I
dreamed up) which doesn't test for a default case, and therefore is faster
when you know the switch index is in range. Another featurette I suppose.

>> For Statement
>>
>> This is a funny, but useful, variation, of a loop statement, but is
>> not a For statement as normally understood. A streamlined 'proper'
>> For statement would be handy (but is awkward to fit into C's zero-
>> based philosophy).
>
> Can you be more specific?

A typical For statement iterates from A to B inclusively, or more often from
1 to N. C however would often need to iterate from 0 to N-1, already losing
some of it's advantage in conciseness.

Unless it were to designed to work from 0 to N-1 anyway, like Python's for i
in range(N):

for (i in 5) printf("%d ",i);

would display 0 1 2 3 4 .

> Something related to this: if I were designing my own language,
> declared objects would be read-only by default. If you want to be
> able to change an object's value after declaring it, you need to
> say so, perhaps with a "var" keyword.

(I do design my own languages; I have tried to have a read-only attribute,
but it's quite fiddly to implement. But I'm not too bothered because it
doesn't it buy you any extra performance (not with my compilers anyway...)
and just introduces more clutter.)

>> _CRTIMP __p_sig_fn_t __cdecl __MINGW_NOTHROW signal(int, __p_sig_fn_t);

>> Whatever it is these attributes are supposed to do, why not just
>> standardise them?
>
> Because many of them are implemention-specific. Though a standard
> syntax for implementation-defined attributes wouldn't be a bad thing;
> is that what you meant? gcc provides some precedent for this.

I mean something where you can guess what the attributes mean. Being able to
port between compilers would be useful too.

(In one of my designs such things might look like:

windows function ....
clang function ...

which are self-explanatory...)

> Hey, you forgot to define a new meaning for "static"!

I didn't have time...

--
Bartc

== 3 of 14 ==
Date: Wed, Mar 10 2010 1:54 pm
From: Ian Collins

On 03/11/10 08:14 AM, Andrew Poelstra wrote:
> On 2010-03-10, Dag-Erling Smørgrav<des@des.no> wrote:
>> Andrew Poelstra<apoelstra@localhost.localdomain> writes:
>>> I think the biggest missing feature of C is namespaces.
>>
>> Agreed, but adding namespaces to the standard would be a lot of work,
>> because there are a lot of corner cases to consider. There is also the
>> issue of preprocessor macros, which can't be coerced into namespaces.
>>
>
> Preprocessor macros would be an unfortunate edge case, but IMHO
> not a fatal one. For function-like macros, you can use the inline
> keyword on a function to get namespaces. For constants, you could
> use an enum.
>
> What other corner cases can you think of?
>
> Feeling C++-ey would be simple enough without any standard library
> changes:
>
> namespace std {
> #include<stdio.h>
> #include<stdlib.h>
> }
>
> And boom, you've got std::malloc() and std::puts() and all that.
>
> Though now that I think about it, using that idea would probably
> cause a fair bit of confusion for linkers.

Unless there was a standard for mangled names in C. Namespaces require
name mangling.

--
Ian Collins
--
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 14 ==
Date: Wed, Mar 10 2010 1:55 pm
From: raltbos@xs4all.nl (Richard Bos)

Walter Banks <walter@bytecraft.com> wrote:

> It is probably too soon to predict the success or not of Google Go.
> http://mashable.com/2009/11/10/go-google-language/

Oh, lord, I hope not. Awful mixture of Java and Python. Here, a quote
from their FAQ, this should tell you everything:

Is Go an object-oriented language?

Yes and no.

Aaaargh! Isn't C++ bad enough?

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.

== 5 of 14 ==
Date: Wed, Mar 10 2010 1:56 pm
From: Thomas Richter

Ian Collins wrote:

>>> The C++ STL appeared fairly early on in that language's evolution and
>>> was rapidly and widely accepted by C++ developers. The widespread use
>>> resulted in it being incorporated into the standard library in first
>>> language standard.
>>>
>>> Why hasn't the same thing happened with C?
>>
>> Because it's the Wrong Thing for C. C isn't a one-purpose language.
>
> Very few languages are, C++ certainly isn't.

The argument goes IMHO into the wrong direction. To make containers
really powerful and safe, you need some kind of generics support, and
some type of mechanism to hide the implementation behind the interface.
C provides only relatively weak measures for that. I afraid the result
would be of rather limited use.

So long,
Thomas
--
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.

== 6 of 14 ==
Date: Wed, Mar 10 2010 1:56 pm
From: Thomas Richter

Flash Gordon wrote:

>> You can write bad code in ANY language.
>
> Yes. However, in C you at least know that + *is* addition.

Actually, it isn't. For floating point, it is a limited precision
version of addition. For integers, it is only addition in a limited
range and behaves undefined outside of that range, and for unsigned, it
is the addition in a ring. (-;

Thus, we have three different versions of addition already, overloaded
on the same symbol, and for constructs that contain two different types
of numbers, the resulting operation is often not easy to follow. Type
promotions in C are a pretty dark chapter, and pretty easy to get wrong
as well.

>>> The thing is though, this thread started by
>> Those are minor incoveniences. Yes, they are bad for newcomers but
>> what is essential is the stuff that is bad for newcomers AND for
>> experienced users.
>
> My experience is that operator overloading leads to confusion for
> experienced users.

In most cases, it should be avoided. The C++ overloading of >> and <<
for IO operations is definitely a pretty bad idea. There are rare cases
where it does make sense because the operator has a very natural meaning
(vector addition, matrix multiplication). It is a feature that should be
used with care. But >> and << for I/O is not one of them.

== 7 of 14 ==
Date: Wed, Mar 10 2010 2:04 pm
From: Dr Malcolm McLean

On 10 Mar, 17:13, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
>
> I'm not sure that the compiler is the biggest concern here. More
> to help out the people reading the code, who might see
>
> a * b + c * a
>
> and think, oh, I can simplify that:
>
> a * (b + c)
>
Then you've got to consider whether the operators are associative.
Technically the built-in C operators are not, but it seldom matters.
The problem is in a sense worse than with commutativity, because if an
operator is not commutative then reversing the operands is likely to
produce a wildly different result. If the operators are not
associative, however, that's often because of the limitations of
machine representation rather than mathematical fundamentals. So you
could get slight differences in values which could lead to all sorts
of subtle and hard to trace problems.

== 8 of 14 ==
Date: Wed, Mar 10 2010 2:11 pm
From: jacob navia

Seebs a écrit :
> On 2010-03-10, Richard Bos <raltbos@xs4all.nl> wrote:
>> jacob navia <jacob@spamsink.net> wrote:
>>> My opinion is that C should be developed further, exactly BECAUSE is
>>> a simple language. Adding a container library to C doesn't make the
>>> language any bigger or more complicated but makes programs COMPATIBLE
>>> because it is possible to interchange data with standard API/containers.
>
>> I'm sorry, but... did you _really_ just write something to the tune of:
>> "C is a simple language. Adding a large, complicated gathering of data
>> structures to it won't make it any bigger and more complicated"?
>
> I suspect Jacob is relying somewhat on the distinction between "language"
> and "library" here.

The standard makes this distinction, I did not invented it.

> A standard container library does not make the "language"
> part of the language more complicated. (It is a bug in English that the C
> language has two components, language and library. Library functions are not
> part of the language part of the language, but the library as a whole is
> part of the language. This should be clear and simple to understand, and is
> not because English is defective. Please file a defect report with the love
> child of some random Norman/Saxon pairing in the 1500s.)
>
> The issue, as I see it is:
>
> Insofar as no complexity is really added, neither is any functionality; you
> can't use the container library without knowing what it does.
>
> Insofar as functionality is added, it creates additional complexity.
>
> The designs I've seen for Jacob's container library, while reasonably
> flexible, are IMHO too top-heavy for the sorts of things that normally make
> it into the C standard library. They're very clearly influenced by things
> learned during the development of C++ and the STL, but those things, I think,
> make less sense in a pure C environment.
>

I do not think so. Modern C software design can be quite sophisticated.
Why should we stay at the level of, say, strcpy?

"top heavy"?

The goal was to have an extremely flexible design that can accomodate
further enhancements without making old code obsolete. True, for a
simple linked list it looks too heavy, but the advantages of a standard
container is that it makes all programs *compatible* by allowing data
interchange in a standard way.

Of course if you just want a simple linked list it is top heavy. Writing
a red/black tree implementation or a dictionary is not the same however,
and even if the syntax looks forbidding at first sight thebgains come
with regular use.

> I guess the question is:
>
> Were this part of a future spec, would we get more or fewer complaints from
> confused newbies? I'd guess more. That, to me, means it is increasing
> complexity.
>
> -s

I do not think that newbies are the problem here. It is rather the
oldbies ( :-) ) like me that have this FED UP feeling when they start
coding the 100th linked list implementation...
--
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.

== 9 of 14 ==
Date: Wed, Mar 10 2010 2:19 pm
From: Dr Malcolm McLean

On 10 Mar, 18:13, Nick <3-nos...@temporary-address.org.uk> wrote:
>
> Really you need to be able to define new operators, even if this is just
> syntactic sugar for functions. Give them all the same precedence and
> off you go.
>
Exponentiation is the obvious basic operation that lacks an operator.
The convention is Chinese hat. Unfortunately that has been used for
XOR. So two Chinese hats. However that looks too much like logical
XOR.
So maybe two asterisks. This could be made to work. However asterisks
are already used for both multiplication and pointer derferencing. It
might be hard to read. Worse, it might be easy to read when playing
about with it, hard to read when you get into subtle, speed-critical,
complex areas of real code.

== 10 of 14 ==
Date: Wed, Mar 10 2010 2:25 pm
From: Nick <3-nospam@temporary-address.org.uk>

Dr Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On 10 Mar, 18:13, Nick <3-nos...@temporary-address.org.uk> wrote:
>>
>> Really you need to be able to define new operators, even if this is just
>> syntactic sugar for functions. Give them all the same precedence and
>> off you go.
>>
> Exponentiation is the obvious basic operation that lacks an operator.
> The convention is Chinese hat. Unfortunately that has been used for
> XOR. So two Chinese hats. However that looks too much like logical
> XOR.
> So maybe two asterisks. This could be made to work. However asterisks
> are already used for both multiplication and pointer derferencing. It
> might be hard to read. Worse, it might be easy to read when playing
> about with it, hard to read when you get into subtle, speed-critical,
> complex areas of real code.

a = b pow c;

That's the sort of thing I was thinking of.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 11 of 14 ==
Date: Wed, Mar 10 2010 2:38 pm
From: jacob navia

Richard Bos a écrit :
> jacob navia <jacob@spamsink.net> wrote:
>
>> My opinion is that C should be developed further, exactly BECAUSE is
>> a simple language. Adding a container library to C doesn't make the
>> language any bigger or more complicated but makes programs COMPATIBLE
>> because it is possible to interchange data with standard API/containers.
>
> I'm sorry, but... did you _really_ just write something to the tune of:
> "C is a simple language. Adding a large, complicated gathering of data
> structures to it won't make it any bigger and more complicated"?
>
> Because if you did, I'd like to know what the French government thinks
> of the stuff you imported from some "coffee shop" in Amsterdam; and if
> you didn't, I'd like to know how you can possibly think that any
> flexible container library that could be good enough to use by the
> majority of C users could ever _not_ be too large, complicated, and
> highly over-specced to use.
>
> Richard

The container library is around 80K (32 bit machines)

In that space I have
o lists (double/sinlgle linked)
o bitstrings
o AVL trees
o Red/Black trees
o Dictionary (Hash tables)
o Flexible arrays.

Is 80K "too large" ???

Over-specced?

You have remained silent (as all other "regs") in the discussions
about the library here.

It is very easy. You limit yourself to piss at other people's proposals
without ever proposing anything.
--
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.

== 12 of 14 ==
Date: Wed, Mar 10 2010 2:42 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <87aaufervu.fsf@temporary-address.org.uk>,
Nick <3-nospam@temporary-address.org.uk> wrote:
>Dr Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On 10 Mar, 18:13, Nick <3-nos...@temporary-address.org.uk> wrote:
>>>
>>> Really you need to be able to define new operators, even if this is just
>>> syntactic sugar for functions. Give them all the same precedence and
>>> off you go.
>>>
>> Exponentiation is the obvious basic operation that lacks an operator.
>> The convention is Chinese hat. Unfortunately that has been used for
>> XOR. So two Chinese hats. However that looks too much like logical
>> XOR.

There is already an operator for logical a xor b:
``a != b'' if a and b are known to be 0 or 1, or otherwise ``!a != !b''.

>> So maybe two asterisks. This could be made to work. However asterisks
>> are already used for both multiplication and pointer derferencing. It
>> might be hard to read. Worse, it might be easy to read when playing
>> about with it, hard to read when you get into subtle, speed-critical,
>> complex areas of real code.
>
>a = b pow c;
>
>That's the sort of thing I was thinking of.

But in that case, ``pow'' would probably have to be a keyword, and then
it could not be used as a fuction name anymore.

It would be more in the spirit of C to use ``a = b static c;''

== 13 of 14 ==
Date: Wed, Mar 10 2010 2:47 pm
From: Ian Collins

On 03/11/10 10:56 AM, Thomas Richter wrote:
> Ian Collins wrote:
>
>>>> The C++ STL appeared fairly early on in that language's evolution and
>>>> was rapidly and widely accepted by C++ developers. The widespread use
>>>> resulted in it being incorporated into the standard library in first
>>>> language standard.
>>>>
>>>> Why hasn't the same thing happened with C?
>>>
>>> Because it's the Wrong Thing for C. C isn't a one-purpose language.
>>
>> Very few languages are, C++ certainly isn't.
>
> The argument goes IMHO into the wrong direction. To make containers
> really powerful and safe, you need some kind of generics support, and
> some type of mechanism to hide the implementation behind the interface.
> C provides only relatively weak measures for that. I afraid the result
> would be of rather limited use.

I agree. That is one reason why containers are part of the C++ standard
library and not the C one. Containers were a bodge in Java before
generics were bolted onto that language.

== 14 of 14 ==
Date: Wed, Mar 10 2010 2:48 pm
From: pacman@kosh.dhis.org (Alan Curry)

scalar*vector follows the rule just fine. And vector*vector as long as you
mean dot product. Cross product is exactly where you have gone too far if you
overload the "*" operator for it.

Matrix multiplication is just crazy. I don't see why the mathematicians
insist on calling it "multiplication" at all.

--
Alan Curry

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 10 2010 12:29 pm
From: Anand Hariharan

On Mar 4, 8:40 am, Richard <rgrd...@gmail.com> wrote:
(...)
> You dont say "if pi is larger than p".You say "if p is larger than
> pi".

They are not equivalent statements. ;-)

==============================================================================
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 6 ==
Date: Wed, Mar 10 2010 12:49 pm
From: jamm

spinoza1111 wrote:

> A letter complaining about Peter Seebach's online behavior in this
> forum and in comp.lang.c.moderated has been sent to Apress management.

In other news, I just ate a bowl of cereal.

== 2 of 6 ==
Date: Wed, Mar 10 2010 9:20 am
From: "Bruce C. Baker"

"spinoza1111" <spinoza1111@yahoo.com> wrote in message
news:e977d7ae-c458-4a77-b4d5-8f88a097a9ea@w9g2000prb.googlegroups.com...
>A letter complaining about Peter Seebach's online behavior in this
> forum and in comp.lang.c.moderated has been sent to Apress management.
>

Peter Seebach will now be either quaking with fear or shaking with laughter.
I suspect it'll be the latter.

== 3 of 6 ==
Date: Wed, Mar 10 2010 1:27 pm
From: Seebs

On 2010-03-10, Bruce C. Baker <bcb@undisclosedlocation.net> wrote:
> "spinoza1111" <spinoza1111@yahoo.com> wrote in message
> news:e977d7ae-c458-4a77-b4d5-8f88a097a9ea@w9g2000prb.googlegroups.com...
>>A letter complaining about Peter Seebach's online behavior in this
>> forum and in comp.lang.c.moderated has been sent to Apress management.

> Peter Seebach will now be either quaking with fear or shaking with laughter.
> I suspect it'll be the latter.

Got it in one.

I mean, really. All we need is a couple of typical sample quotes, like
the accusation that someone is a transvestite nazi, and we pretty much have
the question of "where is the kook in this picture" nailed down.

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

== 4 of 6 ==
Date: Wed, Mar 10 2010 1:37 pm
From: Dann Corbit

In article <slrnhpg44q.rjr.usenet-nospam@guild.seebs.net>, usenet-
nospam@seebs.net says...
>
> On 2010-03-10, Bruce C. Baker <bcb@undisclosedlocation.net> wrote:
> > "spinoza1111" <spinoza1111@yahoo.com> wrote in message
> > news:e977d7ae-c458-4a77-b4d5-8f88a097a9ea@w9g2000prb.googlegroups.com...
> >>A letter complaining about Peter Seebach's online behavior in this
> >> forum and in comp.lang.c.moderated has been sent to Apress management.
>
> > Peter Seebach will now be either quaking with fear or shaking with laughter.
> > I suspect it'll be the latter.
>
> Got it in one.
>
> I mean, really. All we need is a couple of typical sample quotes, like
> the accusation that someone is a transvestite nazi, and we pretty much have
> the question of "where is the kook in this picture" nailed down.

Spinoza/Niggles/Whatever seems to be degrading rapidly into a truly
tragic figure. I sincerely hope that he gets the help he really needs.

== 5 of 6 ==
Date: Wed, Mar 10 2010 1:47 pm
From: Seebs

On 2010-03-10, Dann Corbit <dcorbit@connx.com> wrote:
> Spinoza/Niggles/Whatever seems to be degrading rapidly into a truly
> tragic figure. I sincerely hope that he gets the help he really needs.

Yeah, pretty much. But there's not much we can do about it from here.

== 6 of 6 ==
Date: Wed, Mar 10 2010 2:23 pm
From: James Harris

On 10 Mar, 20:49, jamm <nos...@nomail.net> wrote:
> spinoza1111 wrote:
> > A letter complaining about Peter Seebach's online behavior in this
> > forum and in comp.lang.c.moderated has been sent to Apress management.
>
> In other news, I just ate a bowl of cereal.

This made me laugh out loud when I read it!

Spinoza's complaints about others are becoming like something that we
expect on a daily basis - like breakfast.

I had thought it would be fun to see what Spinoza was like in real
life (but not, ever, to work with him), i.e. how does he deal with
people whom he disagrees with. But having read Dann's comment there's
maybe a sadder way to see this.

James

==============================================================================
TOPIC: Beginner's guide to MinGW?
http://groups.google.com/group/comp.lang.c/t/e2cff1c3cf36ab5f?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 10 2010 1:24 pm
From: REH

On Mar 9, 4:51 pm, "MikeC" <my.address@end_of.post> wrote:
> Folks,
>
> I know this isn't a C-language related question, but before I get into C, I
> have to have a compiler.
> In fact, I have been using DJGPP for many years, but I have recently
> upgraded to a 64-bit CPU machine, and the old DOS programs I wrote with it,
> and DJGPP itself, won't run on it. For this reason, I'd like to upgrade to
> MinGW, and I'm sure there are people on this user group that could point the
> way.
>
> What I'm looking for is a really simple manual that will hold my hand till I
> get going, and have compiled and run my first C program. After that, I
> should be OK.
> I tried the user forum on the MinGW site, but found them none too helpful.
> It's populated by people who don't willingly tolerate newbies.
>
> I have found a fair amount on the web about it, but it's all about other
> languages, and I want something that specifically tells me how to compile
> and run a C program. I've been trying for a long time, but I'm clearly not
> understanding something.
>

Look at the manuals at the GCC site (gcc.gnu.org). MinGW is not much
more than GCC targeted for Windows. You create and compile programs
the same as you would any installation of GCC. There are GUI frontends
to MinGW, but I prefer just an editor and makefiles (or actually JAM
files these days). A simple example:

gcc -o hello.exe hello.c

from the command prompt would compile the file hello.c and create the
executable hello.exe.

REH

== 2 of 2 ==
Date: Wed, Mar 10 2010 1:32 pm
From: REH

On Mar 9, 5:58 pm, "osmium" <r124c4u...@comcast.net> wrote:
> To compile a C program, type the source file name and end the name with
> ".c". Do not fiddle with the OS settings. If you do not provide an
> extension, .c++ will be provided automatically. Because of these rules, C++
> programs are easier to compile and run. It is quite easy to forget you are
> "doing" c if you change the file name often, as I sometimes do with trivial
> programs.
>

I think you are describing something other than MinGW itself, possibly
someone's frontend (such as Visual MinGW or Dev-C++) or possibly the
behavior of your own editor.

REH

==============================================================================
TOPIC: Correct way to write a wrapper for C functions that accept/return
strings
http://groups.google.com/group/comp.lang.c/t/a933ecd78edafba1?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 10 2010 1:39 pm
From: Dr Malcolm McLean

On 9 Mar, 15:53, Eli Osherovich <eli.osherov...@gmail.com> wrote:
>
> May be I do not understand you correctly... but my impression is you
> are talking about C not Fortran.- Hide quoted text -
>
I got the wrong end of the stick. We have a lot of non-native English
speakers here who use terms like "wrapper" incorrectly. I assumed you
meant "interface" rather than Fortran wrapper.

In Fortran 77 an integer is passed along with a string to give its
length. So to call a C string functions it's

void cfunc_(char *str, int N)

note it's "int N", not "int * N"

The easiest way to return a string is simply to write to the buffer
you used to pass the input.

(A question for middlebies: should the C function use size_t
internally? What are the pros and cons of doign so?).

==============================================================================
TOPIC: An interview question
http://groups.google.com/group/comp.lang.c/t/c93105672f793e63?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 10 2010 2:23 pm
From: "Default User"

Keith Thompson wrote:

> raltbos@xs4all.nl (Richard Bos) writes:
> > Keith Thompson <kst-u@mib.org> wrote:
> >> "Default User" <defaultuserbr@yahoo.com> writes:
> >> > Seebs wrote:
> >> >> Sounds like a pretty bad interview question to me.
> >> >
> >> > Sounds like a terrific one to me. You can just get up, shake his
> hand, >> > and leave without wasting any more of your time.
> >>
> >> Or you can tell the interviewer that it's a very silly thing to do,
> >> and he can tell you that was the answer he was looking for.
> >
> > And then you can tell him that you'd prefer your employer not to be
> > trying to set traps for his employees.
> >
> > Really, if you would do that to him, you'd never get hired. Why
> > should he be allowed any more dishonesty than you?
>
> In a real job, you're likely to be faced with bad requirements.
> As an interviewer, how would you judge an applicant's ability and
> willingness to question such requirements?

That's true, but irrelevant. The requirements in a real job should not
be a deliberate trap to see what the reaction will be.

In the given case, the applicant has no way of knowing a trap has been
set. The best he or she can do is assume that this is a legitimate
question. Given that assumption, then the only reasonable conclusion is
that it's a clueless question that indicates a clueless interviewer,
futher indicating a clueless organization.

Like I said, get up and leave. Whether it's a dumb question or a trap
doesn't matter.

Brian

--
Day 400 of the "no grouchy usenet posts" project

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

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 10, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts