C++11: Modernize codebase

[behdad]

I'm designing the iterator structs that I need badly for subsetting GSUB/GPOS, and I'm hitting walls. I really need decltype or auto, and not just for convenience. I suggest we switch to C++11 now, which means older compiler support ends at the end of current year.

Also, suggest we make all our headers declare namespace HB. And we remove a lot of hb_ prefixes from internal functions.

Since C++11 will be required, we can remove a lot of hacks. It was becoming really taxing to support older compilers, specially the ambiguous-operator ones.

[behdad]

(Re iterators, I'm reinventing ranges it seems..)

[behdad]

Ebrahim and I also discussed elsewhere, about switching from unsigned int to unsigned. I started doing that in hb-iter... That, and dropping redundant inline and void, and using auto, make code a lot more compact and pleasant. So I suggest we go ahead with unsigned. Am undecided whether I like to use signed instead of int though.

[lemzwerg]

I vote against C++11. Projects like TeXLive, which are intended to run on a very broad range of operating systems, have already nightmares because of poppler (not only because it uses C++11 but also because of ABI incompatibilities). Luatex, for example, is in the process of abandoning poppler for exactly these reasons. It would be a pity if HarfBuzz would cause similar issues.

I'll write an e-mail to the TeXLive list, pointing to this tracker issue. Maybe other people will chime in.

[behdad]

I'll write an e-mail to the TeXLive list, pointing to this tracker issue. Maybe other people will chime in.

Thanks.

Not requiring C++11 has become a major headache, and with the iterators I need to design, pretty much impossible to continue. I doubt C++11 itself is a problem. Let's see what TeXLive list thinks.

It's not like we don't need to support very weird systems. OpenJDK needs to compile HarfBuzz after all. @prrace

[behdad]

For the record, what I'm proposing will not introduce any ABI incompatibility issues. We still won't be using libstdc++, and won't expose any C++ API / ABI.

[ebraminio]

decltype is available since VS2010 and gcc 4.3 per Wikipedia, pretty much the oldest compilers we already support anyway (didn't check the our bots yet however) so we can skip making harfbuzz C++11 only for now I guess.

To be honest I am not that interested on unsigned int to unsigned plan, just a personal opinion.

Also, suggest we make all our headers declare namespace HB. And we remove a lot of hb_ prefixes from internal functions.

Great. I like this very much!

[behdad]

decltype is available since VS2010 and gcc 4.3 per Wikipedia, pretty much the oldest compilers we already support anyway (didn't check the our bots yet however) so we can skip making harfbuzz C++11 only for now I guess.

What about auto?

[ebraminio]

Apparently since GCC 4.4 (ref) and VS2010 (ref) but some compiler flags will be need to silence our bots for both case I guess.

[vtorri]

i consider 'unsigned' as a modifier, and not a data type, even if in C ANSI, 'unsigned' is synonym of 'unsigned int'

[khaledhosny]

If it is for internal code, I prefer explicit unit32_t and int32_t and the likes instead of unsigned int and int, for public API I was under the impression that the general wisdom is to unsigned int over bare unsigned.

[behdad]

i consider 'unsigned' as a modifier, and not a data type, even if in C ANSI, 'unsigned' is synonym of 'unsigned int'

In reality, the size of int is unimportant (large enough is good), whereas signedness is important and consequential and intentional. So, I see the size as the modifier (short long nothing) and integer just implied because most common.

[behdad]

If it is for internal code, I prefer explicit unit32_t and int32_t and the likes instead of unsigned int and int, for public API I was under the impression that the general wisdom is to unsigned int over bare unsigned.

To me uint32_t implies a specifity that is not intentional.

[khaledhosny]

Right, if the side does not matter then int should be fine (it can’t be smaller than 32-bit on systems we support anyway). Still, I have been bitten by old code making assumptions about the side of int, long etc. that broke badly on 64-bit systems (AFDKO, I’m looking at you!) that I’d rather be safe than sorry.

[behdad]

Right. I'm all for not making assumptions. The only assumption we make is 4 <= sizeof(int).

[prrace]

For OpenJDK, I will check with build folks, and I also would like to check with SAP who
maintain the AIX port. Some ARM port might be the other case with an issue.