linus

[mche...@gmail.com]

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]

On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com wrote:
> 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 Lurndal]

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com wrote:
>> 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.

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).

[woodb...@gmail.com]

On Monday, December 11, 2017 at 11:04:06 AM UTC-6, Öö Tiib wrote:
> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com wrote:
> > 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.
>

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]

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]

On 11/12/2017 18:11, David Brown wrote:
> On 11/12/17 18:29, Scott Lurndal wrote:
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>>> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com  wrote:
>>>> 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.
>>
>> 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).
>>
>
> 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

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 Lurndal]

woodb...@gmail.com writes:

>On Monday, December 11, 2017 at 11:04:06 AM UTC-6, =C3=96=C3=B6 Tiib wrote:
>> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com wrote:
>> > linus clearly said c++ is not suitable for kernel dev many years
>> > ago. tools and lang keep enhancing, does the statement still
>> > valid?

>>=20
>> Trolling much? C++ has been always suitable for kernel development.=20
>>=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.

[woodb...@gmail.com]

Maybe modules would help, but that's C++ 2020.

[David Brown]

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]

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]

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 Lurndal]

Mr Flibble <flibbleREM...@i42.co.uk> writes:
>On 11/12/2017 18:11, David Brown wrote:
>> On 11/12/17 18:29, Scott Lurndal wrote:
>>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>>>> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com  wrote:
>>>>> 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.
>>>
>>> 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).
>>>
>>
>> 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
>
>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.

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 Lurndal]

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]

You use custom allocators to eliminate fragmentation or maintaining
locality of reference with the standard library.

--
Ian.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<f984i7...@mid.individual.net> thusly:

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

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.

[Mr Flibble]

I hope you don't think (a lot of people do this) that using the STL
means use std::vector everywhere. You are correct std::vector isn't
appropriate for kernel dev due to likelihood of making a bad allocation
decision/mistake.

When I use the STL for Userland dev I use the full array of containers
available based on what container properties are appropriate for the
task in hand. For kernel dev a pool allocator + std::list is probably
the way to go rather than std::vector.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[David Brown]

It is all about using the right tool for the job. That might be
std::list, or std::array (which should be zero overhead). But whatever
you use, you need to be careful - depending on what you use, your custom
allocators, your compiler flags, your library versions, etc., it is easy
to end up pulling in lots more into your code than you intended. In my
world, you want your OS to be small (a few KB) - you don't want to
accidentally pull in malloc, exception handling, printf, software
floating point routines, and all sorts of things that can be used by
large template libraries behind the scenes. (This really happens.)

On the other hand, you don't want to spend time and effort reinventing
the wheel when you want a hash table.

So I am not saying "don't use the STL" - I am saying be careful with it,
and consider different implementations of similar libraries.

[David Brown]

Lambdas are not related to the STL or standard library. If you find
them convenient syntax, use them - if not, don't. They don't give you
anything you could not do before, they just provide another syntax that
can be neater than normal functions in some places.

static_assert is /immensely/ useful, IMHO. But you could get the
effects with macros pre C++11 - it's just the error messages were obscure.

[Ian Collins]

On 12/12/2017 09:52 AM, David Brown wrote:
>
> Lambdas are not related to the STL or standard library.

The STL became part of the standard library in 1998, it is no longer a
distinct entity!

--
Ian.

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:
> Thunderbird/52.5.0

>> 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.
>
>You use custom allocators to eliminate fragmentation or maintaining
>locality of reference with the standard library.

You can, but why? The overhead of most STL containers makes them
unsuitable for real-time (which is the definition of a kernel).

[Ian Collins]

The overhead isn't an issue, containers such as std::array don't have
any and std::vector has no more than the equivalent hand written code.
We use std:deque with a custom allocator in or driver layer. Yes we
could probably roll something more specialised, but why bother?

The real problem is run time support library dependency. You can work
around this to some extent by using a static run time library, but
that's far from ideal.

--
Ian.

[Vir Campestris]

On 11/12/2017 21:17, Scott Lurndal wrote:
> The overhead of most STL containers makes them
> unsuitable for real-time (which is the definition of a kernel).

That's far from the only thing you'll find in an operating system. Even
if you don't want to put a hashmap in your kernel to hold the process
control blocks you might find it very handy to hold networking information.

Back to Linus - I hate his coding standards. It feels as though he
develops on an 80x25 green screen - we've got beyond that (1)

But they are strongly enforced. And that is worth a heck of a lot.

Andy
--
(1) But I still have one. It's to scare the grandchildren with, if I
ever have any. It's already scared my kids, along with the 5MB hard disc!

[thiago...@gmail.com]

On Monday, December 11, 2017 at 4:29:35 PM UTC-2, Mr Flibble wrote:
> On 11/12/2017 18:11, David Brown wrote:
> > On 11/12/17 18:29, Scott Lurndal wrote:

> >> =?UTF-8?B?w5bDtiBUaWli?= writes:
> >>> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com  wrote:
> >>>> 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.
> >>
> >> 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).
> >>
> >
> > 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
>
> There is no reason why use of the STL should result in memory
> fragmentation or unpredictable performance.

If you use a vector with the default allocator, and you don't use
reserve then you can create fragmentation.
For embedded systems the first option is not use dynamic allocation.

