Skip to content

2023 11 02 Eclipse iceoryx developer meetup

Jump to bottom
Mathias Kraus edited this page Nov 1, 2023 · 5 revisions

Eclipse iceoryx developer meetup

Date: 2023/11/02

Time: 17:00 CET

Link: https://app.element.io/jitsi.html#conferenceDomain=meet.element.io&conferenceId=JitsiVtfrqukadefbqiqfxryxabai&userId=&roomId=!AooDAAwkyNWwkMElpt%3Agitter.im&roomName=eclipse%2Ficeoryx&startWithAudioMuted=true&startWithVideoMuted=true&language=en

Attendees

Agenda

  1. Move the Developer meetup to another day or to an earlier time on the first Thursday in the month, 5 mins, Mathias "Bob" Kraus
    • Does anybody know why the meetup does not appear in the ROS calendar?
  2. Tasks and open issues from https://github.com/eclipse-iceoryx/iceoryx/wiki/2023-10-05-Eclipse-iceoryx-developer-meetup#minutes, 5 mins, Mathias "Bob" Kraus
  3. Softening the flat include structure a bit (iox/header.hpp, iox/posix/header.hpp and iox/concurrent/header.hpp), 10 mins, Mathias "Bob" Kraus
  4. Cleanup relevant issues for a v3.0 release (https://github.com/eclipse-iceoryx/iceoryx/projects/5), 15 min, Mathias "Bob" Kraus
  5. If there is time, talk about a common coding style for iceoryx, 15 min, Mathias "Bob" Kraus
    • currently it is different for parts of hoofs and the rest of the codebase
    • see also
    • proposal
      • CamelCase for classes to prevent confusion with STL types
      • snake_case for free functions and methods
      • snake_case for variables and members (members with a m_ prefix)
      • snake_case for type traits, they are similar to variables in template meta-programming after all
      • CamelCase for enums
      • SCREAMING_SNAKE_CASE for enum tags
      • SCREAMING_SNAKE_CASE for constants
    • it's basically what we have now but defines one style in case there are currently two in use
      • snake_case for some classes and methods in hoofs and dust
      • CamelCalse for classes and lowerCamelCase for methods in the remaining codebase
      • since the API surface in posh is smaller than in hoofs or dust, going with snake_case for methods should have the lesser impact than the other way around
      • we can provide a using declaration for classes with snake_case during the v3 lifetime with a doxygen deprecation warning
      • deprecate snake_case classes with v4 using the C++ deprecate attribute
      • if someone wants to keep the snake_case classes it is a simple using declaration in their code
      • for methods and functions we could think of a similar strategy

Minutes

Clone this wiki locally