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

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

C++ forcing unnecessary changes to C?

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

Contents

  C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 20:34 +0800
    Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 05:09 -0800
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:42 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:14 -0800
      Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:10 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-19 15:26 +0100
          Re: C++ forcing unnecessary changes to C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-19 10:09 -0500
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-20 13:47 +0100
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 03:25 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-21 14:15 +0100
            Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 05:39 -0800
    Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 14:26 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:41 +0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 15:20 +0100
          Re: conduct in comp.lang.c "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:23 +0800
    Re: C++ forcing unnecessary changes to C? Philipp Klaus Krause <pkk@spth.de> - 2016-11-18 15:16 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:20 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:18 -0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 07:15 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 16:55 +0100
          Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:31 -0800
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:38 +0100
    Re: C++ forcing unnecessary changes to C? John Bode <jfbode1029@gmail.com> - 2016-11-18 07:09 -0800
      Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:22 -0800
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:31 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:04 +0100
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 16:37 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 23:53 +0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:00 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:34 +0100
        Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-18 09:32 -0800
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:09 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 18:02 +0100
          Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-21 03:26 -0600
            Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:11 +0100
              Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-22 08:55 -0800
              Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-25 03:25 -0600
                Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-25 10:00 -0800
                Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-25 12:30 -0800
                  Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 00:38 +0100
                    Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 10:44 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 20:44 +0100
                        Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 12:38 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 21:00 +0100
    Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:04 -0800
      Re: [OT] discipline and obedience "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:53 +0800
      Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:55 +0800
        Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:02 -0800
          Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:09 +0800
            Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:35 -0800
              Re: C & C++ Committee fir <profesor.fir@gmail.com> - 2016-11-19 08:51 -0800
                Re: Do you write C programs? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 01:00 +0800
              Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:59 +0800
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:14 +0100
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 12:05 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 14:51 +0100
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 15:50 +0100
            Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 15:01 +0000
              Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 08:58 -0800
                Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 18:08 +0100
                Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 18:14 +0000
                  Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:33 +1300
                    Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 19:42 +0000
                      Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:51 +1300
                      Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:13 -0800
                        Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 21:35 +0000
                          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:47 +0100
                    Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:09 -0800
                  Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:40 +0100
                    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 01:27 +0100
                      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-26 01:48 +0100
                Re: C++ forcing unnecessary changes to C? Nathan Wagner <nw@hydaspes.if.org> - 2016-11-24 18:09 +0000

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

#97541

On Friday, November 25, 2016 at 5:39:05 PM UTC-6, jacobnavia wrote:
> It would be better to promote that warning to an error. The code that 
> does that is in general BROKEN, since any use of the return value of 
> that function is a bomb that explodes into your software: the 
> introduction of NOISE in the data stream. That noise is amplified (or 
> not) by the position and importance of the usage of the noise in the 
> software.

There are a number of situations where a single function pointer is
used to perform some operations that would return something useful, and
others that wouldn't (perhaps selected with a "mode" parameter); some
callers will use the return value and some won't.  Failing to specify a
return value that nothing will care about shouldn't be a defect--a bigger
defect would be caring about a return value when a function has nothing
meaningful to return.

> Old software is rarely used for unimportant stuff, and it would be much 
> nicer for everyone that the old software is fixed too.

If no code which e.g. passes a function a "mode" value of 0 cares about
what it returns, why should the function need to be "fixed" to return
anything in particular if "mode" is zero?  If a caller uses the return in
such a way that some possible value could cause problems, the caller is
defective.  If no possible return value could cause trouble, would a
machine-language instruction to force a return value of 0 serve any useful
purpose?  If such an instruction would serve no purpose, is there any reason
why programmers should need to force compilers to include it?

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

#97542

Le 26/11/2016 à 19:44, supercat@casperkitty.com a écrit :
> There are a number of situations where a single function pointer is
> used to perform some operations that would return something useful, and
> others that wouldn't (perhaps selected with a "mode" parameter); some
> callers will use the return value and some won't.  Failing to specify a
> return value that nothing will care about shouldn't be a defect--a bigger
> defect would be caring about a return value when a function has nothing
> meaningful to return.