[thiago...@gmail.com]

On Monday, December 11, 2017 at 5:24:02 PM UTC-2, David Brown wrote:
...

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

I think trying to customize STL is more complicated than create a small
custom vector class and will requires a lot of details to be understood and
the code is prepared to be generic and solve problems that the specific
code doesn't have to solve.
Generic code can be dangerous when you try to solve problems that you
don't have.

[thiago...@gmail.com]

On Monday, December 11, 2017 at 5:28:19 PM UTC-2, Ian Collins wrote:
...

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

I haven't seen big advantages in constexpr for functions.
I can clearly see disadvantages in compilation time.

For instance, let's say I have a function to calculate
some value.

factorial(5);

This function will run in each compilation.

Comparing with C solution.

#define FACTORIAL_FIVE 120

or a better name with better meaning in the context, maybe even
better than factorial(5).

I am not saying that we cannot find some application for
constexpr, but I am saying that I would consider a calculate-once
solution instead of calculate in each compilation solution.

[thiago...@gmail.com]

On Monday, December 11, 2017 at 6:14:05 PM UTC-2, David Brown wrote:
> On 11/12/17 19:29, Scott Lurndal wrote:
> > writes:
> >> On Monday, December 11, 2017 at 11:04:06 AM UTC-6, =C3=96=C3=B6 Tiib wrote:
> >>> On Monday, 11 December 2017 12:50:19 UTC+2, mche...@gmail.com wrote:
> >>>> linus clearly said c++ is not suitable for kernel dev many years
> >>>> ago. tools and lang keep enhancing, does the statement still
> >>>> valid?
> >>> =20
> >>> Trolling much? C++ has been always suitable for kernel development.=20
> >>> =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.
> >
>
> 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.

The problem I see with nullptr and enum class is that for an existing
code base or when integrating with some other library (C for instance)
the code becomes mixed in style. The same for using or typedef.
Or new style for function declaration.

For override/final and deleted/default especial functions this
problem is not so big but you can
have classes already updated and others not. (I think clang has a tool to
upgrade C++ code, this could be used to add override )

The word 'virtual' could be used optionally in the past
the show when a function was virtual. Now override has a role
and also can show that a function is virtual.
This also creates two options in style.

class X
{
virtual void F() override;
void F() override;
}

In general, when we have two options to do something the programmers
will argue in style, or they will try to find some minimal reason
to choose between one style or other creating small decision ifs
in their heads. The code can be mixed as well because each programmer
wants to use a different style or just to show that there is a new
option to use.
The same already happens with static functions x anonymous namespaces,
or tabs X spaces or the style of braces or inline in member function X none.

This kind of 'problem' is just drag for software development. At same
time, this is not something to blame (too much) C++ because the language needs
to be compatible with the previous versions.

[JiiPee]

On 11/12/2017 17:29, Scott Lurndal wrote:
>
> Limit yourself to C with classes
> (don't use STL, don't use Exceptions, disable RTTI for performance).

How about new C++ features like unique pointers and lambdas etc? shared
pointers.

std::string and std::vector not usable? also I understood that
std::array has no overhead, why would it be bad to use?

[David Brown]

On 15/12/17 12:44, thiago...@gmail.com wrote:
> On Monday, December 11, 2017 at 5:28:19 PM UTC-2, Ian Collins wrote:
> ...
>> 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.
>
> I haven't seen big advantages in constexpr for functions.
> I can clearly see disadvantages in compilation time.
>
> For instance, let's say I have a function to calculate
> some value.
>
> factorial(5);
>
> This function will run in each compilation.
>
> Comparing with C solution.
>
> #define FACTORIAL_FIVE 120

That is /not/ the C equivalent. The C equivalent would be:

#define FACTORIAL_FIVE (5 * 4 * 3 * 2 * 1)

or perhaps:

#define FACTORIAL_ONE 1
#define FACTORIAL_TWO (2 * FACTORIAL_ONE)
#define FACTORIAL_THREE (3 * FACTORIAL_TWO)
#define FACTORIAL_FOUR (4 * FACTORIAL_THREE)
#define FACTORIAL_FIVE (5 * FACTORIAL_FOUR)
#define FACTORIAL_BAD (1 / 0)

#define FACTORIAL(x) (x == 1 ? FACTORIAL_ONE : x == 2 ? FACTORIAL_TWO \
: x == 3 ? FACTORIAL_THREE : x == 4 ? FACTORIAL_FOUR \
: x == 5 ? FACTORIAL_FIVE : FACTORIAL_BAD)

Clearly, factorial is not a great example for this sort of thing.

A better example would be a table of sine values for an embedded motor
controller, or a generating hashes of strings used to look up
translation files, or a table of CRC values.

In C++, the solution is now to use constexpr, perhaps initialising an
array. In C, the solution is to give up and write a program to generate
the data in a separate file, that you then #include in your C code. (I
have done that for these three examples.)

>
> or a better name with better meaning in the context, maybe even
> better than factorial(5).
>
> I am not saying that we cannot find some application for
> constexpr, but I am saying that I would consider a calculate-once
> solution instead of calculate in each compilation solution.
>

