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

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

Negative effects of c++ in C

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

Contents

  Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:18 +0100
    Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 11:46 +0100
      Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 14:48 +0100
        Re: Big main() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 21:51 +0800
        Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 15:29 +0100
        Re: Negative effects of c++ in C antispam@math.uni.wroc.pl - 2016-11-22 15:09 +0000
      Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 16:58 +0100
    Re: Negative effects of c++ in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-22 14:29 +0000
      Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-22 15:58 +0100
        Re: Negative effects of c++ in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-22 15:55 +0000
        Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 17:01 +0100
          Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 18:32 +0100
          Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-23 00:19 +0100
    [OT] It's only words... :) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 22:55 +0800
      Re: [OT] It's only words... :) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 22:57 +0800
    Re: Negative effects of c++ in C Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:43 +1300
      Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 21:14 +0100
      Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 21:17 +0100
    Re: Negative effects of c++ in C rockbrentwood@gmail.com - 2016-11-23 15:41 -0800
      Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-23 16:19 -0800
        Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-24 14:06 +0100
          Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-24 07:36 -0800
            Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-25 00:23 +0100
              Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-25 09:42 -0800
      Re: Negative effects of c++ in C Keith Thompson <kst-u@mib.org> - 2016-11-23 16:34 -0800
        Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-24 14:55 +0100

Page 1 of 2  [1] 2  Next page →

#97233 — Negative effects of c++ in C

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!

Another bad influence is that now the c committee has specified that if 
the programmer doesn't assign a return value to main it will default to 
zero. This makes it impossible for a compiler to warn aboyt the lack of 
assignment to the return value because the compiler can't distinguish 
between
1) The programmer forgot to assign the return value
2) The programmer doesn't assign a return value because he/she knows 
that it will be set to zero.

[toc] | [next] | [standalone]

#97234

On 22/11/2016 11:18, jacobnavia wrote:

> Since most C compilers are just c++ compilers that also compile C, they 

I see what you did there... C and c++  ^_^

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

You're talking about Microsoft Visual Studio, right?

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

#97251

Le 22/11/2016 à 11:46, Noob a écrit :
> On 22/11/2016 11:18, jacobnavia wrote:
>
>> Since most C compilers are just c++ compilers that also compile C, they
>
> I see what you did there... C and c++  ^_^
>
>> 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!
>
> You're talking about Microsoft Visual Studio, right?
>

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]

#97253 — Re: Big main()

On 22/11/2016 9:48 PM, jacobnavia wrote:
> 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!

You reminded me of my feeling when I first saw the Winmain() of a simple 
hello.c for Window$! :)

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

#97258

On 22/11/2016 14:48, jacobnavia wrote:
> Le 22/11/2016 à 11:46, Noob a écrit :
>> On 22/11/2016 11:18, jacobnavia wrote:
>>
>>> 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!
>>
>> You're talking about Microsoft Visual Studio, right?
> 
> 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!

Try compiling the entire project with -fno-asynchronous-unwind-tables

Does that help? :-)

https://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section#answer-26302715

Regards.

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

#97271

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 22/11/2016 ? 11:46, Noob a ?crit :
> > On 22/11/2016 11:18, jacobnavia wrote:
> >
> >> Since most C compilers are just c++ compilers that also compile C, they
> >
> > I see what you did there... C and c++  ^_^
> >
> >> 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!
> >
> > You're talking about Microsoft Visual Studio, right?
> >
> 
> 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!

IIUC those tables are needed if you link to a C++ library.
So you pay tax for _potential_ to link with C++.  Given
that you have about 7% increase in size and that tables
will stay on disc unless you use them this tax seem
resonable.  And if that 7% really bother you playing
with linker should get rid of them.

-- 
                              Waldek Hebisch

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

#97278

Le 22/11/2016 à 11:46, Noob a écrit :
> I see what you did there... C and c++  ^_^

:-)

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

#97259

jacobnavia <jacob@jacob.remcomp.fr> writes:

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

That's not good.  What ones?  I don't recall ever seeing thing problem
with a C compiler before, but I don't have access to most C compilers.

<snip>
-- 
Ben.

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

#97268

On 22/11/16 15:29, Ben Bacarisse wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> 
>> 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!
> 
> That's not good.  What ones?  I don't recall ever seeing thing problem
> with a C compiler before, but I don't have access to most C compilers.
> 

You only see it on x86-64, and that is because it is a requirement of
the ABI.  You can minimise the tables by using the -fno-unwind-tables
-fno-asynchronous-unwind-tables flags.  The code will work fine, as long
as you are not debugging.

And on *nix it rarely matters that there is extra data like this in an
executable file - those parts are typically not read in from files, so
they take no memory at run-time.

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

