linking c++ code with c library

[BartC]

I want to have linux source code tree on my linux box hosted in VMWare ....
The bad thing is the new kernel can not boot the system*. I bear with
the noise from the pc fan for nothing and waste the whole night. The
debian 5.0 and the linux kernal are both written in C. Do you consider
this a problem topical here and help me out of the trouble?

Sure, just reduce your code down to the smallest size that exhibits the same
problem, and post it here in a form that we can test out.

 

[Richard Bos]

Yes, as any real world problem related to the language.


Yes, since they are related to the language. It is here where people
that know this type of answer could give their advise.


As far as it is related to programming in C, yes.

Ok, then I have a question for you.

In my "My Documents" directory, Windows XP insists on creating a subdir
called "My e-books". I don't want this subdir; I don't use it, so it
just clutters up my Documents dir. But if I delete it, Windows puts it
back after some time. (Behind my back, mind you. A very irritating habit
more Microsoft products have.)
I want that subdir to go away and _stay_ away. I'm sure that a C program
can be written to make this happen. I don't mean one which runs every
now and then and deletes that subdir if it exists; I mean a program
which makes Windows XP not re-create it in the first place.
Since you are so positive that file system organisation is on-topic, and
since the solution can most certainly be written in C, I think that it
is incumbent on you to tell me that solution. Don't you agree?

Richard

 

[Nobody]

Ok, then I have a question for you.

In my "My Documents" directory, Windows XP insists on creating a subdir
called "My e-books". I don't want this subdir; I don't use it, so it
just clutters up my Documents dir. But if I delete it, Windows puts it
back after some time. (Behind my back, mind you. A very irritating habit
more Microsoft products have.)
I want that subdir to go away and _stay_ away. I'm sure that a C program
can be written to make this happen.

Really, all the people dragging up strawmen are merely reinforcing the
argument that many on this group are more interested in language-lawyering
than with the language's actual purpose (writing software). I can't think
of any other comp.lang.* group which is so determined to treat the
language as an abstract construct with no connection to reality.

 

[jacob navia]

Really, all the people dragging up strawmen are merely reinforcing the
argument that many on this group are more interested in language-lawyering
than with the language's actual purpose (writing software). I can't think
of any other comp.lang.* group which is so determined to treat the
language as an abstract construct with no connection to reality.

EXACTLY.

When I ask a technical question I receive mostly a "legal" answer
here.

 

[Nobody]

That's because it's the most practical approach. It is precisely by
treating the language in an abstract way that one is best able to
dissociate the language from any particular platform, and thus can
construct software that is not tied to a particular platform.

Not all code needs to be portable. Even code which does need portability
doesn't need to achieve that by using nothing but portable code; there is
such a thing as conditional compilation.

Most of the jobs I've had would have come to an abrupt end if I wasted
time making the code run on bizarre yet technically-conformant platforms.

If
you want to nail yourself to FooSoft software or Bogonut hardware,
then the Foosoft and Bogonut groups are a great place to hang out.

Except, if those groups' members had the same attitude, the response would
be "questions relating to a specific programming language are off-topic
here, so we will only discuss pseudo-code".

But if you want to write software that will still be useful when
FooSoft and Bogonut are ancient history, abstraction is the way to
go.

A great deal of software reaches the end of its useful life long before
the OS vendor (or even the OS) disappears. OTOH, a great deal of
long-lasting software has isolated portions which are highly
platform-specific.

 

[Nick Keighley]

A great deal of software reaches the end of its useful life long before
the OS vendor (or even the OS) disappears. OTOH, a great deal of
long-lasting software has isolated portions which are highly
platform-specific.

not always though. I made my first change to a K&R C program just a
few weeks ago.

And There's a guy in my office who has a platform where both the
hardware
and the OS are discontinued. The cross-compiler runs under a VMS
emulator.

Sometimes systems Just Won't Die!

 

[Sjouke Burry]

Nobody said:

Gentleman, PLONK!!!

 

[Keith Thompson]

Gentleman, PLONK!!!