There can be times when the compilation in C++ would be so long that
this is relevant - you would not want a constexpr Akerman function with
a multi-precision integer class. But there is a big step before you get
there. And with C++14's unrestricted constexpr functions, this sort of
thing is /much/ easier to write, and much more efficient, than the old
recursive templates from pre-C++11.

[David Brown]

These are new features. If you mix them with old code, things will look
a bid odd. That's life in the programming world - it is not a reason to
stop progress! You always have to make the choice - do I write this
code in the old way to be consistent with other old code, or do I take
advantage of the new features to write better code?

>
> For override/final and deleted/default especial functions this
> problem is not so big but you can
> have classes already updated and others not. (I think clang has a tool to
> upgrade C++ code, this could be used to add override )
>

clang's tool can help automate updates of some features of C++. I
haven't tried it.

> The word 'virtual' could be used optionally in the past
> the show when a function was virtual. Now override has a role
> and also can show that a function is virtual.
> This also creates two options in style.
>
> class X
> {
> virtual void F() override;
> void F() override;
> }
>
> In general, when we have two options to do something the programmers
> will argue in style, or they will try to find some minimal reason
> to choose between one style or other creating small decision ifs
> in their heads. The code can be mixed as well because each programmer
> wants to use a different style or just to show that there is a new
> option to use.
> The same already happens with static functions x anonymous namespaces,
> or tabs X spaces or the style of braces or inline in member function X none.
>
> This kind of 'problem' is just drag for software development. At same
> time, this is not something to blame (too much) C++ because the language needs
> to be compatible with the previous versions.
>

Yes, it is an unavoidable problem. In some cases, older styles can be
deprecated or there can be warnings added to implementations.

[Ian Collins]

On 12/16/2017 02:23 AM, David Brown wrote:
> On 15/12/17 13:09, thiago...@gmail.com wrote:
>> For override/final and deleted/default especial functions this
>> problem is not so big but you can
>> have classes already updated and others not. (I think clang has a tool to
>> upgrade C++ code, this could be used to add override )
>>
>
> clang's tool can help automate updates of some features of C++. I
> haven't tried it.

I have use clan modernise, on a large code base, and it worked
surprising well.

--
Ian

[Paavo Helde]

On 15.12.2017 14:09, thiago...@gmail.com wrote:
> The problem I see with nullptr and enum class is that for an existing
> code base or when integrating with some other library (C for instance)
> the code becomes mixed in style. The same for using or typedef.
> Or new style for function declaration.

You are confusing the goal and the means. Consistent style is not a
goal, it's just a way to produce more maintainable and reliable programs
(which are also just some specific means for solving some real world
problems).

If mixed-style code means more reliable and maintainable code than
non-mixed old-style, then it's better, not worse.

Cheers
Paavo

[Thiago Adams]

On Friday, December 15, 2017 at 6:09:55 PM UTC-2, Paavo Helde wrote:

If you are trying to create more reliable and maintainable
code mixing styles (updating partially enuns or null for instance)
then you have opposite forces in your source code, because more styles
means more complex code and more difficult to read.

In case you have a new junior colleague, he will ask. "Why the code
sometimes have 0 or NULL or null_ptr? What is the difference between enum
and enum class? When I use one or other?"

The ideal code would have only null_ptr and the junior college would
never ask the difference and the complexity would be hidden.


The other opposite force for new style is the question.
"should I make my code incompatible with C only by this enum class?"

When you start to make your code incompatible with C, then adding
one more incompatibility is not a problem because your code
is already incompatible.

"I am using a enum class so I will use more C++ 11 14 17 features."

C++ 17 or C++ 20 or "modern C++" doesn't look C anymore.

We should ask yourselves.
What is the point in to have a language compatible with C if
the language is completely different?

[Ian Collins]

On 12/16/2017 03:28 PM, Thiago Adams wrote:
> On Friday, December 15, 2017 at 6:09:55 PM UTC-2, Paavo Helde wrote:
>> On 15.12.2017 14:09, wrote:
>>> The problem I see with nullptr and enum class is that for an existing
>>> code base or when integrating with some other library (C for instance)
>>> the code becomes mixed in style. The same for using or typedef.
>>> Or new style for function declaration.
>>
>> You are confusing the goal and the means. Consistent style is not a
>> goal, it's just a way to produce more maintainable and reliable programs
>> (which are also just some specific means for solving some real world
>> problems).
>>
>> If mixed-style code means more reliable and maintainable code than
>> non-mixed old-style, then it's better, not worse.
>>
>
> If you are trying to create more reliable and maintainable
> code mixing styles (updating partially enuns or null for instance)
> then you have opposite forces in your source code, because more styles
> means more complex code and more difficult to read.

All code bases evolve over time. Would you have us keep to the features
available when a decades old code base started?

> In case you have a new junior colleague, he will ask. "Why the code
> sometimes have 0 or NULL or null_ptr? What is the difference between enum
> and enum class? When I use one or other?"

He will be told to use nullptr (no underscore) for all new code.

> The ideal code would have only null_ptr and the junior college would
> never ask the difference and the complexity would be hidden.

Clang modernise may take care of that, if I recall correctly.

> The other opposite force for new style is the question.
> "should I make my code incompatible with C only by this enum class?"

