pros icon indicating copy to clipboard operation
pros copied to clipboard

PROS 4: Change Various Structs/Enums to pros namespace, instead of being in pros::c, change all enums to be enum classes

Open WillXuCodes opened this issue 3 years ago • 2 comments
trafficstars

Currently, we have many structs and enums (namely in imu.h and gps.h) that should probably be in the pros namespace rather than the pros::c namespace. This is to have a better distinction between what is part of the "pros::c" API vs default C++ pros API. Since the PROS API is primarily C++, we want to minimize interaction with the ::c namespace for users of the C++ only API.

However, I'd like to get some input on this tbh. May or may not be a good change and it's definently something we want as a PROS 4 thing to prevent user confusion on PROS 3.

Good representation of what I'm talking about https://github.com/purduesigbots/pros-docs/pull/268

WillXuCodes avatar Apr 05 '22 02:04 WillXuCodes

as long as they're defined with C linkage, POD types are fine to define in C++ and use in C. so depending on what level of support is wanted for a low level C API, we have some options.

if we want to go full on C++ it doesn't matter we can just do whatever. probably a better move would be to define two levels of structure for each logical unit, where a POD type contains the relevant data to call down to the C API and a more complex type that has all the member functions etc.

this is sort of what we do now but it would make the relationship more formal. I'm thinking something like

namespace pros {
namespace impl {

extern "C" struct motor_data {
    std::uint8_t port;
    // whatever else idk
}

} // namespace impl

class Motor : impl::motor_data {
    // ...
}

} // namespace pros

HotelCalifornia avatar Apr 05 '22 02:04 HotelCalifornia

Also, for PROS 4 we should start transitioning enums into enum classes to be a more C++ focused API.

WillXuCodes avatar Jun 05 '22 22:06 WillXuCodes