If you're plonking Richard Heathfield, that's your loss (though of
course you're absolutely entitled to do so if you choose).

 

[Sjouke Burry]

Keith Thompson wrote:
cut

If you're plonking Richard Heathfield, that's your loss (though of
course you're absolutely entitled to do so if you choose).

I was plonking a whole thread filled with juvenile newsgroup destroyers.

 

[Keith Thompson]

Keith Thompson wrote:
cut
I was plonking a whole thread filled with juvenile newsgroup destroyers.

Ok. "PLONK" usually means you're killfiling the poster of the article
to which you're replying.

 

[Nobody]

Better still (because IMHO platform-conditional compilation sucks),
there is such a thing as separation of non-portable components into
their own module.

That's fine if the boundary between the portable and platform-specific
parts falls more or less on a function boundary. If it doesn't, you have a
choice of:

1. Have platform-specific versions of the entire function for each
platform, which sucks if the function is 99% portable.

2. Extract the platform-specific portions into separate functions, which
sucks if the portions aren't natural candidates for separate functions
(e.g. read/write several local variables, use break/continue/goto), or are
in an inner loop and the compiler doesn't have "static inline".

3. Define platform-specific macros, which sucks ... well, because C's
macros generally suck.

And most of the jobs I've had would have come to an abrupt end if
I'd taken the advice of those here who post non-portable
information, because I have spent much of my career developing for
platforms other than Windows or *nix.

Obviously you don't take a chunk of code written for one platform and use
it verbatim on another. That doesn't mean that no-one should ever post
platform-specific code in response to a request relating to a specific
platform. Writing code which is far more complex than necessary just so it
works e.g. on a platform using sign-bit integer representation is just
pedantic.

Right. Questions about the language go here, and questions about the
platform go there. This isn't hard.

And questions about C programming on one platform or a subset of platforms
(e.g. any OS running on x86) go where?

Asking someone to take a C-on-Windows/Unix/MacOSX question to all three
groups because it isn't "pure" C is just being a nuisance.

And a great deal of software reaches the end of its useful life long
before it reaches a production environment. But good software
lasts.

It isn't just an issue of software quality. It doesn't matter how
well-written your Gopher client is, nobody uses Gopher any more. A lot of
software has an inherently short life span (e.g. code to transfer data
from a legacy system to its replacement). There's no reason to expend
effort on future-proofing such code.

Right - isolated portions. Those are the portions that you take up
with platform-specific newsgroups. This really is not difficult to
understand.

What's difficult to understand is where people get this idea that c.l.c is
somehow a group of last resort, i.e. anything which overlaps between c.l.c
and any other group inherently belongs solely on the other group.

 

[Phil Carmody]

Nobody said:

Um, quite so.

Functional macros generally suck, but I have no issues with
system specific constants as macros.

Phil

 

[Nobody]

2) having ascertained that video RAM is memory-mapped, I then go to
comp.lang.c and ask them "there's a specific set of hardware
addresses that I need to access; how can I do this in C?" (And
they/we would probably answer with the relevant syntax, along with
the caveat that the C Standard does not require it to work.)

Except that the "answer" would be "you can't do this in C" and any further
discussion would be drowned out with screeches of "that isn't in the
standard".

 

[jacob navia]

Except that the "answer" would be "you can't do this in C" and any further
discussion would be drowned out with screeches of "that isn't in the
standard".

Reason:

There are too many wannabes language lawyers and too few technicians
here.

For instance I developed a small algorithm for detecting the expression
i=i++; and I wanted to know if it is a sound one.

I asked here.

But since I started this (what a mistake!) with the remark "I know this
is illegal", ALL the answers were about the distinction of UB from
IB and other legalese. Noooone of them would try to answer the technical
question posed.

 

[Flash Gordon]

Reason:

There are too many wannabes language lawyers and too few technicians
here.

Or too many people who ignore facts which are inconvenient...

For instance I developed a small algorithm for detecting the expression
i=i++; and I wanted to know if it is a sound one.

I asked here.

But since I started this (what a mistake!) with the remark "I know this
is illegal", ALL the answers were about the distinction of UB from
IB and other legalese. Noooone of them would try to answer the technical
question posed.

Such as this being incorrect. Some posters did address your algorithm,
some pointed out that your assertion that no compiler did such checking
was wrong. Yes, a few people did discuss what was meant by "illegal",
but by no means all and I don't think it was most of the posts.

 

[jacob navia]

Or too many people who ignore facts which are inconvenient...

Like you for instance.

Such as this being incorrect. Some posters did address your algorithm,
None