As soon as you introduce an c++ feature that doesn't exist in C you
break compatibility. The new stuff is no different.

--
Ian.

[Thiago Adams]

On Saturday, December 16, 2017 at 12:45:08 AM UTC-2, Ian Collins wrote:
> On 12/16/2017 03:28 PM, Thiago Adams wrote:
> > On Friday, December 15, 2017 at 6:09:55 PM UTC-2, Paavo Helde wrote:
> >> On 15.12.2017 14:09, wrote:
> >>> The problem I see with nullptr and enum class is that for an existing
> >>> code base or when integrating with some other library (C for instance)
> >>> the code becomes mixed in style. The same for using or typedef.
> >>> Or new style for function declaration.
> >>
> >> You are confusing the goal and the means. Consistent style is not a
> >> goal, it's just a way to produce more maintainable and reliable programs
> >> (which are also just some specific means for solving some real world
> >> problems).
> >>
> >> If mixed-style code means more reliable and maintainable code than
> >> non-mixed old-style, then it's better, not worse.
> >>
> >
> > If you are trying to create more reliable and maintainable
> > code mixing styles (updating partially enuns or null for instance)
> > then you have opposite forces in your source code, because more styles
> > means more complex code and more difficult to read.
>
> All code bases evolve over time. Would you have us keep to the features
> available when a decades old code base started?

I work in 3 different C++ codebases.
One very large from 1999 that still in development. This codebase has
,for instance, a macro for the equivalent of static assert and a macro
for the equivalent of deleted constructor and operator =. This is
for windows and we don´t have a refactoring tool.


Other medium-small started in 2012 and other medium-small
started in 2015.

In 2012 the implementation of C++ 11 in visual studio was limited.
I have used lambdas with copy capture where move capture would be
much better but they were not available at time. Then I had to
use shared_ptr to copy data into lambdas and the refactoring to fix
that would change a lot of code to use unique_ptr with move capture.

Considering that we don't have a way to update in one step the
codebase I am planing to keep the code in the same style of when
it was created.
Sometimes this is not only a matter of compiler, but I changed
my style along the years and I use the same policy.

> > In case you have a new junior colleague, he will ask. "Why the code
> > sometimes have 0 or NULL or null_ptr? What is the difference between enum
> > and enum class? When I use one or other?"
>
> He will be told to use nullptr (no underscore) for all new code.

Yes nullptr, thanks.

> > The ideal code would have only null_ptr and the junior college would
> > never ask the difference and the complexity would be hidden.
>
> Clang modernise may take care of that, if I recall correctly.
>
> > The other opposite force for new style is the question.
> > "should I make my code incompatible with C only by this enum class?"
>
> As soon as you introduce an c++ feature that doesn't exist in C you
> break compatibility. The new stuff is no different.

In this case the code has some expiration time.
This code is good until C++ 17.

I admire the stability of C code, and the C++ code is changing
very fast. Faster than the codebases that uses C++.
Source code started in 2000 was very stable for one decade.
Then C++ changed a lot in 2011 until now.
Projects started in 2011-2013 were suffering of lack of compiler support
at least in windows.
C++ 17, maybe modules and concepts and maybe new STL will create
a completely new style. If you start a project today and then
in two years when the product is version 1.2 and modules where
variable your codebase will look old and deprecated.

[Mr Flibble]

And the reason you snipped "I wouldn't use the default allocator" from
my post you replied to is?

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Limit yourself to C with classes
> (don't use STL, don't use Exceptions, disable RTTI for performance).

Templates can make the code more efficient with less code than the
equivalent non-templated version (just compare std::sort with qsort,
for instance).

Also, C++ has much more to offer in terms of efficiency than C,
such as constexpr functions (and anything constexpr, for that matter).

[Thiago Adams]

On Saturday, December 16, 2017 at 9:18:45 AM UTC-2, Mr Flibble wrote:

I think I answered the older replies before to read the new ones.

[Thiago Adams]

On Monday, December 18, 2017 at 6:40:36 AM UTC-2, Juha Nieminen wrote:

> Scott Lurndal wrote:
> > Limit yourself to C with classes
> > (don't use STL, don't use Exceptions, disable RTTI for performance).
>
> Templates can make the code more efficient with less code than the
> equivalent non-templated version (just compare std::sort with qsort,
> for instance).

This is the classic sample repeated many times. I think C programmers
understand well the problem and they can remove the pointer callback
in a specialized algorithm. Templates are convenient for algorithms
and they solved the "container problem" that still exist in C.
Templates also opened the door for language libraries that requires
type parametrization.

> Also, C++ has much more to offer in terms of efficiency than C,
> such as constexpr functions (and anything constexpr, for that matter).

I don't see constexpr as a feature for efficiency. They are convenient
like templates to express in code some computation/code generation that
can be done in compilation time.
Without constexpr we still can compute things and use the result having
the same efficiency. constexpr just make it more integrated.

The advantage of constexpr, templates and this integration with the
language is more visible when some change in code requires updates
in the generated code.

For instance, let's say you want a table of primes numbers. This
table is not affected by your code changes. In this case you
can create an external program and generate your table. If your
table is not affect by your code, it also means, that doesn't make
sense to generate this table in each build. This is the same for
factorial(5).
On the other hand, if you are experimenting and changing some params
that affects the computation then constexpr offers a
convenient way to update the result in a integrated way.

