Monday, December 11, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

mcheung63@gmail.com: Dec 11 02:49AM -0800

linus clearly said c++ is not suitable for kernel dev many years ago. tools and lang keep enhancing, does the statement still valid?
thanks
Peter
"Öö Tiib" <ootiib@hot.ee>: Dec 11 09:03AM -0800

> linus clearly said c++ is not suitable for kernel dev many years
> ago. tools and lang keep enhancing, does the statement still
> valid?
 
Trolling much? C++ has been always suitable for kernel development.
 
What you mean by "enhancing"? Pile of features? Linus likely dislikes
C++ exactly because of that pile of features and hates programmers who
use it. He has every right for any emotion but emotions lack logic
validity.
scott@slp53.sl.home (Scott Lurndal): Dec 11 05:29PM

>> ago. tools and lang keep enhancing, does the statement still
>> valid?
 
>Trolling much? C++ has been always suitable for kernel development.
 
Well, a subset of C++ is suitable for kernel development. I've been
part of two operating systems and a hypervisor that were all written
in C++ (in one case, C++ and C). Limit yourself to C with classes
(don't use STL, don't use Exceptions, disable RTTI for performance).
woodbrian77@gmail.com: Dec 11 09:43AM -0800

On Monday, December 11, 2017 at 11:04:06 AM UTC-6, Öö Tiib wrote:
> > ago. tools and lang keep enhancing, does the statement still
> > valid?
 
> Trolling much? C++ has been always suitable for kernel development.
 
C++ has become a better language over the years, but I don't
think it's enough to change Linus' opinion on the subject.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
David Brown <david.brown@hesbynett.no>: Dec 11 07:11PM +0100

On 11/12/17 18:29, Scott Lurndal wrote:
> part of two operating systems and a hypervisor that were all written
> in C++ (in one case, C++ and C). Limit yourself to C with classes
> (don't use STL, don't use Exceptions, disable RTTI for performance).
 
There is a lot more to C++ than "C with classes", even when these are
avoided. I agree that disabling exceptions and RTTI are a good idea for
the kind of coding you want in an OS, and that the STL /can/ lead to
unexpected or unpredictable performance, memory fragmentation, and other
performance issues. But there is still a lot left beyond "C with
classes" - templates, strong typing, compile-time programming, better
structure (through namespaces, stronger const, enum classes), etc.
 
I'd say if someone were writing a new OS kernel and did not choose C++
over C, then they simply don't understand C++. (Rust also seems to be a
popular choice, but is as yet too immature for my liking.) But when you
have a large existing code base like the Linux kernel, it's hard to change.
 
And when you have a strongly opinionated leader, like Linus Torvalds,
it's even harder. (Being strong opinionated is not a bad trait for a
leader, within reason - sometimes it is more important to make firm
decisions than to make the /best/ decisions. And Linux seems to be
doing fine in C.)
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 11 06:29PM

On 11/12/2017 18:11, David Brown wrote:
> the kind of coding you want in an OS, and that the STL /can/ lead to
> unexpected or unpredictable performance, memory fragmentation, and other
> performance issues.  But there is still a lot left beyond "C with
 
There is no reason why use of the STL should result in memory
fragmentation or unpredictable performance. I would use it quite
happily if doing kernel dev however I wouldn't use the default allocator
as far as containers are concerned as that will likely use Userland
malloc. I would also make the custom allocator such that it panics the
kernel rather than throw an exception if any allocation arena becomes
full. It would be nice if exceptions could be enabled and caught at
highest level translating it into a panic but I haven't looked into what
would be involved in doing that.
 
/Flibble
scott@slp53.sl.home (Scott Lurndal): Dec 11 06:29PM

>>=20
 
>C++ has become a better language over the years, but I don't
>think it's enough to change Linus' opinion on the subject.
 
It's almost sure to reinforce his opinion. Very little in
C++11, 14 and 17 is of interest to an operating system developer.
woodbrian77@gmail.com: Dec 11 10:40AM -0800

On Monday, December 11, 2017 at 12:29:59 PM UTC-6, Scott Lurndal wrote:
> >think it's enough to change Linus' opinion on the subject.
 
> It's almost sure to reinforce his opinion. Very little in
> C++11, 14 and 17 is of interest to an operating system developer.
 
Maybe modules would help, but that's C++ 2020.
David Brown <david.brown@hesbynett.no>: Dec 11 08:23PM +0100

On 11/12/17 19:29, Mr Flibble wrote:
> full.  It would be nice if exceptions could be enabled and caught at
> highest level translating it into a panic but I haven't looked into what
> would be involved in doing that.
 