some pointed out that your assertion that no compiler did such checking
was wrong.

Yes, one posted that some obscure option of gcc would warn about this
By the way, I never said that "no compiler did such checking", I just
said that I had never seen one.

Yes, a few people did discuss what was meant by "illegal",
but by no means all and I don't think it was most of the posts.

14 posts out of 15 answers. Obviously you have difficulties counting.

 

[Keith Thompson]

Like you for instance.


None

I pointed out some cases that your algorithm would not cover.
Are you not interested in that kind of feedback?

I read your description of your algorithm, and I didn't see any cases
where it would incorrectly report a problem where there isn't one.
I didn't say so explictly; I thought it was sufficiently obvious that
I would have pointed out such a problem if I'd seen it. Furthermore,
I didn't really think that my own failure to find such a problem
was worth mentioning. I could easily have missed something, and
I assumed that someone else might find what I'd missed.

The fact that nobody pointed out such a problem is evidence (but
not proof) that no such problems exist. I think your algorithm
is sound, though inevitably incomplete.

Isn't that exactly the kind of feedback you were looking for?

Yes, one posted that some obscure option of gcc would warn about this
By the way, I never said that "no compiler did such checking", I just
said that I had never seen one.

I wrote:

| gcc certainly warns about ``i = i++'' if you give it the right
| options:
|
| warning: operation on `i' may be undefined

Incidentally, the option I used to enable this warning, "-Wall", is
hardly obscure; it's one of the options that people are often
adviced they should always use.

Or should we have gone into deeper detail about how to use gcc?

14 posts out of 15 answers. Obviously you have difficulties counting.

You misused the word "illegal". Several people pointed this out;
we don't get together behind the scenes and pick one person to point
out each error, so redundancy is unavoidable. This spawned some
further discussion; if you ask a question, are we required to discuss
only matters that relate directly to the specific question you asked?

If you feel your original question hasn't been answered, by all
means ask for clarification (preferably in the original thread,
but you can start a new one if you like).

We answered your question as well as it could be answered *and*
we discussed some other things as well. Apparently that's not
good enough for you. And yet you've chosen to bring it up in a
different thread, rather than replying directly in the thread in
which you asked the question.

So as long as we're bringing up topics from other threads, have you
reconsidered your recent false claim that the "regs" have criticized
you regarding lcc-win's undocumented ansic89 option?

 

[Flash Gordon]

Like you for instance.

I did not ignore anything. You just made a factually inaccurate
statement and I've called you on it.

None

Incorrect, Keith pointed out a case he thought you missed. I might be
wrong but I think there was something else pointed out in comp.std.c (my
memory is not good so I could easily be miss-remembering).
Pointing out open-source tools which do such checks gave you somewhere
to look for alternative schemes for implementing the checks.

Yes, one posted that some obscure option of gcc would warn about this
By the way, I never said that "no compiler did such checking", I just
said that I had never seen one.

Well, you actually said you hadn't seen a compiler which implements this
warning, which is wrong since you've seen gcc. You just had not spotted
a clearly documented option it provides.

14 posts out of 15 answers. Obviously you have difficulties counting.

User923005 discussed what splint and lint do...
Keith talked about what is difficult to detect, pointed out a case he
thought you had missed and pointed out that gcc can diagnose some of the
issues (yes, he put in a side-note about "illegal" but clearly marked as
a quibble)...

In any case, even one post means your statement that "ALL the answers
were about the distinction of UB ..." was factually incorrect.

So as I say, you DID ignore the inconvenient fact that there were
responses directly relevant to your question. Had you responded to those
posts there might have been more discussion, but if you fail to respond
to such comments why would anyone bother going further?

 

[Frank]

If you're plonking Richard Heathfield, that's your loss (though of
course you're absolutely entitled to do so if you choose).

Sjouke is that he makes caustic remarks in a language he doesn't know
well. He and his cohort make me wonder about the english curriculum
on the continent.

 

[Richard Bos]

Really, all the people dragging up strawmen are merely reinforcing the

First of all, it's called straw men, not strawmen. Strawmen would be
people who sell or work with straw. A puppet built of straw is a straw
man.
More importantly, it's not a straw man. I really do have that problem,
and it really is MO that it follows from jacob's arguments that he
should be willing to help me with it.

Richard