Templates also offers a convenient way of instantiation.
For instance, lets say you have a code generator that generates
a vector<T> for you. In this case, you would probably have some
flags to specify the functions you want to instantiate.
When you need a function that you didn't generated then you would
have to run the generator again.
With automatic template instantiation, when you use the template
function it will be automatically instantiated and this is very
convenient. The only disadvantage I see of this convenience is
that it's so simple to generate more instances that programmers
can easily forget that the code may be duplicated with small
differences. I think modern compilers do a hard job to avoid
code bloat. For instance, let's say a container of pointers
instantiated for pointer T1 and T2 etc.. The push_back and others
have the same code that only differs for T but T doesn't affect the
code. In this case the compiler can join the implementation of these
instantiated functions.


Generated code also offer to programmers an important property.
If we can broke a problem in small parts then we have a good
way to go. If the parts are not related then this make easy
to review and maintaining your code.
Sometimes it is difficult to isolate completely on part from other
but the bound between parts can have a pre-defined behavior that
can be checked or generated by the compiler. This make the programmer
free to think each part independently.
For instance,
class X{ ..}
class Y {X x; ..}
class Z { Y y; ...}

When we add some data member in X the class Z is affected. The constructor
of Z is generated again. But we can think in X in a very isolated way and
this property is very interesting and powerful.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Scott Lurndal <sc...@slp53.sl.home> wrote:
>> Limit yourself to C with classes
>> (don't use STL, don't use Exceptions, disable RTTI for performance).
>
>Templates can make the code more efficient with less code than the
>equivalent non-templated version (just compare std::sort with qsort,
>for instance).

And how many operating systems need a sort function?

>
>Also, C++ has much more to offer in terms of efficiency than C,
>such as constexpr functions (and anything constexpr, for that matter).

I suspect that anything that can be done with constexpr in C++ can also be
done in C, if less cleanly, with preprocessor macros.

[David Brown]

On 18/12/17 15:08, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Scott Lurndal <sc...@slp53.sl.home> wrote:
>>> Limit yourself to C with classes
>>> (don't use STL, don't use Exceptions, disable RTTI for performance).
>>
>> Templates can make the code more efficient with less code than the
>> equivalent non-templated version (just compare std::sort with qsort,
>> for instance).
>
> And how many operating systems need a sort function?
>

Templates allow many other things, such as neat and convenient strong
typing. How many operating systems need that in their code? Any that
try to make it as difficult as possible to write incorrect code.

>>
>> Also, C++ has much more to offer in terms of efficiency than C,
>> such as constexpr functions (and anything constexpr, for that matter).
>
> I suspect that anything that can be done with constexpr in C++ can also be
> done in C, if less cleanly, with preprocessor macros.
>

No, that is not the case. Even when you allow for immensely ugly
pre-processing and fixed limits on things (because macros don't allow
recursion or looping), you will not be able to duplicate everything.
And the key point of constexpr is that the same code works for compile
time and for run time.

The C equivalent to C++ constexpr is external code generators and
dedicated pre-processors. constsexpr does not eliminate these entirely
of course, but it certainly reduces the need for them.

[Öö Tiib]

On Monday, 18 December 2017 16:08:48 UTC+2, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
> >Scott Lurndal <sc...@slp53.sl.home> wrote:
> >> Limit yourself to C with classes
> >> (don't use STL, don't use Exceptions, disable RTTI for performance).
> >
> >Templates can make the code more efficient with less code than the
> >equivalent non-templated version (just compare std::sort with qsort,
> >for instance).
>
> And how many operating systems need a sort function?

The std::sort/qsort example is not example of sorting but example how
templates allow very tight integration of different modules.
Templates let us to make language to generate such integration in
compile-time Turing-complete manner.

> >Also, C++ has much more to offer in terms of efficiency than C,
> >such as constexpr functions (and anything constexpr, for that matter).
>
> I suspect that anything that can be done with constexpr in C++ can also be
> done in C, if less cleanly, with preprocessor macros.

The idea of constexpr is to allow ordinary (within certain constraints)
variables to be declared as compile-time constants and ordinary (again
constraints) functions to be ran compile-time. So it is (second and
simpler) feature of C++ that is compile-time Turing-complete.

The C preprocessor can be used in quite clever manners but it is not
Turing-complete. That has been the gloat of Lisp (that has Turing-
complete macros) fans like Paul Graham forever and ever so it can't
come as surprise to anyone of us?

[Scott Lurndal]

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:
>On Monday, 18 December 2017 16:08:48 UTC+2, Scott Lurndal wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>> >Scott Lurndal <sc...@slp53.sl.home> wrote:
>> >> Limit yourself to C with classes
>> >> (don't use STL, don't use Exceptions, disable RTTI for performance).
>> >
>> >Templates can make the code more efficient with less code than the
>> >equivalent non-templated version (just compare std::sort with qsort,
>> >for instance).
>>
>> And how many operating systems need a sort function?
>
>The std::sort/qsort example is not example of sorting but example how
>templates allow very tight integration of different modules.
>Templates let us to make language to generate such integration in
>compile-time Turing-complete manner.