It is certainly /possible/ to use the STL here - but it is also possible
that you get unpredictable performance. If you have a good enough
implementation of the STL, use custom allocators, etc., and are careful
about what you are doing, it should be okay. But the STL is made to be
easy to use for applications - not to be predictable and controllable
for low-level work. For applications, it's great that a std::vector
grows automatically when needed - but for an OS, that is likely to be
exactly what you /don't/ want because your function could suddenly take
much longer to execute than it usually does.
 
There are alternatives, like the EASTL, that have a better balance for
things like OS kernels than the normal STL. (I haven't tried it myself
- one day, when I have time.)
Ian Collins <ian-news@hotmail.com>: Dec 12 08:24AM +1300

On 12/12/2017 07:29 AM, Mr Flibble wrote:
> full. It would be nice if exceptions could be enabled and caught at
> highest level translating it into a panic but I haven't looked into what
> would be involved in doing that.
 
The biggest problem with the standard library (I really do hate the
obsolete term "STL"!) is there isn't any formal distinction between the
standalone, header only, bits and the rest. It there were, you could
safely use something like <array> or <algorithm> knowing you wouldn't be
dragging in something that requires run time support.
 
In most cases you have to disable exceptions and RTTI to eliminate any
run time dependencies.
 
--
Ian
Ian Collins <ian-news@hotmail.com>: Dec 12 08:28AM +1300

On 12/12/2017 07:29 AM, Scott Lurndal wrote:
>> think it's enough to change Linus' opinion on the subject.
 
> It's almost sure to reinforce his opinion. Very little in
> C++11, 14 and 17 is of interest to an operating system developer.
 
constexpr certainly is, along with enum class, atomics and all of the
other bits that suit embedded development. C++ >=11 is a better
language for both embedded and kernel development.
 
--
Ian
scott@slp53.sl.home (Scott Lurndal): Dec 11 07:50PM

>happily if doing kernel dev however I wouldn't use the default allocator
>as far as containers are concerned as that will likely use Userland
>malloc.
 
Have you ever written a kernel? A traditional heap allocator
is a non-starter. Memory allocation and avoiding fragmentation is a
key function of an operating system. My experience with STL
has be don't even bother in an operating system.
scott@slp53.sl.home (Scott Lurndal): Dec 11 07:54PM


>constexpr certainly is, along with enum class, atomics and all of the
>other bits that suit embedded development. C++ >=11 is a better
>language for both embedded and kernel development.
 
Yes, those small features can be useful, as is static_assert. But
very little else. Lambdas may make some people happy, but they're
not likely to find much use in a kernel that avoids STL. Although even atomics
may be too high-level to replace the __sync_* functions GCC uses
to expose the low-level primitives.
Ian Collins <ian-news@hotmail.com>: Dec 12 09:03AM +1300

On 12/12/2017 08:50 AM, Scott Lurndal wrote:
> is a non-starter. Memory allocation and avoiding fragmentation is a
> key function of an operating system. My experience with STL
> has be don't even bother in an operating system.
 
You use custom allocators to eliminate fragmentation or maintaining
locality of reference with the standard library.
 
--
Ian.
legalize+jeeves@mail.xmission.com (Richard): Dec 11 08:12PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>constexpr certainly is, along with enum class, atomics and all of the
>other bits that suit embedded development. C++ >=11 is a better
>language for both embedded and kernel development.
 
Kvasir is a case in point. <http://kvasir.io>
 
Watch the videos.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
David Brown <david.brown@hesbynett.no>: Dec 11 09:13PM +0100

On 11/12/17 19:29, Scott Lurndal wrote:
>> think it's enough to change Linus' opinion on the subject.
 
> It's almost sure to reinforce his opinion. Very little in
> C++11, 14 and 17 is of interest to an operating system developer.
 
For my work, which is low-level programming on small embedded systems
(not OS's, but near enough), I mostly use C (for many reasons - some
good, some bad). But for C++, there are some really nice things in
C++11, C++14 and C++17 for such coding:
 
constexpr (C++11, improved in C++14 and C++17)
 
auto (because it makes things easier)
 
override, final, nullptr, enum class, explicit conversion operators -
they all make it easier to write safer code with better static error
checking.
 
static_assert (it could be done by macros before, but the language
feature is a bit neater)
 
user define literals work well with strong types.
 
threads and atomics are clearly a win for low-level and OS code.
 
smart pointers are a win for everyone (though auto_ptr was okay too).
 
 
C++14 added a few things, like improved constexpr and conveniences like
more type deduction, binary literals and digit separators, and some more
generalisations.
 
