lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 04 Sep 2014 13:58:36 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Alexander Holler <holler@...oftware.de>,
	Peter Zijlstra <peterz@...radead.org>
CC:	Borislav Petkov <bp@...en8.de>,
	Måns Rullgård <mans@...sr.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christopher Barry <christopher.r.barry@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: OT: Open letter to the Linux World

On 2014-09-04 13:29, Alexander Holler wrote:
> Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
>> On 2014-09-04 06:16, Alexander Holler wrote:
>>>
>>> It's a myth that C++ ends up in bigger code than C. At least in my
>>> experience. Especially when the latest additions to C++ are in effect
>>> (like the move-semantics in C++11 I like quiet a lot and which you get
>>> almost for free (by changing nothing) when you use the STL). Thread
>>> support is now also standardized (in C++11), quiet nice to use.
> 
>> Assuming you are writing in a standalone environment (no standard
>> libraries), then yes, your code will usually be about the same size
>> (unless you go way overboard with the object-oriented stuff); but the
>> runtime is larger in almost all non-standalone environments, and there
>> are some cases that code does end up larger in C++.  A lot of 'Clean C'
>> (stuff written so that it compiles correctly as C, C++ and Objective C)
>> that I have seen seems to end up larger (by about 4-6%) when built as
>> C++ (although it usually does much worse as Objective C).
> 
> There are always corner cases and I never would use some "Clean C" code
> to compare sizes of C and C++. There is a whole lot of stuff you just
> can't, shouldn't or wouldn't do when using C instead of C++.
> 
> And just throwing in some numbers without any explanation about features
> (like exceptions), optimizations and so on you've enabled for the tests
> you used to get those numbers, doesn't work. ;)
> 
> I can't really comment on what you mean with "standalone environment" or
> "non-standalone environment", as I don't know what you mean with that.
> But if several programms share e.g. the stuff which is in libstdc++.
> you'll get a lot of size back when compared with C-only programms where
> everyone invents the wheel again and again.
By standalone environment, I mean no libraries, no libc[++], no external
dependencies, and in the case of a lot of kernel programming, no
built-ins.  A OS kernel HAS to be written like that, and it's easier to
do that in C than C++.  I doubt that you have ever looked at any source
code for Windows drivers, but Windows is written in C++, and they still
are just as mind-numbingly insane as some of the poorly maintained,
vendor originated Linux drivers.
Not all C is like the Linux kernel, and in fact, if you use Linux,
probably more than half of your user-space programs were written in C.
They use dynamic linking just like C++ programs (but often with less
complex symbol mangling).


Download attachment "smime.p7s" of type "application/pkcs7-signature" (2455 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