#97277

David Brown <david.brown@hesbynett.no> writes:

> On 22/11/16 15:29, Ben Bacarisse wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> 
>>> 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!
>> 
>> That's not good.  What ones?  I don't recall ever seeing thing problem
>> with a C compiler before, but I don't have access to most C
>> compilers.

(I see from elsewhere it's gcc so I could have seen the problem if I'd
looked.)

> You only see it on x86-64, and that is because it is a requirement of
> the ABI.

Ah, thank.  I've obviously not been paying attention since I got an
x86-64 system.

> You can minimise the tables by using the -fno-unwind-tables
> -fno-asynchronous-unwind-tables flags.  The code will work fine, as long
> as you are not debugging.

If you pass -g, I think those flags also work when debugging as the
tables are then written into special debug sections.  (This is just from
a bit of searching done since the issue came up so take with a pinch of
salt.)

> And on *nix it rarely matters that there is extra data like this in an
> executable file - those parts are typically not read in from files, so
> they take no memory at run-time.

And it seems you can save the file space by stripping them out
post-compile if you like (strip -R).  Again, not sure how reliable that
information is but I tried it on a few programs with no ill-effects.

It would appear not to be a very strong requirement of the ABI.

-- 
Ben.

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

#97279

Le 22/11/2016 à 15:58, David Brown a écrit :
> You can minimise the tables by using the -fno-unwind-tables
> -fno-asynchronous-unwind-tables flags.

I used -fno-unwind-tables with NO effect. Now there is another (yet 
another) option I should use?

Will try that (what a bore that compiler)

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

#97291

On 22/11/2016 17:01, jacobnavia wrote:

> Le 22/11/2016 à 15:58, David Brown a écrit :
>
>> You can minimise the tables by using the -fno-unwind-tables
>> -fno-asynchronous-unwind-tables flags.
> 
> I used -fno-unwind-tables with NO effect.

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

> -fexceptions
> 
> Enable exception handling. Generates extra code needed to propagate
> exceptions. For some targets, this implies GCC generates frame unwind
> information for all functions, which can produce significant data
> size overhead, although it does not affect execution. If you do not
> specify this option, GCC enables it by default for languages like C++
> that normally require exception handling, and disables it for
> languages like C that do not normally require it. However, you may
> need to enable this option when compiling C code that needs to
> interoperate properly with exception handlers written in C++. You may
> also wish to disable this option if you are compiling older C++
> programs that don't use exception handling.
> 
> -funwind-tables
> 
> Similar to -fexceptions, except that it just generates any needed
> static data, but does not affect the generated code in any other way.
> You normally do not need to enable this option; instead, a language
> processor that needs this handling enables it on your behalf.
> 
> -fasynchronous-unwind-tables
> 
> Generate unwind table in DWARF format, if supported by target
> machine. The table is exact at each instruction boundary, so it can
> be used for stack unwinding from asynchronous events (such as
> debugger or garbage collector).

Regards.

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

#97318

On 22/11/16 17:01, jacobnavia wrote:
> Le 22/11/2016 à 15:58, David Brown a écrit :
>> You can minimise the tables by using the -fno-unwind-tables
>> -fno-asynchronous-unwind-tables flags.
>
> I used -fno-unwind-tables with NO effect. Now there is another (yet
> another) option I should use?
>

Yes, the other flag I gave "-fno-asynchronous-unwind-tables".  According 
to my googling, this is the more important one, but the 
"-fno-unwind-tables" may also help.

There will still be a little bit of tables, from static libraries.  You 
could probably eliminate them with objcopy and the right choices of 
sections to keep and discard, but I have no idea whether the resulting 
binaries will work or not - tools such as the link-loader expect 
binaries to follow the platform ABI.

Note that this only affects the size of the binary file, not run-time 
speed.  And I expect that most of those parts of the binary file will 
not get paged into memory when the program is run, so the cost is just a 
little disk space - not unlike the cost of leaving debug information in 
the binary.

> Will try that (what a bore that compiler)
>

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

#97266 — [OT] It's only words... :)

 From "unnecessary changes" to "Negative effects"... interesting, Master!

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

#97267 — Re: [OT] It's only words... :)

Its only words ~ Bee Gees ~ Lyrics
https://www.youtube.com/watch?v=Iy_bJelwa0c

On 22/11/2016 10:55 PM, Mr. Man-wai Chang wrote:
>
> From "unnecessary changes" to "Negative effects"... interesting, Master!

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

#97301

On 11/22/16 11:18 PM, jacobnavia wrote:
> 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!

These have already been explained as no being just "exception handling 
tables".

