[PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

Mailing Lists php.internals
1

Hello,

I’m considering adding some C++ enhancements to the Zend API. These changes would be encapsulated within #ifdef __cplusplus guards, so they wouldn’t interfere with the existing C implementation. The primary goal is to provide a nicer interface for extensions while maintaining compatibility with C.

Key points:

  • Struct-based Approach: Everything will still use structs—no classes or non-public/non-static members.
  • Isolation: Any enhancements that can be isolated from the C implementation will be, and they will reside in a common zend_api_cxx header file.
  • Proposed Enhancements:
  • Constructors and destructors, along with comparison operator overloads for zval.
  • Constructor overloads for common zval initializations.
  • Member methods for common zval operations.

I’m happy to implement and maintain these changes. Since this doesn’t affect userland, do you think an RFC is necessary?

Also, if anyone has suggestions or ideas for this C++ API, I’d love to hear them.

Cheers,
Lanre

2

On Sun, Aug 11, 2024 at 4:54 PM Lanre <lnearwaju@gmail.com> wrote:

Hello,

I’m considering adding some C++ enhancements to the Zend API. These changes would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t interfere with the existing C implementation. The primary goal is to provide a nicer interface for extensions while maintaining compatibility with C.

Key points:
- **Struct-based Approach:** Everything will still use structs—no classes or non-public/non-static members.
- **Isolation:** Any enhancements that can be isolated from the C implementation will be, and they will reside in a common `zend_api_cxx` header file.
- **Proposed Enhancements:**
  - Constructors and destructors, along with comparison operator overloads for `zval`.
  - Constructor overloads for common `zval` initializations.
  - Member methods for common `zval` operations.

I’m happy to implement and maintain these changes. Since this doesn’t affect userland, do you think an RFC is necessary?

Also, if anyone has suggestions or ideas for this C++ API, I’d love to hear them.

Cheers,
Lanre

I am not opposed, but there are some logistics questions:
1. Since it's for extensions and not core, how will we be sure it is
maintained? What will test it?
2. Since it's in core, and C++ is a rapidly evolving language, what
will the required C++ version be? What would our policy be on updating
it?
3. How will we be sure about edges around language mismatches in C
and C++? For instance, they have different rules regarding unions,
which we make liberal use of.
4. C++ has many features and some are controversial. Will any be
disallowed such as exceptions?

There is one part of C++ specifically that I think could be pretty
nice if we can figure out all the details: compile-time evaluation of
the string hash function. This could make dealing with
well-known/compile-time strings easier.

3

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

4

On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison <levi.morrison@datadoghq.com> wrote:

On Sun, Aug 11, 2024 at 4:54 PM Lanre <lnearwaju@gmail.com> wrote:

Hello,

I’m considering adding some C++ enhancements to the Zend API. These changes would be encapsulated within #ifdef __cplusplus guards, so they wouldn’t interfere with the existing C implementation. The primary goal is to provide a nicer interface for extensions while maintaining compatibility with C.

Key points:

  • Struct-based Approach: Everything will still use structs—no classes or non-public/non-static members.
  • Isolation: Any enhancements that can be isolated from the C implementation will be, and they will reside in a common zend_api_cxx header file.
  • Proposed Enhancements:
  • Constructors and destructors, along with comparison operator overloads for zval.
  • Constructor overloads for common zval initializations.
  • Member methods for common zval operations.

I’m happy to implement and maintain these changes. Since this doesn’t affect userland, do you think an RFC is necessary?

Also, if anyone has suggestions or ideas for this C++ API, I’d love to hear them.

Cheers,
Lanre

I am not opposed, but there are some logistics questions:

  1. Since it’s for extensions and not core, how will we be sure it is
    maintained? What will test it?
  2. Since it’s in core, and C++ is a rapidly evolving language, what
    will the required C++ version be? What would our policy be on updating
    it?
  3. How will we be sure about edges around language mismatches in C
    and C++? For instance, they have different rules regarding unions,
    which we make liberal use of.
  4. C++ has many features and some are controversial. Will any be
    disallowed such as exceptions?

There is one part of C++ specifically that I think could be pretty
nice if we can figure out all the details: compile-time evaluation of
the string hash function. This could make dealing with
well-known/compile-time strings easier.

  1. As for testing, we can implement either a second zend_test extension or add the tests to the current one.
  2. C++ is indeed a rapidly evolving language, I suggest starting with a conservative approach by targeting a stable C++ version that balances modern features with broad compatibility—C++17 or C++20 could be good candidates. As for updating the required version, we could establish a policy where we review the C++ version every couple of years, aligning it with broader trends in C++ adoption and compiler support across platforms. This would help us avoid potential fragmentation or compatibility issues.
  3. As long as we stick to the struct based approach, we should be fine regarding the common edge cases. The idea is to keep the structs compatible with C while supporting C++ features
  4. To maintain a clean and consistent API, I suggest we disallow certain C++ features like exceptions. Exceptions could introduce complexity and unpredictability, especially when mixed with C’s error handling mechanisms.

Overall, the goal is to use C++ to enhance the API without compromising the stability and simplicity of the C core. We can focus on C++ features that bring clear benefits, such as stronger type safety and cleaner abstractions, while avoiding those that might introduce unnecessary complexity.

Cheers,

Lanre

5

On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

You aren’t making any sense. Why would we remove the old way? Or why should that be a prerequisite to improving the current API? How are functions that simply proxy the C API inherently ‘more brittle, potentially less secure, and harder to maintain’? You haven’t even seen the code in question?

TVal(const zval *other) : TVal() { ZVAL_COPY(this, other); }
TVal(zend_long value) : TVal() { ZVAL_LONG(this, value); }
TVal(int value) : TVal() { ZVAL_LONG(this, value); }
TVal(size_t value) : TVal() { ZVAL_LONG(this, value); }
TVal(bool value) : TVal() { ZVAL_BOOL(this, value); }
TVal(std::string_view value) : TVal() { ZVAL_STRINGL(this, value.data(), value.size()); }
TVal(double value) : TVal() { ZVAL_DOUBLE(this, value); }
TVal(const char *value) : TVal() { ZVAL_STRING(this, value); }
TVal(const std::string &value) : TVal() { ZVAL_STRINGL(this, value.c_str(), value.size()); }
bool IsNull() const { return Z_TYPE_P(this) == IS_NULL; }
bool IsTrue() const { return Z_TYPE_P(this) == IS_TRUE; }
bool IsFalse() const { return Z_TYPE_P(this) == IS_FALSE; }
bool IsBool() const { return Z_TYPE_P(this) == IS_TRUE || Z_TYPE_P(this) == IS_FALSE; }
bool IsLong() const { return Z_TYPE_P(this) == IS_LONG; }
bool IsDouble() const { return Z_TYPE_P(this) == IS_DOUBLE; }
bool IsString() const { return Z_TYPE_P(this) == IS_STRING; }
bool IsArray() const { return Z_TYPE_P(this) == IS_ARRAY; }
bool IsObject() const { return Z_TYPE_P(this) == IS_OBJECT; }
bool IsInstanceOf(zend_class_entry *ce) const {
return Z_TYPE_P(this) == IS_OBJECT && (ce == Z_OBJCE_P(this) || instanceof_function(Z_OBJCE_P(this), ce));
}
bool IsCallable() const { return zend_is_callable((zval *) this, 0, nullptr); }
bool IsResource() const { return Z_TYPE_P(this) == IS_RESOURCE; }
bool IsReference() const { return Z_ISREF_P(this); }

The above is a snippet from my current implementation, so please elaborate on which part of that is so crazy to you.

Cheers,
Lanre.

6

On Mon, Aug 12, 2024, 11:03 PM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

if anything, I would rather go with rust (zig would have my preference ;-). The benefits would be to have a significant ease to contribute for many.

Neither of c++ or rust would be easy to add. The later would have the huge advantage to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c++ makes zero sense in 2024 for php (or any other language), a strong and bold take :slight_smile:

best,
Pierre

7

On Mon, Aug 12, 2024 at 10:50 AM Pierre Joye <pierre.php@gmail.com> wrote:

On Mon, Aug 12, 2024, 11:03 PM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

if anything, I would rather go with rust (zig would have my preference ;-). The benefits would be to have a significant ease to contribute for many.

Neither of c++ or rust would be easy to add. The later would have the huge advantage to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c++ makes zero sense in 2024 for php (or any other language), a strong and bold take :slight_smile:

best,
Pierre

Lol it’s been a long morning, thanks for the laugh. Look through php’s source code, do you see any mention of rust or zig? or any references to their compilers? PHP already supports C++20 (https://github.com/php/php-src/blob/master/build/php_cxx_compile_stdcxx.m4) and has at least one extension implemented in c++.

Do you genuinely believe that it makes more sense to add support for a new language (rust/zig) that will require its own compiler (that isn’t installed anywhere by default), than to improve support for a language already part of php?

Humor me and elaborate on why you think that ‘c++ makes zero sense in 2024 for php (or any other language),’

Cheers,
Lanre.

8

On Tue, Aug 13, 2024, 12:07 AM Lanre <lnearwaju@gmail.com> wrote:

On Mon, Aug 12, 2024 at 10:50 AM Pierre Joye <pierre.php@gmail.com> wrote:

On Mon, Aug 12, 2024, 11:03 PM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

if anything, I would rather go with rust (zig would have my preference ;-). The benefits would be to have a significant ease to contribute for many.

Neither of c++ or rust would be easy to add. The later would have the huge advantage to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c++ makes zero sense in 2024 for php (or any other language), a strong and bold take :slight_smile:

best,
Pierre

Lol it’s been a long morning, thanks for the laugh. Look through php’s source code, do you see any mention of rust or zig? or any references to their compilers? PHP already supports C++20 (https://github.com/php/php-src/blob/master/build/php_cxx_compile_stdcxx.m4) and has at least one extension implemented in c++.

any of them won’t happen anyway, being realistic.

My point, while the last paragraph was slightly provocative, is as realistic as it can be.

Adding thin layers to support external deps using c++ is a necessity and it is self contained without any other impact, and straightforward.

Adding c++ to the engine, or worst replacing it with c++, is non sense in 2024.

If we were starting from scratch, why not, if the majority of the few contributors master it. But afaict it is not the case.

Extensions/sapi are already being written using other languages than C (and a few in go) btw.

Besides, long term, it brings direct support for many targets which are harder using c/c++, wasi/wasm f.e. (for a trendy one).

side note, we did not see them in the kernel(s) (windows or linux) btw, and yet there are here.

ps: I still know the code there, a bit :wink:

best,
Pierre

9

On Mon, Aug 12, 2024 at 11:29 AM Pierre Joye <pierre.php@gmail.com> wrote:

Adding thin layers to support external deps using c++ is a necessity and it is self contained without any other impact, and straightforward.

It appears we are on the same page unless you are misunderstanding my proposal. I’m not adding C++ to the engine, it’s already there, I just want to improve the support for c++ without any impact on the current C api. As it stands now, you can’t even have a std::vector since the default destructor doesn’t perform any cleanup. I am not proposing replacing anything in the engine with c++.

Cheers,
Lanre.

10

On Mon, Aug 12, 2024 at 10:19 AM Lanre <lnearwaju@gmail.com> wrote:

On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison <levi.morrison@datadoghq.com> wrote:

On Sun, Aug 11, 2024 at 4:54 PM Lanre <lnearwaju@gmail.com> wrote:

Hello,

I’m considering adding some C++ enhancements to the Zend API. These changes would be encapsulated within #ifdef __cplusplus guards, so they wouldn’t interfere with the existing C implementation. The primary goal is to provide a nicer interface for extensions while maintaining compatibility with C.

Key points:

  • Struct-based Approach: Everything will still use structs—no classes or non-public/non-static members.
  • Isolation: Any enhancements that can be isolated from the C implementation will be, and they will reside in a common zend_api_cxx header file.
  • Proposed Enhancements:
  • Constructors and destructors, along with comparison operator overloads for zval.
  • Constructor overloads for common zval initializations.
  • Member methods for common zval operations.

I’m happy to implement and maintain these changes. Since this doesn’t affect userland, do you think an RFC is necessary?

Also, if anyone has suggestions or ideas for this C++ API, I’d love to hear them.

Cheers,
Lanre

I am not opposed, but there are some logistics questions:

  1. Since it’s for extensions and not core, how will we be sure it is
    maintained? What will test it?
  2. Since it’s in core, and C++ is a rapidly evolving language, what
    will the required C++ version be? What would our policy be on updating
    it?
  3. How will we be sure about edges around language mismatches in C
    and C++? For instance, they have different rules regarding unions,
    which we make liberal use of.
  4. C++ has many features and some are controversial. Will any be
    disallowed such as exceptions?

There is one part of C++ specifically that I think could be pretty
nice if we can figure out all the details: compile-time evaluation of
the string hash function. This could make dealing with
well-known/compile-time strings easier.

  1. As for testing, we can implement either a second zend_test extension or add the tests to the current one.
  2. C++ is indeed a rapidly evolving language, I suggest starting with a conservative approach by targeting a stable C++ version that balances modern features with broad compatibility—C++17 or C++20 could be good candidates. As for updating the required version, we could establish a policy where we review the C++ version every couple of years, aligning it with broader trends in C++ adoption and compiler support across platforms. This would help us avoid potential fragmentation or compatibility issues.
  3. As long as we stick to the struct based approach, we should be fine regarding the common edge cases. The idea is to keep the structs compatible with C while supporting C++ features
  4. To maintain a clean and consistent API, I suggest we disallow certain C++ features like exceptions. Exceptions could introduce complexity and unpredictability, especially when mixed with C’s error handling mechanisms.

Overall, the goal is to use C++ to enhance the API without compromising the stability and simplicity of the C core. We can focus on C++ features that bring clear benefits, such as stronger type safety and cleaner abstractions, while avoiding those that might introduce unnecessary complexity.

Cheers,

Lanre

Also I already implemented a compile time version of the string hash function (for one of my extensions), feel free to use it if you need (https://gist.github.com/oplanre/e384ed2a4c0fea698ed0e15d24157611) but it most likely won’t be part of this PR/RFC

Cheers,
Lanre

11

On Aug 12 2024, at 12:27 pm, Lanre lnearwaju@gmail.com wrote:

On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

You aren’t making any sense. Why would we remove the old way? Or why should that be a prerequisite to improving the current API? How are functions that simply proxy the C API inherently ‘more brittle, potentially less secure, and harder to maintain’? You haven’t even seen the code in question?

I think I’m making perfect sense. I don’t think it’s a good idea to have two ways of doing the same thing. Having two ways means twice the tests, twice the potential security issues, and twice the maintenance. This is not a simple thing you are suggesting – I highly doubt any move to C++ is going to end as a simple wrapper (which I assume is what you’re implying by your code block), even if the first PR merged starts that way.

FWIW I agree 100% with Pierre as well – both his political and non-political answer :slight_smile: – if the project was to consider anything I’d love to see Rust get some love.

12

On Mon, Aug 12, 2024 at 12:33 PM John Coggeshall <john@coggeshall.org> wrote:

On Aug 12 2024, at 12:27 pm, Lanre <lnearwaju@gmail.com> wrote:

On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall <john@coggeshall.org> wrote:

I’m considering adding some C++ enhancements to the Zend API.

I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secure, and harder to maintain codebase. The win of making it easier / “nicer” on a subset of developers who might prefer a C++ interface isn’t anywhere near worth the risk IMO.

You aren’t making any sense. Why would we remove the old way? Or why should that be a prerequisite to improving the current API? How are functions that simply proxy the C API inherently ‘more brittle, potentially less secure, and harder to maintain’? You haven’t even seen the code in question?

I think I’m making perfect sense. I don’t think it’s a good idea to have two ways of doing the same thing. Having two ways means twice the tests, twice the potential security issues, and twice the maintenance. This is not a simple thing you are suggesting – I highly doubt any move to C++ is going to end as a simple wrapper (which I assume is what you’re implying by your code block), even if the first PR merged starts that way.

FWIW I agree 100% with Pierre as well – both his political and non-political answer :slight_smile: – if the project was to consider anything I’d love to see Rust get some love.

I didn’t realize this was an open mic for Rust devs to flaunt their ignorance, but since you’ve decided to chime in, let me spell it out for you. Rust has absolutely nothing to do with this discussion, so try to stay on topic. Nowhere did I mention a move to C++; perhaps reading comprehension isn’t your strong suit.

PHP already supports C++ for extensions, as evidenced by the intl extension. The current support is painfully basic, which forces developers to waste time on redundant wrappers or use third-party libraries like PHP-CPP. What I’m proposing is a way to improve this support so C++ devs don’t have to keep doing the same menial work over and over again.

All of this will be wrapped in macros, so C compilers won’t even notice the compatibility layer and will compile as usual. It’s a simple, elegant solution—something you might not be familiar with, given your affinity for Rust’s convoluted approach to everything.

Cheers,
Lanre.

13

lol. Listen friend, I’ve been involved in PHP internals on and off for over 20 years – and so has Pierre. You’d do well to respond with a little more consideration instead of flying off the handle calling us ignorant rust developers lol.

The idea of enhancing support for C++ makes no sense. It’s a waste of time and energy. The entire industry is actively trying to to move AWAY from C/C++ in general, not to mention someone has to maintain it after you get bored insulting people here and move on. This is doubly true when the benefit is a handful of people who want to might write some extension in C++.

On Aug 12 2024, at 2:59 pm, Lanre lnearwaju@gmail.com wrote:

I didn’t realize this was an open mic for Rust devs to flaunt their ignorance, but since you’ve decided to chime in, let me spell it out for you. Rust has absolutely nothing to do with this discussion, so try to stay on topic. Nowhere did I mention a move to C++; perhaps reading comprehension isn’t your strong suit.

PHP already supports C++ for extensions, as evidenced by the intl extension. The current support is painfully basic, which forces developers to waste time on redundant wrappers or use third-party libraries like PHP-CPP. What I’m proposing is a way to improve this support so C++ devs don’t have to keep doing the same menial work over and over again.

All of this will be wrapped in macros, so C compilers won’t even notice the compatibility layer and will compile as usual. It’s a simple, elegant solution—something you might not be familiar with, given your affinity for Rust’s convoluted approach to everything.

Cheers,
Lanre.

14

On Mon, Aug 12, 2024 at 1:36 PM John Coggeshall <john@coggeshall.org> wrote:

lol. Listen friend, I’ve been involved in PHP internals on and off for over 20 years – and so has Pierre. You’d do well to respond with a little more consideration instead of flying off the handle calling us ignorant rust developers lol.

The idea of enhancing support for C++ makes no sense. It’s a waste of time and energy. The entire industry is actively trying to to move AWAY from C/C++ in general, not to mention someone has to maintain it after you get bored insulting people here and move on. This is doubly true when the benefit is a handful of people who want to might write some extension in C++.

On Aug 12 2024, at 2:59 pm, Lanre <lnearwaju@gmail.com> wrote:

I didn’t realize this was an open mic for Rust devs to flaunt their ignorance, but since you’ve decided to chime in, let me spell it out for you. Rust has absolutely nothing to do with this discussion, so try to stay on topic. Nowhere did I mention a move to C++; perhaps reading comprehension isn’t your strong suit.

PHP already supports C++ for extensions, as evidenced by the intl extension. The current support is painfully basic, which forces developers to waste time on redundant wrappers or use third-party libraries like PHP-CPP. What I’m proposing is a way to improve this support so C++ devs don’t have to keep doing the same menial work over and over again.

All of this will be wrapped in macros, so C compilers won’t even notice the compatibility layer and will compile as usual. It’s a simple, elegant solution—something you might not be familiar with, given your affinity for Rust’s convoluted approach to everything.

Cheers,
Lanre.

It’s impressive that you’ve been involved with PHP internals, but it’s clear you haven’t a clue about what I’m proposing and are contributing nothing of value. You’d have to be seriously naive to believe that “the entire industry is actively trying to move AWAY from C/C++.”

The fact is, C is still the backbone of nearly everything. If you’re building anything that interacts with an OS or embedded device, you’re either writing in C/C++ (C++ for Windows) or working with some C wrapper. Rust’s approach to low-level implementation is laughable unless you’re prepared to abuse unsafe or use Cranelift. Even simple things like JIT optimizations are considered unsafe in Rust.

Swift, which is heavily used in macOS, is essentially an LLVM wrapper—meaning it relies on C++. The recent advancements in Swift’s interop with C++ highlight just how crucial C++ remains. Then there’s Adobe apps, Microsoft products, browsers, and virtually every game and game engine that are all implemented in C++.

So, unless you’re living in a fantasy world where everyone is abandoning proven technology for glorified scripting languages, I suggest you step back and recognize the reality of the situation.

I’m sure the idea of enhancing C++ makes no sense to you, and would be a waste of your time and energy, but not everyone is that stupid/incompetent so even if i do get bored of maintaining it, literally any C++ dev can pick it up, it really is that simple.

Cheers,

Lanre.

15

On Mon, Aug 12, 2024 at 9:00 PM Lanre <lnearwaju@gmail.com> wrote:

I didn’t realize this was an open mic for Rust devs to flaunt their ignorance, but since you’ve decided to chime in, let me spell it out for you. Rust has absolutely nothing to do with this discussion, so try to stay on topic. Nowhere did I mention a move to C++; perhaps reading comprehension isn’t your strong suit.

May I remind you again that we expect all participants on this list to
be polite. Ad-hominem attacks are not tolerated. Please freshen up on
the mailing list rules.

Ilija

16

Friend, honest to god you are really not doing yourself any favors here.

You came on this list with a proposal. I think it’s a bad idea, and I’ve enumerated the reasons why I have come to that conclusion:

  • If it’s so easy and transparent to improve support for C++, it could easily exist outside of core as a set of header files to make the lift lighter for someone looking to use it. Sounds like that project already exists (no idea, didn’t look into it).

  • Even if it’s “easy” with a few header files, it’s still adding a whole new thing required to maintain the project because now someone has to own and maintain a C++ API and every change to the “real” C engine needs a corresponding C++ API update. Who here long-term is going to own that engine-level API and make sure it’s “the C++ way”…you? The way you’re behaving I wouldn’t trust you to not rage-quit today… so who then? What happens if there is a conflict between “the C way” and “the C++ way” in regards to a new engine-level API down the road? What kind of extra thought / energy / consideration do we need to put into engine-level API changes in the future because now we have to maintain two distinct engine APIs?

  • If it’s not so easy and transparent (e.g. requiring us to start modifying the engine because C++ isn’t happy), I’m opposed to the idea because conceptually I’d like to see any such effort spent on improving support for a future-looking language. I honestly don’t care what that is, but considering Linux’s recent embracing of Rust I think that’s got some merit to consider. For the record, I don’t personally even code in Rust so attacking me like I’ve got a horse in that race is pretty ridiculous.

  • I don’t believe that just because something is prevalent means it’s good. Entire governments are starting to recommend not using C/C++ because of the security risks posed by its non-existent memory safety. If PHP was being written today, it wouldn’t have been written in C.

Don’t like I don’t agree with you? Okay. It’s a public mailing list, and everyone here has an opportunity to chime in and voice their opinion. I’ll give you a nickel’s worth of free advice though – speaking from personal experience I’d be happy to tell you about over a beer one day – not only are you violating the rules of the list, but you’re not helping your cause and you just look like an @!#%$% who is screaming louder and louder because someone doesn’t agree with them. Please stop, for your own sake.

What is 100% clear to me is that, even if there is a good reason to go down this road, IMO it absolutely should go through an RFC process as I said up front because just with what I’ve thought of enumerated above there are a lot of questions here that I don’t see any reason to believe you’ve thought through, even if I try to ignore your constant insults.

17

On Tue, Aug 13, 2024, 3:16 AM Lanre <lnearwaju@gmail.com> wrote:

I’m sure the idea of enhancing C++ makes no sense to you, and would be a waste of your time and energy, but not everyone is that stupid/incompetent so even if i do get bored of maintaining it, literally any C++ dev can pick it up, it really is that simple.

Your previous reply related to the misunderstanding about your proposal (engine vs extension support) was enough.

Now, this reply and the previous one go way beyond an acceptable, respectful discussion. Please stop it and reconsider the way your communicate your disagreements or arguments.

18

On Aug 12, 2024 at 4:13 PM, <Lanre> wrote:

You’d have to be seriously naive to believe that “the entire industry is actively trying to move AWAY from C/C++.”

Well, there is this:

https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF

-Mike

19

On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel <mike@newclarity.net> wrote:

On Aug 12, 2024 at 4:13 PM, <Lanre> wrote:

You’d have to be seriously naive to believe that “the entire industry is actively trying to move AWAY from C/C++.”

Well, there is this:

https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF

-Mike

The source mentions Python and Swift as “memory-safe languages,” both of which are implemented in C and C++. How does that work if C and C++ aren’t memory-safe?

Mozilla introduced Rust years ago, yet Firefox remains primarily C++, with only about 3% of the codebase in Rust. By dismissing C and C++, one overlooks the fact that they are crucial for powering everyday systems such as elevators, automotive control units (ECUs, ADAS), medical devices, consumer electronics, industrial automation, and more.

It IS naive to believe that “the entire industry is actively trying to move AWAY from C/C++.”.

Cheers,
Lanre.

20

On 2024-08-14 16:03, Lanre wrote:

On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel <mike@newclarity.net

    Well, there is this:

    https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF

    -Mike

The source mentions Python and Swift as "memory-safe languages," both of which are implemented in C and C++. How does that work if C and C++ aren't memory-safe?

Cheers,
Lanre.

The same way Legolas can be called an elf even when the character is being played by a human actor: by not making category errors.

Even if the compiler of a Swift program has a memory management failure, that is not the fault of the Swift program, but of the compiler (and the language it is written in that allowed it).