That is precisely the mistake. By allowing noise to enter the system, it 
builds a dangerous opportunity for bugs. Now, let's see in detail.

A function is proposed, that should return a valid value "sometimes", 
when the result value is used, I suppose.

So, we have a situation when according to computations local to that 
function, noise or a meaningful value can come out of that function.

When a change needs to be done to some software, a new call to that 
function could be needed. Or that function could be used in a slightly 
different context because of a larger software reorganization.

Is it right to write functions that can return noise sometimes?

If we slightly redesign the function, so that always a valid value is 
returned, the default being EXIT_SUCCESS or zero, we eliminate some noise.

In a debugging situation, a random value is difficult to differentiate 
from actual data. Why has this variable 1285623 as value? Where it was 
computed?

And you start a dead end since that value is just NOISE. Can be 
anything, that value is not a value in fact.

It can be the value of the last operation done with register eax in 
intel/amd machines. Or whatever, something even meaningful in the 
context of the crash, for instance.

To build solid software means avoiding things like this. The language 
can encourage those practices by defining that a non void function must 
always and in all paths of execution return an assigned return value and 
not noise.

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

#97544

On Saturday, November 26, 2016 at 1:44:24 PM UTC-6, jacobnavia wrote:
> That is precisely the mistake. By allowing noise to enter the system, it 
> builds a dangerous opportunity for bugs. Now, let's see in detail.
> 
> A function is proposed, that should return a valid value "sometimes", 
> when the result value is used, I suppose.

