Cinder incompatible with C++ modules in Gcc

[fedapo]

When using C++ modules on an application that uses Cinder compilation with Gcc fails.

I believe the errors are due to Gcc limitations (a bug?), Clang is not affected and compiles correctly.
Nevertheless, Cinder could play nice and easily fix the Gcc problem while also resulting in code that is a tiny bit cleaner.

This is the error:

/home/user/Cinder/include/cinder/ImageIo.h:48:81: note: existing declaration ‘typedef enum cinder::ImageIo::DataType cinder::ImageIo::DataType’
   48 |         typedef enum DataType { UINT8, UINT16, FLOAT32, FLOAT16, DATA_UNKNOWN } DataType;
      |                                                                                 ^~~~~~~~
/home/user/Cinder/include/cinder/ImageIo.h:47:65: error: conflicting imported declaration ‘typedef enum cinder::ImageIo::ColorModel cinder::ImageIo::ColorModel’
   47 |         typedef enum ColorModel { CM_RGB, CM_GRAY, CM_UNKNOWN } ColorModel;
      |                                                                 ^~~~~~~~~~
/home/user/Cinder/include/cinder/ImageIo.h:47:65: note: existing declaration ‘typedef enum cinder::ImageIo::ColorModel cinder::ImageIo::ColorModel’
   47 |         typedef enum ColorModel { CM_RGB, CM_GRAY, CM_UNKNOWN } ColorModel;
      |                                                                 ^~~~~~~~~~
/home/user/Cinder/include/cinder/ImageIo.h:51:56: error: conflicting imported declaration ‘typedef enum cinder::ImageIo::ChannelType cinder::ImageIo::ChannelType’
   51 |                                         CHAN_UNKNOWN } ChannelType;
      |                                                        ^~~~~~~~~~~
/home/user/Cinder/include/cinder/ImageIo.h:51:56: note: existing declaration ‘typedef enum cinder::ImageIo::ChannelType cinder::ImageIo::ChannelType’
   51 |                                         CHAN_UNKNOWN } ChannelType;
      |                                                        ^~~~~~~~~~~
/home/user/my_app/src/MyApp.cpp:32:6: note: during load of binding ‘::MyApp@MyApp’
   32 | void MyApp::setup()
      |      ^~~~~

Cinder's headers are placed only in the global module fragment of the C++ module's code, as they should.

module;

#include <cinder/GeomIo.h>
#include <cinder/CameraUi.h>
#include <cinder/app/App.h>
#include <cinder/gl/gl.h>

export module MyApp;

// ... actual code of the module interface

In order to silence the error enum definitions should be converted from this:

	typedef enum ColorModel { CM_RGB, CM_GRAY, CM_UNKNOWN } ColorModel;

To this:

	enum ColorModel { CM_RGB, CM_GRAY, CM_UNKNOWN };

I have tried this change and after that everything works. I believe Cinder would not get worse after this. Using a typedef in all enum and struct definitions is not necessary in C++ and it looks a lot like a leftoever style that was only needed in C.

I can propose a pull request with the change above. What are the chances that it gets approved? What are the reasons for objecting to it?

[andrewfb]

Hi @fedapo - thanks for looking at this, and I'd be up to merge this change. Would you be able to reformat your PR #2402? Right now there's a lot of changes that are formatting changes, rather than isolated removals of the typedef.

[fedapo]

Sure.
The changes are really due to vscode that automatically deletes trailing spaces (my setting), but I can revert that.
I'll post here a note as soon as it's done.

[fedapo]

@andrewfb I've reverted all changes that affected trailing blanks. The PR should be more focused on the actual issue now.

Would it be beneficial to do one single large commit to clean all trailing spaces?
The hash of this commit can be published in a .git-blame-ignore-revs file, so that it can be ignored from the history of changes. Github tools (e.g. blame) take this file into account, command-line tools can use the flag --ignore-revs-file.
I could take charge of this change, of course.

[andrewfb]

Thanks very much for this, @fedapo - merged now.

Re: trailing spaces (and other formatting issues), I appreciate the suggestion - and you’re right about .git-blame-ignore-revs mitigates a lot of the usual issues. That said, we're intentionally holding off on repo-wide formatting changes for the time being. We’re already mostly standardized on clang-format, and I want to do any full normalization in a single pass alongside a larger history-rewriting maintenance update to reduce repo size. Until then, I’d prefer to avoid incremental formatting-only commits, even for whitespace.