C++17 has a few more nice things that make it easier to write correct
code, like std::optional and std::variant. if constexpr is another nice
point.
 
In general, C++11 onwards have made it easier to write clear and correct
code, made it easier to write generic code (which can then be used for
more strong type checking), and /far/ easier to do compile-time
generation. This all leads to safer coding, more productive coding, and
more efficient coding - all important things for an OS developer. To
me, C++ was not worth considering until C++11.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 11 05:46PM +0100

The logic in the code below bothers me, it feels unclean due to the
double testing of whether a character is newline or not.
 
(Notation: here `ref_<T>` denotes `T&`, `raw_array_of_<n,T>` is `T[n]`,
and the corresponding `array_of_<n,T>` is `std::array<T,n>`. The
definitions are trivial and are available e.g. in my /stdlib/ library,
header `<stdlib/extension/type_builders.hpp>`.)
 
 
const raw_array_<wchar_t> flowed_about_text = LR"(
Let 𝘜 be the encoding last saved as default, or, if that encoding isn't
Unicode,➲
let 𝘜 be UTF-8 with BOM.
 
When a buffer is activated and has not already been checked:
 
if the document is empty and its encoding isn't Unicode, then
its encoding is set to 𝘜.
 
Ideally the "when a buffer…" should have been "when file a is opened or➲
a new document is created", but➲
apparently Notepad++ does not inform a plugin of its creation of new➲
documents. Also, ideally the forced encoding should have been the one➲
currently selected as default in Notepad++, but apparently Notepad++
does not➲
make the dynamic configuration info available to a plugin.
 
Author's mail address: alf.p.steinbach+npp@gmail.com)";
 
template< class Char, U_size n >
auto unflowed( ref_<raw_array_of_<n, const Char>> flowed_text )
-> array_of_<n, Char>
{
array_of_<n, Char> result;
bool last_was_continuation_char = true; // Skip newline at
start.
ptr_<wchar_t> p_out = &result[0];
for( const wchar_t ch: flowed_text )
{
if( last_was_continuation_char and ch != L'\n' )
{
*p_out++ = L'➲';
}
switch( ch )
{
case L'➲':
{
last_was_continuation_char = true;
continue; // Copy this '➲' next time if
appropriate.
}
case L'\n':
{
if( last_was_continuation_char ) {}
else
{
*p_out++ = L'\n';
}
break;
}
default:
{
*p_out++ = ch;
break;
}
}
last_was_continuation_char = false;
}
*p_out = L'\0';
return result;
}
 
auto const about_text = unflowed( flowed_about_text );
 
 
I know of one alternative, to completely dispense with the logic and
just use Very Long Lines in the string literal. But that also feels wrong.
 
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): Dec 11 05:10PM

[Please do not mail me a copy of your followup]
 
I see lots of weird formatting when I view this in my newsreader (trn),
but it's probably because you're using UTF-8 for characters that are
perfectly representable in ASCII and my newsreader is old.
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>The logic in the code below bothers me, it feels unclean due to the
>double testing of whether a character is newline or not.
 
Are you referring to the test against the character literal in the if
statement and further down in the switch as the duplicate testing?
 
> {
> *p_out++ = L'\xe2\x9e\xb2';
> }
 
How can you have a character literal with three bytes in it? If you
want a unicode character literal, isn't it more portable to specify
the character code via \u or \U?
 
...or is this your news software transliterating something?
 
I have no idea what your source character encoding is that you're
using, so perhaps this is valid code in it's original form.
 
IMO, it is better to use \u/\U for unicode characters outside of
ASCII, particularly when posting across forums.
 
> return result;
> }
 
> auto const about_text = unflowed( flowed_about_text );
 
It seems you either have the state as local inline variables as you've
done it here, or you encapsulate the state in some kind of class that
does part of the work. But I don't see how encapsulating it as a class
makes any real difference because this class is already doing
low-level character-by-character work and I don't see any way to
extract out a simpler responsibility.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 11 06:29PM +0100

On 12/11/2017 6:10 PM, Richard wrote:
>> double testing of whether a character is newline or not.
 
> Are you referring to the test against the character literal in the if
> statement and further down in the switch as the duplicate testing?
 
Yes.
 
 
>> *p_out++ = L'\xe2\x9e\xb2';
>> }
 
> How can you have a character literal with three bytes in it?
 
What you see is the UTF-8 encoding of Unicode character 'CIRCLED HEAVY
WHITE RIGHTWARDS ARROW' (U+27B2), that I thought would work nicely
visually as a line continuation character (tried various arrows first).
 
 
> If you
> want a unicode character literal, isn't it more portable to specify
> the character code via \u or \U?
 
