• BaardFigur@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    It wish it was that easy. It is a deep rooted problem, because of several other factors.

    There’s not just one function that is l dependant on the ringbuffer, but multiple functions in multiple libs and dll’s. Some if these dll’s and libs are used by us, some are used by another department and some are used by both. It has to stay C-code, in order for both departments to be able to use the library. The other department is using pInvoke to call it from a C#-application, or from other dlls. We use it as library in a C+±application, but also for us it might happen indirectly by being called from other libs or dlls. A proper fix is therefore an immense task, and requires coordinations between multiple teams.

    About deprecation, well, we handle warnings as errors, so adding a deprecated-attribute wouldn’t compile. I could add a warning-assert, but that annoys some of the senior developers, and then I have to remove it again.

    About code review, many of the seniors often don’t do them and just commit directly…

    To sum up, it’s easier to phase it out instead of turning everything upside down.