[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [4diac-dev] Migrating forte to +11
|
On 12.06.20 09:50, Martin Melik-Merkumians wrote:
Hi,
And here std:vector would definitly improve the situation compared to our single linked list. However I made the experience that stdlibs pull in stuff that cause the allocation of some memory areas which can be >bad and needs to be monitored.
As the original implementer of the Singly Linked List in FORTE, this was the main reason. Std:lib pulled a lot of additional stuff into FORTE and bloated code size
I use C++17 routinely on Cortex-M class hardware and even on AVR 8-bit
MCUs, and these days the bloat argument no longer holds. In fact, using
C++ features allowed the compiler to optimize code that I would not have
done manually. Example at hand: 5 almost-same unrolled loops because
every cycle matters for that application -- made it a function template
with some constexpr, instantiated it 5 times, and it worked. Previously,
it didn't work. Manually written generic loops were too slow, and
specialisation by hand (a.k.a. copy & paste) was too big.
As for the features I know to work well on microcontrollers: vector,
array, functional, exceptions, and the C++ Core Guidelines Support
Library -- but of course none of iostreams, those are
bloat^H^H^H^H^Hfeature-laden indeed. The more I think about it, maybe
link-time optimisation (LTO) is actually the reason it works for me so
well. It throws away unused code on a much finer granularity than the
traditional linker.
Also the option to get bounds checking on all array accesses via .at()
has been a real time saver. Strong run-time type safety is really a
productivity and security gain.
All these arguments make it important to find out what platforms do not
support C++11 yet.
Generically speaking, I think it is reasonable to require support for an almost 10 year old standard.
We're not the only ones who want to use modern C++.
In principle you are current, but we just had the case of a 4diac user using an old complier not capable of C++11 features and we do not know how many out there are in a similar situation.
If we upgrade we will kick some of our users at least for now. We and especially Alois has fought to broaden the user base in last years, and not only academic users but also industrial ones. From my perspective, this is an important point to consider beside from the already pointed out technical reasons.
Yes indeed, and I fully agree. Therefore it would be important to know
why that compiler did not have C++11 yet. What compiler was it that was
affected? I have been working with extremely conservative companies
(tooling-wise) as well, but even they got C++11 by now.
Regards,
--
Dipl.-Inform. Jörg Walter
Senior Researcher
R&D Group Distributed Computation and Communication
OFFIS e.V. - Institut für Informatik
FuE Bereich Produktion | R&D Division Manufacturing
Escherweg 2, 26121 Oldenburg - Germany
Phone/Fax.: +49 441 9722-729 / -282
E-Mail: joerg.walter@xxxxxxxx
URL: http://www.offis.de
Registergericht: Amtsgericht Oldenburg VR 1956
Vorstand: Prof. Dr.-Ing. Wolfgang H. Nebel (Vorsitzender),
Prof. Dr. techn. Susanne Boll-Westermann, Prof. Dr.-Ing. Axel Hahn,
Prof. Dr.-Ing. Andreas Hein, Prof. Dr. Sebastian Lehnhoff