At the expense, potentially of a larger code footprint. A key metric in
kernel development. Granted compilers have gotten better since
the first template implementations with cfront, e.g. std::min/std::max
generate code inline with simple comparision instructions with good
optimizing compilers. Templates can be abused, however.

[Richard]

[Please do not mail me a copy of your followup]

thiago...@gmail.com spake the secret code
<90e12cec-4652-4016...@googlegroups.com> thusly:

>Generic code can be dangerous when you try to solve problems that you
>don't have.

Interesting. Can you provide an example?

The idea behind generic algorithms is to leverage the expertise of
other people as opposed to re-inventing the wheel.

I know the real-time/game working group has very speicfic concerns
about the standard library, but most of them come from the containers
and not the algorithms.
--
"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>

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<f9jfl0...@mid.individual.net> thusly:

>On 12/16/2017 03:28 PM, Thiago Adams wrote:
>> The ideal code would have only null_ptr and the junior college would
>> never ask the difference and the complexity would be hidden.
>
>Clang modernise may take care of that, if I recall correctly.

Yes, clang-tidy can upgrade everything to use nullptr.

[David Brown]

Templates can also lead to noticeably smaller code - because it is
specialised for the task in hand, rather than a generic function. Newer
and better compilers do make a difference - nowadays tools can spot
identical functions and merge them, for example, so that foo<int> and
foo<unsigned int> don't both take space. And they will merge the same
template-generated function across different translation units (unless
the functions have been inlined, cloned, etc.).

Yes, templates can be abused - but they can also be /used/.

[Richard]

[Please do not mail me a copy of your followup]

Thiago Adams <thiago...@gmail.com> spake the secret code
<51d6fc02-6db2-43b3...@googlegroups.com> thusly:

>One very large from 1999 that still in development. This codebase has
>,for instance, a macro for the equivalent of static assert and a macro
>for the equivalent of deleted constructor and operator =. This is
>for windows and we don´t have a refactoring tool.

clang-tidy is pretty much ubiquitous.

On Windows, VS2015 shipped with some limited refactoring support out
of the box and they improved/expanded on it in VS2017.

Even better is ReSharper for C++ add-on from JetBrains. The JetBrains
products (CLion, R++) score highest on passing my refactoring test
suite.

[Ian Collins]

for loops can be abused as well, should we avoid those?

It's foolish to write of a chunk of a language because it can be abused.
Just don't abuse it...

--
Ian.

[Öö Tiib]

On Monday, 18 December 2017 23:42:56 UTC+2, Scott Lurndal wrote:

Every tool can be abused. Modern human has indeed may be too flexible
mind and is too open to innovation. More complex tool is simpler
to misunderstand, harder to learn and has more ways to misuse. History
of our tool industry shows that it really took millions of years for
our ancestors to get somewhere. https://en.wikipedia.org/wiki/Stone_tool
;)
It is likely that C++ has gone overboard with incorporating various
complications into it but templates and constexpr really make it
simpler to achieve efficient results in practice ... especially when
not abused.

[Thiago Adams]

On Monday, December 18, 2017 at 9:18:44 PM UTC-2, David Brown wrote:
...

> Templates can also lead to noticeably smaller code - because it is
> specialised for the task in hand, rather than a generic function. Newer
> and better compilers do make a difference - nowadays tools can spot
> identical functions and merge them, for example, so that foo<int> and
> foo<unsigned int> don't both take space. And they will merge the same
> template-generated function across different translation units (unless
> the functions have been inlined, cloned, etc.).

..
I think this merge feature in Microsoft Visual C++ is done by
the linker and it works even for C.

[Thiago Adams]

On Monday, December 18, 2017 at 9:04:59 PM UTC-2, Richard wrote:
> [Please do not mail me a copy of your followup]

?

> thiago.adams spake the secret code
> [..] thusly:
?

> >Generic code can be dangerous when you try to solve problems that you
> >don't have.
>
> Interesting. Can you provide an example?

I used a wrong word. It may be dangerous in some cases
where the specialization is not obvious or never tested.
However, what I was trying to say is that generic code can be
waste of time or make code unnecessarily complicated or obfuscated
trying to accept cases that you may not have.

Generic code is an strategy for code reuse. This strategy can be
a gamble or you already have use cases for each type of type.
Even when you know the type of type you are going to use
I think the code can be too complicated. I never liked the
policy design because I think it tries to make too much with
the same template class instead of split the problem
in more classes.

Once I wrote a parser generator. For the scanner, instead of
use std::string I used a type <T>. My intention was to allow
some super fast string append with some custom string allocated
on stack. I think this code was written in 2009.
I have never used this type T with a type different from std::string.
I just make the code more complicated.

[Thiago Adams]

On Monday, December 18, 2017 at 9:25:20 PM UTC-2, Richard wrote:
...

> >One very large from 1999 that still in development. This codebase has
> >,for instance, a macro for the equivalent of static assert and a macro
> >for the equivalent of deleted constructor and operator =. This is
> >for windows and we don´t have a refactoring tool.
>
> clang-tidy is pretty much ubiquitous.

But this tool cannot remove old custom macros.

For large codebases a custom parser can be useful because
you can fix something in large scale. In this aspect I think
the C language is more convenient than C++. Although both have
the preprocessor, the C language is much simpler.