> Another bad influence is that now the c committee has specified that if
> the programmer doesn't assign a return value to main it will default to
> zero. This makes it impossible for a compiler to warn aboyt the lack of
> assignment to the return value because the compiler can't distinguish
> between
> 1) The programmer forgot to assign the return value
> 2) The programmer doesn't assign a return value because he/she knows
> that it will be set to zero.

Has it taken you 17 years to realise that?

-- 
Ian

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

#97306

Le 22/11/2016 à 20:43, Ian Collins a écrit :
> These have already been explained as no being just "exception handling
> tables".

Excuse me but the objective of those tables is to realize the 
catch/throw mechanism. You are confusing those tables with the debug 
information, that has nothing to do with that.

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

#97307

Le 22/11/2016 à 20:43, Ian Collins a écrit :
>> Another bad influence is that now the c committee has specified that if
>> the programmer doesn't assign a return value to main it will default to
>> zero. This makes it impossible for a compiler to warn aboyt the lack of
>> assignment to the return value because the compiler can't distinguish
>> between
>> 1) The programmer forgot to assign the return value
>> 2) The programmer doesn't assign a return value because he/she knows
>> that it will be set to zero.
>
> Has it taken you 17 years to realise that?

Mystery. 17, seventeen years that I have been asking myself that 
existential question...

I remember complaining before, I do not remember if it was 17 years 
ago... probably not.

In any case I am surely not as clever as you that understands everything 
faster since you are c++ programmer

:-)

Those kind of cryptic sentences that should have been just silently 
ignored but...

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

#97370

On Tuesday, November 22, 2016 at 4:18:47 AM UTC-6, jacobnavia wrote:
> Another bad influence is that now the c committee has specified that if 
> the programmer doesn't assign a return value to main it will default to 
> zero. This makes it impossible for a compiler to warn aboyt the lack of 
> assignment to the return value because the compiler can't distinguish 
> between
> 1) The programmer forgot to assign the return value
> 2) The programmer doesn't assign a return value because he/she knows 
> that it will be set to zero.

I'm in firm agreement with you on the underlying issue you're really addressing by this: the ISO is cranking out "franchise-breakers" to the saga worse than what the 2001 Planet of the Apes did to that franchise, and it may be time to do a little rebooting and go maverick.

Note my just-posted comment on the novel syntax for an update operator.

But here's one issue that's really hit the sore spot for me. The "auto" keyword is woefully underused and ISO wants to waste a perfectly good legacy by trashing it ... only to replace its natural generalization with one of its 201x "keywords" (which look like warts on the language).

Take a close look at the places _thread_local is used. Inside a block it may only occur with static or extern, while auto may never occur with either. Outside it may freely be used, while auto may never be used.

The literal meaning of auto is to denote a variable that's heaped on the call frame for a subroutine. But the ESSENTIAL meaning is to denote a variable that's heaped on a separately called program thread -- regardless of whether it's called as a subroutine or spawned as a separate thread.

In a unified framework that embodies both cases, a subroutine itself may be regarded as equivalent to a thread that suspends its caller and then resumes the caller when it returns.

So, instead of phasing out the "auto" keyword only to replace it in these other contexts by another (wart of a) keyword, just simply use auto for all the contexts and do away with "thread_local" entirely.

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

#97373

On Wednesday, November 23, 2016 at 5:41:57 PM UTC-6, rockbr...@gmail.com wrote:
> But here's one issue that's really hit the sore spot for me. The "auto" keyword is woefully underused and ISO wants to waste a perfectly good legacy by trashing it ... only to replace its natural generalization with one of its 201x "keywords" (which look like warts on the language).

How about the "register" keyword?  Making the use of "register" on a variable
which is exposed to outside code or has its address taken is a constraint
violation, but if that weren't the case the keyword could serve as a useful
annotation that an lvalue will not have its value accessed using a pointer
*except* within the context of a sub-expression where its address is taken;
within such a context, one of two conditions must apply:

   1. All accesses to the lvalue must be performed using the result of the
      address-of operator or a pointer derived therefrom.

   2. All accesses to the lvalue by any means must be reads.

Allowing the "register" qualifier to be used in such fashion would give the
compiler useful information it would not otherwise have; given something
like:

    int foo(void)
    {
      register int x = 0;
      if (getvalue(&x))
      {
        x++;
        foo();
        x++;
        bar();
      }
      return x;
    }

present rules would require a compiler to pessimistically allow for the
possibility that "foo" and/or "bar" might access x unless it could see
into the code for them and/or "getvalue".  Defining the "register" keyword
as indicated would tell the compiler those functions won't access "x",
allowing it to be safely kept in a register across calls to them.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web