The behavior of the function would be controlled by the arguments.  Since
the meaning of the return value, if any, would depend upon the type of
action being performed, any code that didn't know what action was being
performed would have no reason to do anything with it except pass it
through to code that might want it [either directly, or as part of a "raw
bits" log].

> So, we have a situation when according to computations local to that 
> function, noise or a meaningful value can come out of that function.

The determination would generally be based upon arguments given to the
function.  The function would know whether a meaningful value was expected,
as would the caller.  A wrapper function shouldn't need to know or care.

> When a change needs to be done to some software, a new call to that 
> function could be needed. Or that function could be used in a slightly 
> different context because of a larger software reorganization.

Designs such as I described are somewhat brittle, and in most cases on
modern hardware the extra cost of ensuring a particular return value would
be too slight to be worth worrying about.  On the other hand, since some
APIs work that way, any code wanting to use those APIs must be capable of
interacting smoothly with code that works that way.

> Is it right to write functions that can return noise sometimes?

Most such "functions" behave as sets of functions that for technical
reasons share a common entry point.  Pass 0 as the first argument to
perform one action and return one kind of value; pass 1 as the first
argument to perform some other action that returns another kind of
value; etc.

> If we slightly redesign the function, so that always a valid value is 
> returned, the default being EXIT_SUCCESS or zero, we eliminate some noise.

True, and on most modern hardware the cost of doing so is low enough that
it would generally be a good idea.  On the other hand, the only reason I
can see to have a compiler return an indeterminate value rather than e.g.
(retType){0} would be that the run-time cost of the latter would be
unacceptable.  If a programmer has to force the generation of code to
return a known value whether or not anything would care, the runtime cost
of having a compiler force a return value in the non-existent cases where
the programmer doesn't do so would be zero.

> In a debugging situation, a random value is difficult to differentiate 
> from actual data. Why has this variable 1285623 as value? Where it was 
> computed?

If the log indicates captures the arguments and the return value, a log-
parsing utility could filter things if it turns out there's a need for
it.  If nobody ever ends up looking at the logs, there won't be any need
for anyone to spend time writing utilities to do so.

> And you start a dead end since that value is just NOISE. Can be 
> anything, that value is not a value in fact.

Having everything that should be a sensible value "look" like a sensible
value can make debugging a bit easier, but if one doesn't know what a
function is supposed to return one wouldn't know whether something like 0
or 12 was a sensible value or not.

> It can be the value of the last operation done with register eax in 
> intel/amd machines. Or whatever, something even meaningful in the 
> context of the crash, for instance.

It's often easier to log stuff that may or may not be meaningful, and worry
about what should be shown if/when it's necessary to actually use the log
enough that one can't visually confirm the correctness of the parts that are
defined and ignore the rest, than to try to capture only things that are
actually meaningful.

> To build solid software means avoiding things like this. The language 
> can encourage those practices by defining that a non void function must 
> always and in all paths of execution return an assigned return value and 
> not noise.

Avoiding noise has a certain run-time cost.  In many cases, that cost will
be low enough, and the benefits great enough, to justify paying it.  On
the other hand, I would expect a programmer to have a better idea of the
costs and benefits, as they relate to a particular application, than would
a compiler [the compiler might know costs, but generally wouldn't know what
things would or would not be beneficial in a given application].

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

#97543

Le 26/11/2016 à 19:44, supercat@casperkitty.com a écrit :
> If no code which e.g. passes a function a "mode" value of 0 cares about
> what it returns, why should the function need to be "fixed" to return
> anything in particular if "mode" is zero?  If a caller uses the return in
> such a way that some possible value could cause problems, the caller is
> defective.

Failure modes?

With the introduction of noise the failure modes of the function are 
impredictable. They depend on memory contents that can be quite 
different. The program works most of the time except sometimes in the 
morning when nobody has used much the machine. Then it crashes but if 
you restart it, it works. Nobody knows why.


  If no possible return value could cause trouble, would a
> machine-language instruction to force a return value of 0 serve any useful
> purpose?  If such an instruction would serve no purpose, is there any reason
> why programmers should need to force compilers to include it?

void functions do not return any value. The language provides an 
specific construct for that situation, and that simplifies the task of 
the maintenance programmer. Mixing void and non void functions is a 
conceptual problem, and in fact two functions are needed with the same 
signature

void Perform( inputs)

non void Compute( inputs)

where Compute() returns a result and Perform() returns none. All code of 
the mode values that do not return any value should be in the void 
function Perform() and all those that return a result in the Compute() 
function. That simplifies everything isn't it?

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

#96882

On Friday, November 18, 2016 at 7:34:12 AM UTC-5, Mr. Man-wai Chang wrote:
> IS it a stupid comment?

1) Is what a stupid comment?

2) The Subject: header should summarize what's in the message, it shouldn't be
the only place where you write something important that's not in the message.

3) The question mark a the end of your Subject: makes it nominally a question,
not a comment, though it doesn't have the right syntax to be a question.

4) The comment "C++ forces unnecessary changes to C" would be a stupid one
unless presented with evidence supporting such a claim, which you have not
provided. To the best of my knowledge, which is pretty good, there is no such
evidence.

5) The question "Is C++ forcing unnecessary changes to C?" would not be a
stupid question. However, it would be a far more interesting question if were
part of a message that also presented evidence justifying bothering to ask it -
such as even a single example of a change to C that appeared to you to be both
unnecessary and forced by C++.
 
The answer to that question is "No". Both the C committee and the C++ committee
are committed to a policy of avoiding creating gratuitous incompatibilities
between the two languages. However, neither committee has any authority to
force the other committee to do anything - avoiding such incompatibilities is
achieved by cooperation between the committees, not by force. Whether any
particular change to C has been unnecessary is debatable, and has been hotly
debated in many cases - but those changes have always been done with the fully
voluntary cooperation of the C committee, not by force from the C++ committee.
Note: the policy described above freely allows non-gratuitous
incompatibilities, and such incompatibilities are quite numerous, and every
revision of either standard introduces many new non-gratuitous
incompatibilities.