[Gareth Owen]

Given that (in the Linux kernel at least) most of the things that would
be templates in C++ are implemented with macros, I don't find the
"templates can be abused" argument very compelling either.

[Ian Collins]

Indeed, macros have to be inline, so they can cause more bloat than
function templates which don't.

--
Ian.

[David Brown]

I don't know about MSVC, but in gcc it is handled at two levels. In the
compiler, merging is done for functions (or sections of code) that match
in their internal structures, and can be done at various stages of
optimisation (the earlier it is done, the more efficient it is). In
linking, merging is done for functions with the same object code. Each
level has its advantages.

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
>>Templates can make the code more efficient with less code than the
>>equivalent non-templated version (just compare std::sort with qsort,
>>for instance).
>
> And how many operating systems need a sort function?

Are going to ask that same question for every single simple example
that could be given?

> I suspect that anything that can be done with constexpr in C++ can also be
> done in C, if less cleanly, with preprocessor macros.

Only if you are willing to either generate the code by hand (and do so again
every single time some parameter changes), or write a separate code generator
program, which you integrate into the building process of the entire project.

As a simple example, with constexpr functions and objects you can generate
an array of precalculated values (using some functions) at compile time,
rather than having to calculate these values at runtime.

[James Kuyper]

On 12/18/2017 06:59 PM, Ian Collins wrote:
...

> It's foolish to write of a chunk of a language because it can be abused.

"write off"?

[Ian Collins]

On 12/20/2017 07:34 AM, James Kuyper wrote:
> On 12/18/2017 06:59 PM, Ian Collins wrote:

> ....

>> It's foolish to write of a chunk of a language because it can be abused.
>
> "write off"?

Indeed :)

--
Ian.

[Richard]

[Please do not mail me a copy of your followup]

Thiago Adams <thiago...@gmail.com> spake the secret code

<e940119a-ddaa-4fff...@googlegroups.com> thusly:

>On Monday, December 18, 2017 at 9:25:20 PM UTC-2, Richard wrote:
>...
>> >One very large from 1999 that still in development. This codebase has
>> >,for instance, a macro for the equivalent of static assert and a macro
>> >for the equivalent of deleted constructor and operator =. This is
>> >for windows and we don´t have a refactoring tool.
>>
>> clang-tidy is pretty much ubiquitous.
>
>But this tool cannot remove old custom macros.

