Refactor different rules into implementation of private interface Algorithm.
Since IslamicCalendar is public in Java (not in C++), we cannot put them into different subclass of Calendar and have to let them use the same class and object since the caller UNFORTUNALLY can call setCalculationType and setCivil to change the object to different rule. With this refactoring, we group the formula for the same rule into the same Algorithm
implementaiton and now we only do the if/switch check in the constructor or during the call of setCalculationType and setCivil only. The calculation operation is then just delegate the work to the assigned concrete Algorithm.
Improve the efficency while the month is very large. Apply the same optimization in PR 2853 which estimate starting point of year iteration based on an inverse calculation.
ICU-22679 change parameter name
ICU-22679 Use Consumer
Test set+set, set+add, set+roll, add+add, roll+roll
Fix more int32_t overflow problems.
Optimize both Java and C++ Hebrew Calendar month/year advancement by first consider
every 235 months is 19 years before iteration.
This makes it possible to call public functions that take a string class
as a template parameter and return an object of that class (implemented
through the StringByteSink helper class) also with the CharString class,
even though this class doesn't actually provide the public API required
by StringByteSink.
This makes it possible to use such more modern APIs also internally.
The repeated sequence of allocating a CharString and CharStringByteSink,
before calling some function that writes into this, can be moved into a
single shared helper function which then is used to give all ulocimp.h
functions that write to ByteSink an overload that instead returns a
CharString, to make call sites look like perfectly normal C++ code.
The repeated sequence of allocating a CheckedArrayByteSink, calling some
function that writes into this, then checking for overflow and returning
through u_terminateChars() can all be moved into a single shared helper
function.
There's a subtle difference between these two ways of accessing the
value of an optional and that is that the value() method can throw an
exception if there isn't any value, but operator* won't do that (it's
just undefined behavior if there isn't any value).
ICU4C code never tries to access any optional value without first
checking that it exists, but the ability of the value() method to throw
an exception in case there wasn't any such check first is the reason why
std::exception symbols previously could show up in debug builds.
This reverts the changes that were made to dependencies.txt by
commit dc70b5a056.
tz2024a change "Asia/Qostanay" "Asia/Almaty" but test machines has
not yet update their zoneinfo to 2024a so we mark them as known issues
extern long timezone; in <time.h> (set man tzset on Linux shell)
returns wrong value when TZ=America/Scoresbysund
· No function should do anything if an error has already occurred.
· On error, a value of 0, nullptr, {}, etc., should be returned.
· Values shouldn't have overloaded meanings (eg. index or found).
· Values that are never used should not be returned at all.
- [x] Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-22671
- [x] Required: The PR title must be prefixed with a JIRA Issue number. <!-- For example: "ICU-1234 Fix xyz" -->
- [x] Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
- [x] Required: Each commit message must be prefixed with a JIRA Issue number. <!-- For example: "ICU-1234 Fix xyz" -->
- [ ] Issue accepted (done by Technical Committee after discussion)
- [ ] Tests included, if applicable
- [ ] API docs and/or User Guide docs changed or added, if applicable
When building icu4c, it defaults to clang instead of gcc when the default compiler, cc / c++, is a symlink to gcc / g++.
This not the expected behavior when building C and C++ code.
It appears that this behavior was put in place originally for supporting C++11, which hopefully is no longer such a concern.
This PR adjusts the configure.ac for icu4c to prefer the cc and c++ compilers first.
