Modules

[woodb...@gmail.com]

Is anyone doing anything with modules?

I watched two talks from Cppcon about modules:

https://duckduckgo.com/?q=cppcon+2017+boris&t=ffsb&iax=videos&ia=videos&iai=E8EbDcLQAoc

and another one that had to do with the gcc implementation
of modules.

I think I may create a separate github repo for the modules
version of my code. At first the non-modules repo would be
the dominant repo. Is that how others are approaching it?


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[David Brown]

On 21/11/17 03:08, woodb...@gmail.com wrote:
> Is anyone doing anything with modules?
>
> I watched two talks from Cppcon about modules:
>
> https://duckduckgo.com/?q=cppcon+2017+boris&t=ffsb&iax=videos&ia=videos&iai=E8EbDcLQAoc
>
> and another one that had to do with the gcc implementation
> of modules.
>

I don't think gcc has an implementation of modules as yet. clang has
support for an earlier draft of modules, while the current guinea pig
here is MSVC. As the drafts get more solidified, and the implementation
in MSVC gets tested more in practice, there will come a point where the
other big C++ compilers implement them. The same thing happens with all
the new features for C++ - gcc is prototyping concepts, clang is
prototyping metaclasses, MSVC is prototyping modules. In the end all
three will support C++20.

> I think I may create a separate github repo for the modules
> version of my code. At first the non-modules repo would be
> the dominant repo. Is that how others are approaching it?

If you are not basing your development firmly on MSVC, then don't use
modules at the moment.

[woodb...@gmail.com]

On Tuesday, November 21, 2017 at 2:51:04 AM UTC-6, David Brown wrote:
>
> I don't think gcc has an implementation of modules as yet. clang has
> support for an earlier draft of modules, while the current guinea pig
> here is MSVC. As the drafts get more solidified, and the implementation
> in MSVC gets tested more in practice, there will come a point where the
> other big C++ compilers implement them. The same thing happens with all
> the new features for C++ - gcc is prototyping concepts, clang is
> prototyping metaclasses, MSVC is prototyping modules. In the end all
> three will support C++20.
>
> > I think I may create a separate github repo for the modules
> > version of my code. At first the non-modules repo would be
> > the dominant repo. Is that how others are approaching it?
>
> If you are not basing your development firmly on MSVC, then don't use
> modules at the moment.
>

In Boris' talk he has a slide titled "Interface File extensions"

His recommendations are if you are using .hpp/.cpp
extensions to use .mpp and if you are using .hxx/.cxx
extensions to use .mxx for module interface files.
I use a .hh/.cc convention and I may use .mm for module
interface files.

I've created this repo:
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.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[woodb...@gmail.com]

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

[fir]

W dniu wtorek, 21 listopada 2017 03:08:35 UTC+1 użytkownik woodb...@gmail.com napisał:
> Is anyone doing anything with modules?
>
> I watched two talks from Cppcon about modules:
>
> https://duckduckgo.com/?q=cppcon+2017+boris&t=ffsb&iax=videos&ia=videos&iai=E8EbDcLQAoc
>
> and another one that had to do with the gcc implementation
> of modules.
>
> I think I may create a separate github repo for the modules
> version of my code. At first the non-modules repo would be
> the dominant repo. Is that how others are approaching it?
>
>

in my world, there is a lot of modules, there are called dlls, (for example msvcrt.dll kernel32.dll bass.dll NxPhysics.dll green.fire.dll )

there is a lot that can be said on those modules as this knowledge related to them is very importnt, you may for example read my post "granular upgrade" on comp.lang.c
which is up to that

[David Brown]

On 18/12/17 19:03, fir wrote:
> W dniu wtorek, 21 listopada 2017 03:08:35 UTC+1 użytkownik
> woodb...@gmail.com napisał:
>> Is anyone doing anything with modules?
>>
>> I watched two talks from Cppcon about modules:
>>
>> https://duckduckgo.com/?q=cppcon+2017+boris&t=ffsb&iax=videos&ia=videos&iai=E8EbDcLQAoc
>>
>>
>>
and another one that had to do with the gcc implementation
>> of modules.
>>
>> I think I may create a separate github repo for the modules version
>> of my code. At first the non-modules repo would be the dominant
>> repo. Is that how others are approaching it?
>>
>>
>
> in my world, there is a lot of modules, there are called dlls, (for
> example msvcrt.dll kernel32.dll bass.dll NxPhysics.dll green.fire.dll
> )
>

