Add C++ modules support by mikomikotaishi · Pull Request #442 · LASTRADA-Software/Lightweight

mikomikotaishi · 2026-02-10T00:10:20Z

This PR adds support for C++ modules.

Using statements are sorted in alphabetical order so that it is easier to maintain.

Yaraslaut · 2026-02-10T16:37:36Z

Hi, thanks for the PR, I think we need to consume somewhere Lightweight module to ensure that everything works, for instance chinook example is a good place: https://github.com/LASTRADA-Software/Lightweight/tree/master/src/examples/test_chinook

mikomikotaishi · 2026-02-10T18:58:41Z

Sure, I can add a test for the modules.

mikomikotaishi · 2026-02-11T23:04:57Z

I have a test now for the modules

mikomikotaishi · 2026-02-13T16:00:43Z

@Yaraslaut @christianparpart could you review the tests?

Yaraslaut · 2026-02-13T17:47:43Z

I think we should avoid duplication of the source code, the easiest would be to update existing chinook example with the module usage, since we also check this example in the CI, no need for duplication, because then we need make sure that everything is syncronized

mikomikotaishi · 2026-02-13T22:07:51Z

@Yaraslaut The code is now unified, with macro guards to decide between module imports and includes.

Yaraslaut

Thanks a lot for the update, nothing big, the only point that i am worried about is qualified names, such that name resolution is as simple as possible

src/examples/test_chinook/entities/Customer.hpp

Yaraslaut · 2026-02-13T22:15:32Z

src/examples/test_chinook/entities/Album.hpp


 #include "Artist.hpp"

-#include <Lightweight/DataMapper/DataMapper.hpp>


do we need to import Lightweight; here instead? since this should be enough to include this header to start using the struct, and order of the includes should not matter

I didn't do it with the headers, because I made sure the standard library would be included beforehand.

I guess you're suggesting something like

#ifdef LIGHTWEIGHT_BUILD_MODULES import Lightweight; #else #include <Lightweight/DataMapper/DataMapper.hpp> #endif

but this is a bad idea. import statements MUST appear all at the top of a file, and if we were to do this, we would get something like

#include "entities/Album.hpp" #include "entities/Artist.hpp"

could expand into

import Lightweight; struct Album final { /* ... */ }; import Lightweight; struct Artist final { /* ... */ };

and an import statement would be coming after code, which is rejected by the compiler.

Oh interesting, you can notice that one of the ci checks is failing that checks ddl2cpp. This is a small tool that generates this header files for the database, see: https://github.com/LASTRADA-Software/Lightweight/actions/runs/22004219452/job/63585918320

So I guess we need to find a way to deal with this hear

Yaraslaut · 2026-02-13T22:17:20Z

src/examples/test_chinook/main.cpp

+using std::basic_string_view;
+using std::format_string;
+using std::optional;
+using std::string;
+using std::string_view;
+
+using Lightweight::BelongsTo;
+using Lightweight::DataMapper;
+using Lightweight::Field;
+using Lightweight::PrimaryKey;
+using Lightweight::SqlConnection;
+using Lightweight::SqlConnectionString;
+using Lightweight::SqlDateTime;
+using Lightweight::SqlDynamicUtf16String;
+using Lightweight::SqlNullable;
+using Lightweight::SqlNumeric;
+using Lightweight::SqlRealName;


I do not think that this is a good idea to drop all qualifiers, such as namespaces

The example previously already used using namespace Lightweight; I'm doing this because if we had done that already, then there isn't much of a reason not to do this, but instead of using namespace individual using statements are probably better to make it clear what types originate from what.

But, on the topic of qualification, I think in these examples it's usually clear from context what the symbols refer to. using gives us readability, while not losing context of what library symbols originate from where.

oh, did not notice, indeed the case, we can keep it like this, this is ok

src/examples/test_chinook/main.cpp

Yaraslaut · 2026-02-13T22:23:00Z

src/examples/test_chinook/entities/Track.hpp