6) Don't respond by calling me Master - I'm giving you advice, not orders, and
you are quite obviously ignoring the advice I've given you in the past, so I'm
clearly NOT your Master. If I were your Master, I'd have the power, the right,
and the responsibility to discipline you for failing to follow my advice; in
reality, none of those things apply.

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

#96974 — Re: [OT] discipline and obedience

On 19/11/2016 3:04 AM, jameskuyper@verizon.net wrote:
> 6) Don't respond by calling me Master - I'm giving you advice, not orders, and
> you are quite obviously ignoring the advice I've given you in the past, so I'm
> clearly NOT your Master. If I were your Master, I'd have the power, the right,
> and the responsibility to discipline you for failing to follow my advice; in
> reality, none of those things apply.

Wanna try some Jedi if not Sith mind tricks, aka psychology if not 
psychiatry, Master?

I think there are mercenaries "doctors" out there for hire to do dark 
deeds, Master! Doctor X? :)

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

#96975 — Re: C & C++ Committee

On 19/11/2016 3:04 AM, jameskuyper@verizon.net wrote:
> The answer to that question is "No". Both the C committee and the C++ committee
> are committed to a policy of avoiding creating gratuitous incompatibilities
> between the two languages. However, neither committee has any authority to
> force the other committee to do anything - avoiding such incompatibilities is
> achieved by cooperation between the committees, not by force. Whether any
> particular change to C has been unnecessary is debatable, and has been hotly
> debated in many cases - but those changes have always been done with the fully
> voluntary cooperation of the C committee, not by force from the C++ committee.
> Note: the policy described above freely allows non-gratuitous
> incompatibilities, and such incompatibilities are quite numerous, and every
> revision of either standard introduces many new non-gratuitous
> incompatibilities.

Are C & C++ programming mostly about military projects in USA? Then I 
can understand why Masters here emphasize obedience and discipline. :)

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

#96990 — Re: C & C++ Committee

On Saturday, November 19, 2016 at 9:55:21 AM UTC-5, Mr. Man-wai Chang wrote:
...
> Are C & C++ programming mostly about military projects in USA? Then I

There's a lot of military oriented computer programming done in the US (I've no idea how much of it is in C or C++). However, there's a lot of civilian programming being done as well, including both of the projects I'm working on.
 
> can understand why Masters here emphasize obedience and discipline. :)

You probably misuse the term "master" because you've never had one - when someone else is your master, that person is almost always concerned with obedience and discipline, whether the master of an aristocratic household, or of carpentry, painting, or Tae-kwon-do. For me, it's one of the things that makes me not want to be anyone's master - sadists may feel differently.

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

#96993 — Re: C & C++ Committee

On 20/11/2016 12:02 AM, jameskuyper@verizon.net wrote:
>
> There's a lot of military oriented computer programming done in the US (I've no idea how much of it is in C or C++). However, there's a lot of civilian programming being done as well, including both of the projects I'm working on.
>...
> You probably misuse the term "master" because you've never had one - when someone else is your master, that person is almost always concerned with obedience and discipline, whether the master of an aristocratic household, or of carpentry, painting, or Tae-kwon-do. For me, it's one of the things that makes me not want to be anyone's master - sadists may feel differently.

I do *NOT* work for the military, Master. I write business programs.

Save your anger and orders in your military projects, Master! :)

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

#97005 — Re: C & C++ Committee

On Saturday, November 19, 2016 at 11:09:07 AM UTC-5, Mr. Man-wai Chang wrote:
> On 20/11/2016 12:02 AM, jameskuyper@verizon.net wrote:
> >
> > There's a lot of military oriented computer programming done in the US
> > (I've no idea how much of it is in C or C++). However, there's a lot of
> > civilian programming being done as well, including both of the projects I'm
> > working on.
> >...
> > You probably misuse the term "master" because you've never had one - when
> > someone else is your master, that person is almost always concerned with
> > obedience and discipline, whether the master of an aristocratic household,
> > or of carpentry, painting, or Tae-kwon-do. For me, it's one of the things
> > that makes me not want to be anyone's master - sadists may feel differently.
> 
> I do *NOT* work for the military, Master. I write business programs.

Well, I said nothing to the contrary - why did you bother replying in that manner?

> Save your anger and orders in your military projects, Master! :)