There are many things known as "modules". This thread is in c.l.c++, so
it is about C++ modules - these bare no more relation to DLL's on
Windows than they do to space station modules.

C++ modules will hopefully be part of C++20, and will replace or augment
the traditional .h and .cpp packaging with modules that can be compiled
- improving structure and modularity of C++ programs, and massively
improving build times compared to header-based template libraries.

[fir]

module concept and win32 dll perfectly covers

this module design (i mean what and how to divide on dlls and various aspect that do appear here) are very domain of knowledge
for good c coder

recently im interested in drivers, drivers are also just modules but have some specyfics which i feel i would like to know better

[Thiago Adams]

On Tuesday, November 21, 2017 at 12:08:35 AM UTC-2, woodb...@gmail.com wrote:
...

> I think I may create a separate github repo for the modules
> version of my code. At first the non-modules repo would be
> the dominant repo. Is that how others are approaching it?

The approach I think is better to create a "module" is the amalgamation
like sqlite does.
You have a public interface with 1 header and 1 source code with
all the combined implementation.
To consume the library you just add these two files.

[woodb...@gmail.com]

On Wednesday, December 20, 2017 at 2:21:22 PM UTC-6, Thiago Adams wrote:
>
> The approach I think is better to create a "module" is the amalgamation
> like sqlite does.
> You have a public interface with 1 header and 1 source code with
> all the combined implementation.
> To consume the library you just add these two files.

I don't know much about sqlite, but Wikipedia says it's a C library.
I'm talking about C++ modules.

[Thiago Adams]

On Thursday, December 21, 2017 at 12:46:31 AM UTC-2, woodb...@gmail.com wrote:
> On Wednesday, December 20, 2017 at 2:21:22 PM UTC-6, Thiago Adams wrote:
> >
> > The approach I think is better to create a "module" is the amalgamation
> > like sqlite does.
> > You have a public interface with 1 header and 1 source code with
> > all the combined implementation.
> > To consume the library you just add these two files.
>
> I don't know much about sqlite, but Wikipedia says it's a C library.
> I'm talking about C++ modules.

From:

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

"3 The Problems
The primary issue we face when trying to scale compilation of C++ libraries and programs to billions of lines of code is how C++ programmers author software components, compose, and consume them."


I give just a sample with SQLite to answer "Is that how others are approaching it?".
I consider the amalgamation approach, that is used by sqlite and others, a
good approach to compose and consume libraries.

With this approach we have two files that can be used in a portable way
in different platforms.
It's not clear for me if modules have the property of being portable.

[woodb...@gmail.com]

On Thursday, December 21, 2017 at 5:26:37 AM UTC-6, Thiago Adams wrote:
>
> From:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
>
> "3 The Problems
> The primary issue we face when trying to scale compilation of C++ libraries and programs to billions of lines of code is how C++ programmers author software components, compose, and consume them."
>
>
> I give just a sample with SQLite to answer "Is that how others are approaching it?".
> I consider the amalgamation approach, that is used by sqlite and others, a
> good approach to compose and consume libraries.

OK, thanks for your comments. They inspired me to do some
consolidating of my smaller files into one file. I'm a long
ways though, from having just one header and one .cc file.

>
> With this approach we have two files that can be used in a portable way
> in different platforms.
> It's not clear for me if modules have the property of being portable.

That's an interesting question, but I'm not sure how much it will
matter in practice.

[woodb...@gmail.com]

On Friday, December 22, 2017 at 10:22:16 AM UTC-6, woodb...@gmail.com wrote:
> On Thursday, December 21, 2017 at 5:26:37 AM UTC-6, Thiago Adams wrote:
> >
> > From:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
> >
> > "3 The Problems
> > The primary issue we face when trying to scale compilation of C++ libraries and programs to billions of lines of code is how C++ programmers author software components, compose, and consume them."
> >
> >
> > I give just a sample with SQLite to answer "Is that how others are approaching it?".
> > I consider the amalgamation approach, that is used by sqlite and others, a
> > good approach to compose and consume libraries.
>
> OK, thanks for your comments. They inspired me to do some
> consolidating of my smaller files into one file. I'm a long
> ways though, from having just one header and one .cc file.
>

