When you are new to a mailing list or other discussion forum, it is a
good idea to do one of two things - stick rigidly to rational technical
points, or find out who you are talking to before straying from the
technicalities. Insulting one of the big contributors and experts on
gcc development, as well as being a well-known poster on this mailing
list, is /not/ going to do your cause any good! We can all have
different ideas and opinions, but when someone of Andrew's standing and
experience says your idea won't work or you are factually inaccurate, it
is a good idea to listen.
Some people do want a centralised source of C and/or C++ libraries and
other code, or other common repositories, as is found for a number of
other languages. Most C and C++ programmers, I think, understand that
this could only be of minor use, and only for some developers. I know
that for /my/ work, I would never consider a build system that tried to
pull in code or libraries from elsewhere. And I have never found a
build system that works better than "make" for my own uses. (Other
people have different needs and preferences.)
It is also worth noting that people have been trying to make something
like this for decades - long before Rust was conceived. The only one
similar concept that has been successful has been boost.org.
Now, let's look at the technical aspects. You are suggesting "no
headers" as though it were a good thing, while C++ development is moving
towards more header-only libraries. Modules reduce, but do not
eliminate the importance of headers. You want to remove macros, though
macros (with their well-established flaws and limitations) are essential
to real-world C and C++ development.
What you are asking for here requires a huge change to the way C++
works, and the way people use it today. It is not going to happen.
Changes like that don't happen in established languages, because doing
so changes too much and would never work well as afterthoughts and
add-ons. The way to get such things is to develop a new language - such
as Rust, or the experimental proposed "next generation C++" languages
like Carbon or Sutter's cpp2.
And even if some of your ideas are feasible and beneficial, making them
"standard" means starting with standards proposals, not with gcc.
Discuss them on the C++ standards proposals mailing list. If and when
they develop into a realistic concept with a fair chance of becoming
part of C++, /then/ it is time to consider implementation in gcc.
David
On 15/07/2025 23:36, The Cuthour via Gcc wrote:
You must be AI.
2025年7月16日 5:07:45 JST、Andrew Pinski <pins...@gmail.com> より:
On Tue, Jul 15, 2025 at 1:06 PM The Cuthour <cuth...@gmail.com> wrote:
Facts
(1) There's no header files in Java/Rust.
(2) There's cargo in Rust.
Ok, sounds like you want a language that is NOT C. Or you want to
improve the standard C/C++ language.
This is the wrong location to talk about doing that.
I wish
(1) There was no header files also in C/C++.
(2) There was cargo also in C/C++.
