F
@john-0 Diese ganzen libc-includes finde ich immer einen absoluten Horror mit den ganzen #ifdef und #include_next von Lowlevel-Header-Fetzen, die teilweise nicht mal Include Guards haben .
Nur mal den ersten Konflikt genauer angesehen:
Auffällig finde ich, dass die "bestehende Deklaration":
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3
die selbe Stelle ist wie die "in Konflikt stehende Deklaration":
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3
bei mir (Arch-basiertes Linux, CachyOS) sieht die Datei so aus:
#ifndef ____mbstate_t_defined
#define ____mbstate_t_defined 1
/* Integral type unchanged by default argument promotions that can
hold any value corresponding to members of the extended character
set, as well as at least one value that does not correspond to any
member of the extended character set. */
#ifndef __WINT_TYPE__
# define __WINT_TYPE__ unsigned int
#endif
/* Conversion state information. */
typedef struct
{
int __count;
union
{
__WINT_TYPE__ __wch;
char __wchb[4];
} __value; /* Value so far. */
} __mbstate_t;
#endif
Da ist schon ein Guard namens ____mbstate_t_defined. Aber wer weiss, das da noch alles an #undef-Schwarzmagie zwischendurch veranstaltet wird. Und dann sind auch noch Module im Spiel.
Ich meine mich allerdings entsinnen zu können, dass die Reihenfolge von import un #include wichtig ist. Auch wenn du kein eigenes Modul baust und diese nur konsumierst:
Ich glaube die #include müssen auf jeden Fall vor dem import kommen.
Und in der Tat, wenn ich bei mir das hier mache, knallt es auch gewaltig:
import std;
#include <stdio.h>
auto main() -> int
{
}
/toolchains/dosloader-toolchain-x86_64-linux-musl/i386-dosloader-elf/include/stdio.h:89:8: error: conflicting declaration 'struct __file'
[build] 89 | struct __file {
[build] | ^~~~~~
[build] In file included from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/cstdio:47,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/ext/string_conversions.h:47,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/bits/basic_string.h:4500,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/string:58,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/bits/stdexcept_throw.h:57,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/bitset:49,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/i386-dosloader-elf/bits/stdc++.h:52,
[build] from /toolchains/dosloader-toolchain-x86_64-linux-musl/lib/gcc/i386-dosloader-elf/16.0.1/include/c++/bits/std.cc:26,
[build] of module std, imported at /home/user/Development/dosloader/examples/filesystem.cpp:1:
[build] /toolchains/dosloader-toolchain-x86_64-linux-musl/i386-dosloader-elf/include/stdio.h:89:8: note: previous declaration as 'struct __file'
Während:
#include <stdio.h>
import std;
auto main() -> int
{
}
wunderbar funktioniert.
Warum es bei dir allerdings nur mit -freflection knallt, kann ich nicht sagen. Ich hätte erwartet, das würde auch ohne Reflection und nur mit Modulen passieren.
Edit: Noch ein anderes Detail, wenn du mal eigene Module baust, dann dürfen z.B. solche #includes auch nur im Global Module Fragment stehen:
module;
#include <stdio.h>
module mymodule;
...
Das nur so am Rande, da gibt es generell spezielle Regeln, wenn man beide Methoden (Module und #include) mischen will.