Yes, it can. (I've written some of the checks that ship in clang-tidy.)

Custom transformations of course require custom code to identify those
transformations. There are some commercial tools out there that have
a custom DSL in which you can write such tranfsormations. However,
clang-tidy doesn't (yet) have such a DSL for specifying
transformations.

DMS is a commercial tool for transforming C++ code with a DSL for
specifying the transformations. Here is a lightning talk about it
from CppCon 2017: <https://www.youtube.com/watch?v=86fwuXSz7lQ>
It looks pretty cool from that talk, but I have not experience in
using it. Here is a page from their site explaining code
transformations:
<http://www.semdesigns.com/Products/DMS/ProgramTransformation.html?Home=DMSToolkit>

Given that I can't find a price for DMS directly on their prices page,
I'm assuming it's expensive. My guess would be somewhere between $10K
and $50K per seat. Still, that may be cheap compared to modernizing a
legacy code base by hand (and presumably less error prone).

[Scott Lurndal]

I could see using it for Jovial to C, that makes a lot of sense,
particularly in the context of the B2.

I'm not as confident that it would be worth the price for C to C
or C++ to C++, which seems like churn for the sake of churn.

[Thiago Adams]

On Tuesday, December 19, 2017 at 5:53:56 PM UTC-2, Richard wrote:
> [Please do not mail me a copy of your followup]
>

> Thiago Adams spake the secret code

I am making a tool for C, that can read on source file build the
AST and generate the same code modified (or not) with all comments
macros etc.
https://github.com/thradams/CPrime

I trying to make my tool apply changes "in place" not in a new file
and this means that I have to edit the current file and not create
a new one. The difference is that I cannot create something already
created for instance. My next motivation is to to add C++ lambdas as
an extension for C. The lambda can be inside #ifdef and the some functions
are generated/edited to implement the lambda.


I am interested for these transformation strategies and also the Sutter's
Metaclasses.

Maybe some day, templates will be a subset of that can be done
with other declarative transformation language.

I was wondering if the C /C++ language had a standardized AST data structure
with basic operations. A program would be data structure. You can have
the same program as source file, or json, or xml or binary etc.

I think for modules they have to define some standard data structures
for declarations to create modules compatible between compilers.
Considering that modules have templates(Am I right?) then the modules
also need to have code representation.

I am thinking while I am writing..
so I am also wondering, Can I create a static analysis tool using the module
representation?

[Richard]

[Please do not mail me a copy of your followup]

>I am making a tool for C, that can read on source file build the
>AST and generate the same code modified (or not) with all comments
>macros etc.
>https://github.com/thradams/CPrime

Seems like you're reinventing most of clang-tidy.

>I was wondering if the C /C++ language had a standardized AST data structure
>with basic operations.

Nope.

>I think for modules they have to define some standard data structures
>for declarations to create modules compatible between compilers.

Read the module proposal. This is explicitly not a design goal, IIRC.

[Thiago Adams]

On Wednesday, December 20, 2017 at 4:25:14 PM UTC-2, Richard wrote:
...

> >I think for modules they have to define some standard data structures
> >for declarations to create modules compatible between compilers.
>
> Read the module proposal. This is explicitly not a design goal, IIRC.

I think they are delaying these questions.
Are modules of clang compatible with VC++ ?
Are modules compatible between compilers?


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf


"7 Tools Support
The abstract operational model of a module is that it contains everything that is
ever to be known about its constituents module units. In particular, we envision
that a high quality implementation will provide library interfaces for querying the
elaborated forms of declarations, hosting environmental values, including translation
command line switches, target machines, optional source form, binary form,
etc. Ideally, a module would provide all that is necessary for a code analysis tool.
A library interface to internal representation of modules will be the subject of
a separate proposal.

"

My understanding of modules is that they are big data structures that
represent exported code.
When you include the module you have something faster than parsing.

To archive this design the module cannot be affect by the external
pre-processor. In some ways it is similar of pre-compiled headers.


It's not clear for me if modules have the equivalent of static library
compiled code. In this case the exported code works like the includes
and the internal code as a library for one specific target.

[ruben safir]

On 12/11/2017 05:49 AM, mche...@gmail.com wrote:
> oes the statement still valid?


Ask Mr Tovalds.

[ruben safir]

On 12/18/2017 09:08 AM, Scott Lurndal wrote:
> with preprocessor macros.

ugg

[ruben safir]

On 12/19/2017 07:47 AM, Juha Nieminen wrote:
>> And how many operating systems need a sort function?
> Are going to ask that same question for every single simple example
> that could be given?
>

the scheduler has a whole red/black tree.

[David Brown]

On 20/12/17 20:35, Thiago Adams wrote:
> On Wednesday, December 20, 2017 at 4:25:14 PM UTC-2, Richard wrote:
> ...
>>> I think for modules they have to define some standard data structures
>>> for declarations to create modules compatible between compilers.
>>
>> Read the module proposal. This is explicitly not a design goal, IIRC.
>
> I think they are delaying these questions.
> Are modules of clang compatible with VC++ ?
> Are modules compatible between compilers?
>
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
>
>
> "7 Tools Support
> The abstract operational model of a module is that it contains everything that is
> ever to be known about its constituents module units. In particular, we envision
> that a high quality implementation will provide library interfaces for querying the
> elaborated forms of declarations, hosting environmental values, including translation
> command line switches, target machines, optional source form, binary form,
> etc. Ideally, a module would provide all that is necessary for a code analysis tool.
> A library interface to internal representation of modules will be the subject of
> a separate proposal.
>
> "
>
> My understanding of modules is that they are big data structures that
> represent exported code.
> When you include the module you have something faster than parsing.
>
> To archive this design the module cannot be affect by the external
> pre-processor. In some ways it is similar of pre-compiled headers.
>

It has similarities to pre-compiled headers. But pre-compiled headers
/are/ affected by the pre-processor - by compiler options, flags, other
include files, pre-processor macro definitions, etc. This is why you
can't have more than one pre-compiled header included by a translation
unit, why it must come first in the list of includes, and why they will
fail to be used if you change settings or have extra macro defines.
With modules, you are not allowed to have that kind of dependency, thus
your application code can import as many modules as it wants, in any
order. And modules can also contain implementation code, not just the
header code.

[Richard]

[Please do not mail me a copy of your followup]

Thiago Adams <thiago...@gmail.com> spake the secret code

<c7288995-718b-4dc7...@googlegroups.com> thusly:

>On Wednesday, December 20, 2017 at 4:25:14 PM UTC-2, Richard wrote:
>...
>> >I think for modules they have to define some standard data structures
>> >for declarations to create modules compatible between compilers.
>>
>> Read the module proposal. This is explicitly not a design goal, IIRC.
>
>I think they are delaying these questions.
>Are modules of clang compatible with VC++ ?
>Are modules compatible between compilers?

I thought I read this in one of the modules papers/proposals that it
was not expected that modules are something you ship. Currently there
is no compatibility for binary products of compilers between
compilers. Where such binary compatibility exists, it is not due to
any wording in the standard, but due to the compiler team providing
the compatibility explicitly as a goal (e.g. clang's ability to link
against libraries producted by MSVC).

I don't see how modules are going to be any different in this regard.
Why would you expect to be able to share compiled modules between
compilers when you typically can't share object files?

>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
>
>
>"7 Tools Support
>The abstract operational model of a module is that it contains
>everything that is
>ever to be known about its constituents module units. In particular, we envision
>that a high quality implementation will provide library interfaces for
>querying the
>elaborated forms of declarations, hosting environmental values,
>including translation
>command line switches, target machines, optional source form, binary form,
>etc. Ideally, a module would provide all that is necessary for a code
>analysis tool.
>A library interface to internal representation of modules will be the subject of
>a separate proposal.
>
>"

This is completely unrelated feature to sharing modules between
compilers. I would expect that over time compiled modules would be a
place where innovation occurs to increase the compile speed of using
modules. If module binary formats or interchange are mandated, then
the opportunity for innovation likely disappears.