The source code is UTF-8, so it's no problem just using Unicode
characters directly.
 
 
> ...or is this your news software transliterating something?
 
No, I looked at the posted raw message text. It's OK:
 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
 
So it's probably trn that's the culprit here.
 
 
> I have no idea what your source character encoding is that you're
> using, so perhaps this is valid code in it's original form.
 
Yes, it's UTF-8 encoded source. I think all source code now should be
UTF-8 encoded :)
 
 
> makes any real difference because this class is already doing
> low-level character-by-character work and I don't see any way to
> extract out a simpler responsibility.
 
Hm, well, it feels redundant, awkward, somehow.
 
Like there is some really simple elegant way to do it that just refuses
to pop up in my brain.
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Dec 11 10:28AM -0800

On Monday, 11 December 2017 18:47:17 UTC+2, Alf P. Steinbach wrote:
> The logic in the code below bothers me, it feels unclean due to the
> double testing of whether a character is newline or not.
 
Ok, I jump to for cycle that as I understood bothers you:
 
> }
> last_was_continuation_char = false;
> }
 
I would get rid of switch and so then write it like:
 
for (const wchar_t ch: flowed_text)
{
if (last_was_continuation_char and ch != L'\n')
{
*p_out++ = L'➲';
}
if (ch == L'➲')
{
last_was_continuation_char = true;
continue; // Copy this '➲' next time if appropriate.
}
if (!last_was_continuation_char or ch != L'\n')
{
*p_out++ = ch;
}
last_was_continuation_char = false;
}
 
It seems like 1/3 shorter and 1/3 cleaner too ... however on such
cases I trust unit tests more than my head. :D May be I misunderstood
your logic and so I am not 100% sure that it actually does same thing. ;)
legalize+jeeves@mail.xmission.com (Richard): Dec 11 06:45PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>Like there is some really simple elegant way to do it that just refuses
>to pop up in my brain.
 
Some standard algorithm perhaps?
 
If you're just stripping your internal "continuation" character, then
isn't it just copy_if?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
woodbrian77@gmail.com: Dec 11 10:36AM -0800

> https://github.com/Ebenezer-group/modwards
 
> for the modules version of the code. I'm not sure
> what to do next though in the process.
 
Are there any suggestions for first steps in this?
Maybe trying to import the standard library rather
than including vector, etc?
 

Brian
Ebenezer Enterprises
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): Dec 11 04:16AM

[Please do not mail me a copy of your followup]
 
bartc <bc@freeuk.com> spake the secret code
 
>Finally, a C++17 feature (in fact a C++ feature) I can understand.
 
>Yes, this is just a byte type, that doesn't do anything clever. Why did
>it take so long to figure out that it was needed?
 
You seem to be unfamiliar with how the standardization process works.
 
For everything in the standard, someone has to propose it, defend the
proposal and shepherd the proposal through the entire process. Yes,
this includes even something as simple as std::byte. If noone does
this work, it doesn't end up in the standard despite whatever you may
perceive as the "need" for it.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Öö Tiib" <ootiib@hot.ee>: Dec 10 10:52PM -0800

On Friday, 8 December 2017 23:22:25 UTC+2, jacobnavia wrote:
> used by whoever wrote the stuff. Luckily for me, I learn the subsets
> used by the authors (or ask them), and then I forget them as soon as I
> can when the job is done, to make place for whatever new subset I will find.
 
Lot of software development is actually maintenance. Do you really
maintain different software each few months? Why? It sounds very
unusual maintenance. Most maintenance that I know of releases a new
patch every few months and so it goes on for decades.
 
> Well, luckily for me, most C++ software is written by people that use
> 0.1% of C++. Still, following unknown code is a nightmare.
 
A person sits behind computer, drinks some warm beverages and solves
there some puzzle. Is the puzzle "boring", "tiresome", "interesting",
"challenging", "problematic", "painful" or outright "nightmare"?
On what that depends?
David Brown <david.brown@hesbynett.no>: Dec 11 10:19AM +0100

On 11/12/17 05:16, Richard wrote:
> this includes even something as simple as std::byte. If noone does
> this work, it doesn't end up in the standard despite whatever you may
> perceive as the "need" for it.
 
Plus, std::byte was /not/ needed. It is helpful, perhaps, and could
make code clearer and reduce the risk of mistakes since you cannot use
arithmetic on std::byte (as you can on "char", "unsigned char" or
"uint8_t" - the popular alternatives). But std::byte can't do anything
you could not already do with "unsigned char" - indeed, it is the /lack/
of features in std::byte that is its strength. Personally, I don't
think the bitwise operators should have been allowed either.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)