+    Field<int32_t, PrimaryKey::ServerSideAutoIncrement, SqlRealName { "TrackId" }> TrackId;
+    Field<SqlDynamicUtf16String<200>, SqlRealName { "Name" }> Name;
+    BelongsTo<&Album::AlbumId, SqlRealName { "AlbumId" }, SqlNullable::Null> AlbumId;
+    BelongsTo<&Mediatype::MediaTypeId, SqlRealName { "MediaTypeId" }> MediaTypeId;
+    BelongsTo<&Genre::GenreId, SqlRealName { "GenreId" }, SqlNullable::Null> GenreId;
+    Field<optional<SqlDynamicUtf16String<220>>, SqlRealName { "Composer" }> Composer;
+    Field<int32_t, SqlRealName { "Milliseconds" }> Milliseconds;
+    Field<optional<int32_t>, SqlRealName { "Bytes" }> Bytes;
+    Field<SqlNumeric<10, 2>, SqlRealName { "UnitPrice" }> UnitPrice;


I am slightly confused
why qualifiers removed here?

I removed the qualifiers because I ensured they were added into scope before the #include directives were used. (As for why I de-qualified, I think it's easier to read and maintain, not to mention the original example already used using namespace Lightweight; previously.

mikomikotaishi · 2026-02-13T22:26:18Z

Is it a problem in this example? The symbols all belong to either the library or std, so I decided to import names into scope to make code easier to read

Yaraslaut

I think that everything is ok, just need to fix compilation and do something about ddl2cpp.
I guess what we want to do, is to add some kind of guard in this headers for the module support, and introduce this guard in the ddl2cpp as well

Yaraslaut · 2026-02-14T20:34:32Z

src/examples/test_chinook/main.cpp

+using std::basic_string_view;
+using std::format_string;
+using std::optional;
+using std::string;
+using std::string_view;
+
+using Lightweight::BelongsTo;
+using Lightweight::DataMapper;
+using Lightweight::Field;
+using Lightweight::PrimaryKey;
+using Lightweight::SqlConnection;
+using Lightweight::SqlConnectionString;
+using Lightweight::SqlDateTime;
+using Lightweight::SqlDynamicUtf16String;
+using Lightweight::SqlNullable;
+using Lightweight::SqlNumeric;
+using Lightweight::SqlRealName;


oh, did not notice, indeed the case, we can keep it like this, this is ok

Yaraslaut · 2026-02-14T20:37:26Z

src/examples/test_chinook/entities/Album.hpp


 #include "Artist.hpp"

-#include <Lightweight/DataMapper/DataMapper.hpp>


Oh interesting, you can notice that one of the ci checks is failing that checks ddl2cpp. This is a small tool that generates this header files for the database, see: https://github.com/LASTRADA-Software/Lightweight/actions/runs/22004219452/job/63585918320

So I guess we need to find a way to deal with this hear

mikomikotaishi · 2026-02-14T21:20:03Z

OK, let's see if this fixes the ddl2cpp CI.

mikomikotaishi requested a review from a team as a code owner February 10, 2026 00:10

github-actions bot added documentation Improvements or additions to documentation Query Builder Data Binder SQL Data Binder support CMake labels Feb 10, 2026

Add C++ modules support

59cb898

mikomikotaishi force-pushed the master branch from dda4512 to 59cb898 Compare February 10, 2026 00:15

mikomikotaishi force-pushed the master branch from d4fc580 to a1bddf1 Compare February 11, 2026 23:07

Add tests for modules

f3482ad

mikomikotaishi force-pushed the master branch from a1bddf1 to f3482ad Compare February 11, 2026 23:10

Yaraslaut reviewed Feb 13, 2026

View reviewed changes

mikomikotaishi force-pushed the master branch from f101a6d to efa2172 Compare February 13, 2026 22:49

Yaraslaut approved these changes Feb 14, 2026

View reviewed changes

mikomikotaishi force-pushed the master branch from efa2172 to dea95b8 Compare February 14, 2026 21:19

Move examples into one singular location (modules/headers)

aaadbb7

mikomikotaishi force-pushed the master branch from dea95b8 to aaadbb7 Compare February 14, 2026 22:20


		#include "Artist.hpp"

		#include <Lightweight/DataMapper/DataMapper.hpp>

Conversation

mikomikotaishi commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Yaraslaut commented Feb 10, 2026

Uh oh!

mikomikotaishi commented Feb 10, 2026

Uh oh!

mikomikotaishi commented Feb 11, 2026

Uh oh!

mikomikotaishi commented Feb 13, 2026

Uh oh!

Yaraslaut commented Feb 13, 2026

Uh oh!

mikomikotaishi commented Feb 13, 2026

Uh oh!

Yaraslaut left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikomikotaishi commented Feb 13, 2026

Uh oh!

Yaraslaut left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikomikotaishi commented Feb 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mikomikotaishi commented Feb 10, 2026 •

edited

Loading