Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18836
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: reasons for preferring C over C++ |
| Date | 2014-10-20 02:47 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <pan.2014.10.20.01.47.36.118000@nowhere.invalid> (permalink) |
| References | (2 earlier) <caf18hF6lueU1@mid.individual.net> <7x4mv1tdyv.fsf@ruckus.brouhaha.com> <VUA0w.496001$_u1.143324@fx30.am4> <7x8ukd9f0c.fsf@ruckus.brouhaha.com> <KZ-dnWseYsinotnJnZ2dnUU7-L-dnZ2d@giganews.com> |
On Sun, 19 Oct 2014 17:46:18 -0500, Tim Wescott wrote: > gnu C has a way of defining a function as "link this only if you need it" > (with attribute ((__weak__)), IIRC). It basically makes a function act > like a function in a library, even though it's been compiled into a .o > file. If they use that method with templatized methods, then only one > will get included in the link, even if multiple copies are scattered > around in the object files. > > I don't KNOW that they use that, but I'd be surprised if they didn't. The usual behaviour for g++ is to instantiate the template in each object file, and leave it to the linker to remove duplicates. If the linker doesn't support that, there are switches to either track template instantiations so that they can be compiled and linked separately (-frepo), or to suppress automatic instantiation and require the code to explicitly instantiate any templates which it uses (-fno-implicit-templates). https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html However, that isn't what Paul was talking about. While exact duplicates can be removed, if you instantiate a template several times with different parameters, each distinct set of parameters will get its own customised version of the template code. This allows for maximum optimisation, as each individual instantiation has all of its parameters fixed at compile time. But it does result in code bloat relative to languages which generate one set of code which handles polymorphism by accepting parameters at run time. The designer of the template may be able to minimise bloat by identifying large sections of code which are only weakly dependent upon the parameters. E.g. there could be portions of code which only care about the type's size, and generating different versions for different sizes would have negligible benefit (particularly on a system with a fast multiply). So the template code could delegate such tasks to a non-template helper function which takes the size as a (run-time) parameter. Unfortunately, this isn't particularly straightforward for container templates, as core operations such as copy, move, assign, swap, etc may have to use the relevant type-specific methods or overloads, and using indirect calls for such primitive operations would hurt performance badly. So if you want to go down that route, you have to manually "dissect" the parameters using type traits such as is_trivial or is_trivially_copyable etc in order to delegate to less-specialised templates where possible while retaining full specialisation where necessary (or where the alternatives are impractical).
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:21 +0200
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 10:36 -0700
Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:48 +0200
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 21:25 +0100
Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:28 +0200
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 23:40 +0100
Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 10:58 -0700
Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-15 21:03 +0300
Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 11:11 -0700
Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 20:26 +0200
Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-15 20:44 +0200
Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:30 +0200
Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-16 18:19 +0200
Re: reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-16 23:12 +0200
Re: reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-17 13:25 +0800
Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-17 18:43 +0200
Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-18 12:29 +0100
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:44 -0700
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:25 +0100
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 15:42 -0700
Re: reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 11:03 +0300
Re: reasons for preferring C over C++ Tim Wescott <seemywebsite@myfooter.really> - 2014-10-19 17:46 -0500
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 16:28 -0700
Re: reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 02:47 +0100
Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:34 +0100
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:00 -0700
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:50 +0100
Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:57 +0100
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 12:11 +0100
Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-20 22:36 +0300
Re: reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:36 +0000
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:52 +0100
Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:56 +0100
Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-19 10:52 +0200
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:16 -0700
Re: reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:02 +0000
Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:45 +0100
Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-15 22:12 +0200
Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:35 +0200
Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 19:10 -0700
Re: reasons for preferring C over C++ Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-16 10:34 +0300
Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-16 10:10 +0100
Re: reasons for preferring C over C++ Tim Wescott <tim@seemywebsite.com> - 2014-10-16 01:06 -0500
Re: reasons for preferring C over C++ Anders.Montonen@kapsi.spam.stop.fi.invalid - 2014-10-16 08:32 +0000
Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-16 20:54 +0200
csiph-web