Migrated the entire existing codebase from C to C++
Added extern "C" wrappers for all exported functions to ensure full C API compatibility
Adapted XTDK to work seamlessly with both C and C++ code
Performed extensive refactoring:
reorganized variables and functions into classes
added initializers and getters/setters to ensure proper data encapsulation
Reworked libxtos:
now built from the entire kernel code
optimized to avoid being fully statically linked with the bootloader
Extended the SDK packaging:
the entire SDK is now installed and archived
includes not only compiled libraries but also headers necessary to build code against the kernel
Agreements
I have read the Contributors License Agreement and I consent to those terms.
## Proposed changes
- Migrated the entire existing codebase from C to C++
- Added extern "C" wrappers for all exported functions to ensure full C API compatibility
- Adapted XTDK to work seamlessly with both C and C++ code
- Performed extensive refactoring:
- reorganized variables and functions into classes
- added initializers and getters/setters to ensure proper data encapsulation
- Reworked libxtos:
- now built from the entire kernel code
- optimized to avoid being fully statically linked with the bootloader
- Extended the SDK packaging:
- the entire SDK is now installed and archived
- includes not only compiled libraries but also headers necessary to build code against the kernel
## Agreements
- [x] I have read the Contributors License Agreement and I consent to those terms.
Do we need to typecast each bool operation? In C this returned integer value and compiler knew how to cast it into our BOOLEAN enum. In C++, result value is of bool type that cannot be automatically typecasted into enum.
Do we need to typecast each bool operation? In C this returned integer value and compiler knew how to cast it into our BOOLEAN enum. In C++, result value is of bool type that cannot be automatically typecasted into enum.
No, we do not have to. Alternatively, I can suggest moving the BOOLEAN type definition from xttypes.h to xtcompat.h:
#ifdef __cplusplus
/* C++ definitions */
#define XTCLINK extern "C"
#define NULLPTR nullptr
/* C++ boolean type */
typedef bool BOOLEAN, *PBOOLEAN;
#define TRUE true
#define FALSE false
/* C++ widechar type */
typedef wchar_t wchar;
#else
/* C definitions */
#define XTCLINK
#define NULLPTR ((void *)0)
/* C boolean type */
typedef enum _BOOLEAN
{
FALSE = 0,
TRUE = 1
} BOOLEAN, *PBOOLEAN;
/* C widechar type */
typedef unsigned short wchar;
#endif
This will allow us to maintain backward compatibility with C and get rid of explicit typecasts at the same time.
This should also work in the case of the quoted fragment, even though the result of the operation is not of type bool but int. The result of the expression will be 0 if the flag is not set, or the value of COMPORT_FLAG_INIT if it is. It is only the comparison of this result, for example (SerialPort.Flags & COMPORT_FLAG_INIT) != 0, that actually yields a bool type.
Please let me know if you accept this, then I will commit the proposed change.
No, we do not have to. Alternatively, I can suggest moving the BOOLEAN type definition from xttypes.h to xtcompat.h:
```
#ifdef __cplusplus
/* C++ definitions */
#define XTCLINK extern "C"
#define NULLPTR nullptr
/* C++ boolean type */
typedef bool BOOLEAN, *PBOOLEAN;
#define TRUE true
#define FALSE false
/* C++ widechar type */
typedef wchar_t wchar;
#else
/* C definitions */
#define XTCLINK
#define NULLPTR ((void *)0)
/* C boolean type */
typedef enum _BOOLEAN
{
FALSE = 0,
TRUE = 1
} BOOLEAN, *PBOOLEAN;
/* C widechar type */
typedef unsigned short wchar;
#endif
```
This will allow us to maintain backward compatibility with C and get rid of explicit typecasts at the same time.
This should also work in the case of the quoted fragment, even though the result of the operation is not of type bool but int. The result of the expression will be 0 if the flag is not set, or the value of COMPORT_FLAG_INIT if it is. It is only the comparison of this result, for example (SerialPort.Flags & COMPORT_FLAG_INIT) != 0, that actually yields a bool type.
Please let me know if you accept this, then I will commit the proposed change.
You are right, this results in int, not bool. There are more such changes like this in the diff, and I added a comment to the first one, as its the only one that fits on first page. unfortunately. Never mind, I think the proposed solution will be OK.
You are right, this results in int, not bool. There are more such changes like this in the diff, and I added a comment to the first one, as its the only one that fits on first page. unfortunately. Never mind, I think the proposed solution will be OK.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Proposed changes
Agreements
@@ -0,0 +398,4 @@BOOLEANDebug::SerialPortReady(){return (BOOLEAN)(SerialPort.Flags & COMPORT_FLAG_INIT);Do we need to typecast each bool operation? In C this returned integer value and compiler knew how to cast it into our BOOLEAN enum. In C++, result value is of bool type that cannot be automatically typecasted into enum.
No, we do not have to. Alternatively, I can suggest moving the BOOLEAN type definition from xttypes.h to xtcompat.h:
This will allow us to maintain backward compatibility with C and get rid of explicit typecasts at the same time.
This should also work in the case of the quoted fragment, even though the result of the operation is not of type bool but int. The result of the expression will be 0 if the flag is not set, or the value of COMPORT_FLAG_INIT if it is. It is only the comparison of this result, for example (SerialPort.Flags & COMPORT_FLAG_INIT) != 0, that actually yields a bool type.
Please let me know if you accept this, then I will commit the proposed change.
You are right, this results in int, not bool. There are more such changes like this in the diff, and I added a comment to the first one, as its the only one that fits on first page. unfortunately. Never mind, I think the proposed solution will be OK.