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 commonzend_api_cxx
header file. -
Proposed Enhancements:
- Constructors and destructors, along with comparison operator overloads
forzval
. - Constructor overloads for common
zval
initializations. - Member methods for common
zval
operations.
- Constructors and destructors, along with comparison operator overloads
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
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:
- Since it's for extensions and not core, how will we be sure it is
maintained? What will test it? - 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? - 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. - 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.
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.
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.
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 :) -- if the project was to consider anything I'd love to see Rust get some love.
On Mon, Aug 12, 2024 at 12:33 PM John Coggeshall john@coggeshall.org
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 :) -- 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.
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++.
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.
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++.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.
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.
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.
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:
-Mike
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:
-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.
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 <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).
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:
-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?
This is the wrong analyze and approach. How many issues happen the past
years in the core of a language vs the apps using it would be a better data.
As another example, go is written in go btw.
My argument about using other languages to write extensions or sapi for php
is about ease the development and allow more people to do it. FrankenPHP is
a very good example. There are others.
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.
Some of my code running automates on z80 still run. Yet, newer models use
mips cpu and C.
Similarly cobol is still used, so are some c cgi applications.
It IS naive to believe that “the entire industry is actively trying to move
AWAY from C/C++.”.
you are extrapolating for the sake of it. Every industry has a certain
latency to move from one tech to another (or non tech).
It does not prevent new solutions to grow and be used.
also the main topic being how to handle the few cases using c++
dependencies have been elegantly solved already.
On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel mike@newclarity.net
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:
-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?This is the wrong analyze and approach. How many issues happen the past
years in the core of a language vs the apps using it would be a better data.As another example, go is written in go btw.
My argument about using other languages to write extensions or sapi for
php is about ease the development and allow more people to do it.
FrankenPHP is a very good example. There are others.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.Some of my code running automates on z80 still run. Yet, newer models use
mips cpu and C.Similarly cobol is still used, so are some c cgi applications.
It IS naive to believe that “the entire industry is actively trying to
move AWAY from C/C++.”.
you are extrapolating for the sake of it. Every industry has a certain
latency to move from one tech to another (or non tech).It does not prevent new solutions to grow and be used.
also the main topic being how to handle the few cases using c++
dependencies have been elegantly solved already.
This conversation is a waste of both of our times, have a wonderful day,
cheers.
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.
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
Ilija
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 :)
best,
Pierre
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 :)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.
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 :)best,
PierreLol 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 ;-)
best,
Pierre
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<zval> since the default
destructor doesn't perform any cleanup. I am not proposing replacing
anything in the engine with c++.
Cheers,
Lanre.
On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison levi.morrison@datadoghq.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 commonzend_api_cxx
header file.- Proposed Enhancements:
- Constructors and destructors, along with comparison operator
overloads forzval
.- 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,
LanreI am not opposed, but there are some logistics questions:
- Since it's for extensions and not core, how will we be sure it is
maintained? What will test it?- 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?- 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.- 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.
- As for testing, we can implement either a second zend_test extension or
add the tests to the current one. - 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. - 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 - 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
On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison levi.morrison@datadoghq.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 commonzend_api_cxx
header file.- Proposed Enhancements:
- Constructors and destructors, along with comparison operator
overloads forzval
.- 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,
LanreI am not opposed, but there are some logistics questions:
- Since it's for extensions and not core, how will we be sure it is
maintained? What will test it?- 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?- 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.- 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.
- As for testing, we can implement either a second zend_test extension or
add the tests to the current one.- 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.- 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- 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
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.
Hi Lanre,
This thread seems to have become quite heated, perhaps because people tend to have strong opinions about different programming languages.
It might help reset the discussion to draft a quick RFC outlining what is being proposed, and why.
I think some key things that would need to be considered are:
-
Why does this belong in the core repository, vs a separate library such as PHP-CPP? Would it be easier to have it maintained by people familiar with the core engine, but not with C++, rather than people outside the project, but familiar with C++? Are there technical reasons why some features require / benefit from being part of the same files / directories as the C API? Are there potential uses for things which are already in the core, such as bundled extensions?
-
Does this imply the PHP project "blessing" C++ in some way, over other languages? Or does it imply we could/should have similar wrappers for other languages, such as Rust and Go? (Ignoring any personal views, both are in active use in similar contexts, and a quick search turned up https://docs.rs/ext-php-rs/latest/ext_php_rs/ and https://github.com/deuill/go-php)
-
What guarantees can/should we provide about the stability and maintenance of these additional API elements? Note that this crosses over with point 1 - a separate library can make breaking changes on a different cycle to the core project, and even add C++ (or Rust, Go, etc) APIs for already released versions of the engine.
Regards,
Rowan Tommins
[IMSoP]