I have no military projects, so if such projects were the only context where I 
had permission to be angry, I'd be incredibly frustrated, because the world is
full of things that justify anger (for example, the guy who recently punched
his infant child 5 times at full strength, killing the child, and his wife, who
overheard the incident, but did not actually see it, and who claims to be
uncertain whether those blows had anything to do with the child's death).
What I feel about your approach to non-conversation is mere annoyance, not
anger - you're not worth getting angry over.
As for orders, I haven't given you any - just advice, which you're free to
ignore. The only people with an obligation to obey orders from me are vendors
and my twins. Since the twins are only 19 months old, verbal orders do not yet
play a significant role in my efforts to keep them from killing themselves or
destroying the household. :-)

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

#97012 — Re: C & C++ Committee

W dniu sobota, 19 listopada 2016 17:35:47 UTC+1 użytkownik james...@verizon.net napisał:
> On Saturday, November 19, 2016 at 11:09:07 AM UTC-5, Mr. Man-wai Chang wrote:
> > On 20/11/2016 12:02 AM, jameskuyper@verizon.net wrote:
> > >
> > > There's a lot of military oriented computer programming done in the US
> > > (I've no idea how much of it is in C or C++). However, there's a lot of
> > > civilian programming being done as well, including both of the projects I'm
> > > working on.
> > >...
> > > You probably misuse the term "master" because you've never had one - when
> > > someone else is your master, that person is almost always concerned with
> > > obedience and discipline, whether the master of an aristocratic household,
> > > or of carpentry, painting, or Tae-kwon-do. For me, it's one of the things
> > > that makes me not want to be anyone's master - sadists may feel differently.
> > 
> > I do *NOT* work for the military, Master. I write business programs.
> 
> Well, I said nothing to the contrary - why did you bother replying in that manner?
> 
> > Save your anger and orders in your military projects, Master! :)
> 
> I have no military projects, so if such projects were the only context where I 
> had permission to be angry, I'd be incredibly frustrated, because the world is
> full of things that justify anger (for example, the guy who recently punched
> his infant child 5 times at full strength, killing the child, and his wife, who
> overheard the incident, but did not actually see it, and who claims to be
> uncertain whether those blows had anything to do with the child's death).
> What I feel about your approach to non-conversation is mere annoyance, not
> anger - you're not worth getting angry over.
> As for orders, I haven't given you any - just advice, which you're free to
> ignore. The only people with an obligation to obey orders from me are vendors
> and my twins. Since the twins are only 19 months old, verbal orders do not yet
> play a significant role in my efforts to keep them from killing themselves or
> destroying the household. :-)

our new user is not so bad as a clown but not anybody likes clowns that much (a bit of clown, ok, but on a longer run i personally get angry for all timewaste  )

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

#97015 — Re: Do you write C programs?

On 20/11/2016 12:51 AM, fir wrote:
>
> our new user is not so bad as a clown but not anybody likes clowns that much (a bit of clown, ok, but on a longer run i personally get angry for all timewaste  )

Do you write C programs, at least at home?

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

#97013 — Re: C & C++ Committee

I thought C was widely in the military industry. Well, *NEVER* worked in 
that field.