I've gone further in this direction than I anticipated
when I wrote that a few weeks ago. Code review comments
welcome.

https://github.com/Ebenezer-group/onwards

Thanks in advance.

[Mr Flibble]

Change the fucking record Brian. You need to work on other projects,
seriously.

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

[Thiago Adams]

Sorry, which one is your amalgamated?
What is new?
Have you used some tool?

(
Brian, I have one project that may interest
you.
I have a tool/compiler that reads C code and generates
C code.

https://github.com/thradams/CPrime

https://www.youtube.com/watch?v=cFHL6cf1n_k&t=90s

https://www.youtube.com/watch?v=vzouZGBV8YQ&t=490s

This compiler could generate code for serialization
for instance reading structs and more.
To allow others uses I could have some plugins to
consume the AST and generated customized code.

)

[woodb...@gmail.com]

On Monday, January 8, 2018 at 1:43:09 PM UTC-6, Thiago Adams wrote:
> On Monday, January 8, 2018 at 5:06:50 PM UTC-2, woodb...@gmail.com wrote:
> > On Friday, December 22, 2017 at 10:22:16 AM UTC-6, woodb...@gmail.com wrote:
> > >
> > > OK, thanks for your comments. They inspired me to do some
> > > consolidating of my smaller files into one file. I'm a long
> > > ways though, from having just one header and one .cc file.
> > >
> >
> > I've gone further in this direction than I anticipated
> > when I wrote that a few weeks ago. Code review comments
> > welcome.
> >
> > https://github.com/Ebenezer-group/onwards
> >
> > Thanks in advance.
>
> Sorry, which one is your amalgamated?

I'm not down to just one header file yet.

> What is new?

These two files are the result of merging a lot of my smaller files:
https://github.com/Ebenezer-group/onwards/blob/master/Buffer.hh
https://github.com/Ebenezer-group/onwards/blob/master/wrappers.hh

I'm not sure I want to merge those two. It possible someone would
want to use just wrappers.hh and not the rest of the code.

> Have you used some tool?
>
> (
> Brian, I have one project that may interest
> you.
> I have a tool/compiler that reads C code and generates
> C code.
>

That sounds familiar.

[woodb...@gmail.com]

On Monday, January 8, 2018 at 1:16:34 PM UTC-6, Mr Flibble wrote:

Please don't swear here.

[red floyd]

On 1/8/2018 7:42 PM, woodb...@gmail.com wrote:
> On Monday, January 8, 2018 at 1:16:34 PM UTC-6, Mr Flibble wrote:
>
> Please don't swear here.
>

Stop imposing your fucking sanctimony on us.

[Thiago Adams]

I created a simple tool to do the amalgamation:

https://github.com/thradams/amalgamation

It is very simple (179 lines) and open source.

[Öö Tiib]

Most preprocessor metaprogramming will break, same names in anonymous
namespaces may conflict and same names of statics may conflict.
I did not check if Brian's code has any of that.
Otherwise works.

[Thiago Adams]

In my own code I had to make static function names unique
manually.

For template code, I think the template code must be merged in
a single header file. And the source code merged in other file without
to expand the template headers. Instead it must include one merged
template file.

If I had to to this using the tool I would
do the following:

1 - Merge all includes in one file

tool merge_h.txt allheaders.h

-- merge_h.txt--

#include "header1.h"
#include "header2.h"
...
#include "headerN.h"

---

2 - Merge source files.
Headers files must not be present in this directory
to avoid expansion. They need to be included at the
beginning to avoid subsequent includes of "#include".

tool merge_cpp.txt allsource.cpp


-- merge_cpp.txt--


////////////cut here after completation ///////////////////

#include "header1.h"
#include "header2.h"
...
#include "headerN.h"

///////////cut here after completation /////////////

#include "allheaders.h"

#include "source1.cpp"
#include "source2.cpp"
...
#include "sourceN.cpp"
---


After generation allsource.cpp I would manually
remove cut here, or just use #if 0 there.


I don't have a real case for this now, but
the tool can be customized for the template needs.
I can create the "don't expand list" also to
avoid to have to remove the headers I don't want
to expand.