On 20/11/2016 12:35 AM, jameskuyper@verizon.net wrote:
> Well, I said nothing to the contrary - why did you bother replying in that manner?
>....
> I have no military projects, so if such projects were the only context where I
> had permission to be angry, I'd be incredibly frustrated, because the world is
> full of things that justify anger (for example, the guy who recently punched
> his infant child 5 times at full strength, killing the child, and his wife, who
> overheard the incident, but did not actually see it, and who claims to be
> uncertain whether those blows had anything to do with the child's death).
> What I feel about your approach to non-conversation is mere annoyance, not
> anger - you're not worth getting angry over.
> As for orders, I haven't given you any - just advice, which you're free to
> ignore. The only people with an obligation to obey orders from me are vendors
> and my twins. Since the twins are only 19 months old, verbal orders do not yet
> play a significant role in my efforts to keep them from killing themselves or
> destroying the household. :-)
>

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

#97232

Le 18/11/2016 à 13:34, Mr. Man-wai Chang a écrit :
>
> IS it a stupid comment?

Another problem is that C++ has catch/throw.

Since most C compilers are just c++ compilers that also compile C, they 
generate all the tables needed for exception handling even if the file 
is a C file. For instance in a moderately sized program (1.5MB) fully
approx 100 000 bytes are just exception handling tables needed for c++ 
even if the program is C only!

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

#97235

On 22/11/16 11:14, jacobnavia wrote:
> Le 18/11/2016 à 13:34, Mr. Man-wai Chang a écrit :
>>
>> IS it a stupid comment?
> 
> Another problem is that C++ has catch/throw.
> 
> Since most C compilers are just c++ compilers that also compile C, they
> generate all the tables needed for exception handling even if the file
> is a C file. For instance in a moderately sized program (1.5MB) fully
> approx 100 000 bytes are just exception handling tables needed for c++
> even if the program is C only!
> 

My experience is that most C "big" compilers handle different languages
- such as C and C++, but perhaps also others (gcc has Fortran, Ada, Go,
Objective-C, and Objective-C++ last time I looked).  Exception tables
are generated if exceptions are enabled - either because they are the
default for the language and not explicitly disabled, or because they
are explicitly enabled on the command line.

So gcc certainly does not generate exception tables for C compilation.
(And I think the developers would be somewhat surprised to hear gcc
characterised as "just" a C++ compiler that also compiles C!)

Similarly, embedded compilers that I have used that support C and C++ do
not generate exception tables for C.  And the many C-only embedded
compilers I have used do not support C++ at all.

Maybe MSVC generates exception stack unwind tables for C, since it is (I
believe) more like a "C++ compiler that also compiles C".  But I am not
familiar with the tool, so I cannot say.

Do you have concrete examples since you refer to "most C compilers" here?

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

#97252

Le 22/11/2016 à 12:05, David Brown a écrit :
> So gcc certainly does not generate exception tables for C compilation.

This is FALSE. See the thread I started "Negative effects of c++ in C".
For your convenience here is a msg:

No, I am talking about gcc. For instance I have a program called "asm",
an assembler, featuring

jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm
-rwxrwxr-x 1 jacob jacob 1462480 Nov 22 14:40 asm
jacob@linux-mint ~/lcc/asm/asm4 $ objdump -h asm

asm:     file format elf64-x86-64

Sections:
Idx Name          Size
  0 .interp       0000001c
...
several other small sections elided
...
15 .eh_frame_hdr 00003734
16 .eh_frame     00015b5c

We have then 0x3734 (14132) and 0x15b5c (88924) bytes, i.e. 103,506
bytes of exception handling overhead!

ALL the sources are in straight C and I have to pay 103,506 c++ taxes!

For NOTHING since C has no throws!

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

#97264

On 22/11/16 14:51, jacobnavia wrote:
> Le 22/11/2016 à 12:05, David Brown a écrit :
>> So gcc certainly does not generate exception tables for C compilation.
> 
> This is FALSE. See the thread I started "Negative effects of c++ in C".
> For your convenience here is a msg:
> 
> No, I am talking about gcc. For instance I have a program called "asm",
> an assembler, featuring
> 
> jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm
> -rwxrwxr-x 1 jacob jacob 1462480 Nov 22 14:40 asm
> jacob@linux-mint ~/lcc/asm/asm4 $ objdump -h asm
> 
> asm:     file format elf64-x86-64
> 
> Sections:
> Idx Name          Size
>  0 .interp       0000001c
> ...
> several other small sections elided
> ...
> 15 .eh_frame_hdr 00003734
> 16 .eh_frame     00015b5c
> 
> We have then 0x3734 (14132) and 0x15b5c (88924) bytes, i.e. 103,506
> bytes of exception handling overhead!
> 
> ALL the sources are in straight C and I have to pay 103,506 c++ taxes!
> 
> For NOTHING since C has no throws!

A little research shows that this is a /requirement/ of the x86-64 ABI.
 Amongst other things, gcc also uses it for debugging and cleanup
attributes (a gcc extension allowing a sort of destructor call in C).

On targets that don't have such ABI requirements - such as the ARM that
I am using - there are no exception tables or other C++ related
overhead, other than a few instructions from the library startup code.

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

#97270

On 22/11/2016 14:50, David Brown wrote:
> On 22/11/16 14:51, jacobnavia wrote:
>> Le 22/11/2016 à 12:05, David Brown a écrit :
>>> So gcc certainly does not generate exception tables for C compilation.
>>
>> This is FALSE. See the thread I started "Negative effects of c++ in C".
>> For your convenience here is a msg:
>>
>> No, I am talking about gcc. For instance I have a program called "asm",
>> an assembler, featuring
>>
>> jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm

(Thanks. I've been wondering how to get 'ls' to give me a file size in 
bytes!)

>> ALL the sources are in straight C and I have to pay 103,506 c++ taxes!
>>
>> For NOTHING since C has no throws!
>
> A little research shows that this is a /requirement/ of the x86-64 ABI.

That sounds unlikely. After all Jacob produces his own compiler for 
x64-ABI; you'd think he would know if that was the case!

-- 
Bartc

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

#97289

BartC <bc@freeuk.com> writes:
> On 22/11/2016 14:50, David Brown wrote:
>> On 22/11/16 14:51, jacobnavia wrote:
>>> Le 22/11/2016 à 12:05, David Brown a écrit :
>>>> So gcc certainly does not generate exception tables for C compilation.
>>>
>>> This is FALSE. See the thread I started "Negative effects of c++ in C".
>>> For your convenience here is a msg:
>>>
>>> No, I am talking about gcc. For instance I have a program called "asm",
>>> an assembler, featuring
>>>
>>> jacob@linux-mint ~/lcc/asm/asm4 $ ls -l asm
>
> (Thanks. I've been wondering how to get 'ls' to give me a file size in 
> bytes!)

`man ls`?  `ls --help`?

g>>> ALL the sources are in straight C and I have to pay 103,506 c++ taxes!
>>>
>>> For NOTHING since C has no throws!
>>
>> A little research shows that this is a /requirement/ of the x86-64 ABI.
>
> That sounds unlikely. After all Jacob produces his own compiler for 
> x64-ABI; you'd think he would know if that was the case!

The ABI document is http://www.x86-64.org/documentation/abi.pdf .
(The web site seems to be down at the moment.)  Sections 3.3.1,
Exception Interface, and 6.3, Unwinding Through Assembler Code,
seem relevant.  I haven't read it closely enough to know just what
it requires.  Perhaps David can provide more details.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#97290

Le 22/11/2016 à 17:58, Keith Thompson a écrit :
> Sections 3.3.1,
> Exception Interface, and 6.3, Unwinding Through Assembler Code,
> seem relevant.

They are not.
They describe what happens for c++, not for C. C has no try/catch and 
doesn't need any such sections.

Note that that document specifies that the exception handling stuff is 
going into the .text (code) section...

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

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

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

csiph-web