[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [4diac-dev] Migrating forte to +11
|
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
> 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.
Best regards,
Martin
--------------------------------------------------
Dipl.-Ing. Martin Melik-Merkumians
Advanced Mechatronic Systems
Automation and Control Institute (ACIN)
TU Wien
DVR-Number: 0005886
Gusshausstr. 27-29, room CA-05-38
1040 Vienna, Austria
Phone: +43 (0)1 588 01 37688
Fax: +43 (0)1 588 01 937688
Email: melik-merkumians@xxxxxxxxxxxxxxxxx
http://www.acin.tuwien.ac.at/
--------------------------------------------------
-----Ursprüngliche Nachricht-----
Von: 4diac-dev-bounces@xxxxxxxxxxx <4diac-dev-bounces@xxxxxxxxxxx> Im Auftrag von Alois Zoitl
Gesendet: Donnerstag, 11. Juni 2020 12:16
An: 4diac developer discussions <4diac-dev@xxxxxxxxxxx>
Betreff: Re: [4diac-dev] Migrating forte to +11
hi jörg,
first of all i wanted to point out that I'm a big fan of how C++ evolved in the last years and I would like to embrace its usage in 4diac FORTE. However I'm now old enough to have made some bad experiences with C and C++ which made me cautious. Bad maybe this is anyhow outdated by now.
On Thu, 2020-06-11 at 04:15 +0200, Jörg Walter wrote:
> Hi Alois,
>
> On 10.06.20 21:02, Alois Zoitl wrote:
> > I have rather mixed feelings here. At first I see the cool features
> > of modern C++ (e.g., lambdas, const expr) which can help to improve code quality and flash size.
>
> Also think of more limited devices that cannot run forte yet (Cortex-M
> with 128k flash?). With these features, it would become easier to
> address such resource-constrained devices. Lots of compile-time
> optimisation beyond constexpr, much better control over memory through
> polymorphic memory resources. std::string with short string
> optimisation, the list of useful features is long.
flash was mostly not the biggest problem. We had that always quite well under control. Mostly it is RAM. 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. One reason for example why we have an own strtol implementation. using the standard C version pulled in a 6k array. On 64k RAM machine, on which I was testing at that time, this was really bad. Maybe this is better by now.
>
> Also think of security: Programming according to the C++ Core
> Guidelines will go a long way to eliminate accidental memory errors --
> although forte does not show any obvious flaws in this area, it hasn't
> been audited or penetration-tested, or has it?
This is definitely a concern I have.
>
>
> > However I also see that we have a very diverse community with many
> > different OSes (e.g., I hear that ThreadX is coming back via some
> > Microsoft initiative), different CPUs and memory capacity. While I thought most of our hardware will be arm and Linux based by now it looks not like that will come. Also RAM is still a crucial thing in many devices of our users. Just have a look at the current discussion in the forum.
>
> I would expect RAM usage to be lower with C++11 or later. But rare
> platforms are a problem indeed.
As pointed out above I got bad surprises so without measuring I would not say anything.
>
> Unlike the current cross-platform approach, I don't see an easy way to
> use C++11/14/17 features in a way that allows fallback implementations
> for platforms that don't have full library support for C++11 -- for
> example, there's a big difference between using constexpr and
> std::thread on FreeRTOS. I'd expect the former to be Just Working, the
> latter to require explicit FreeRTOS support in the standard library.
std::thread is one of my biggest concerns. Maybe with the popularity of freeRTOS on the cortexM3 series of controllers this will change hopefully soon.
>
> On the other hand, we already need C++ support. My experience is that
> people resist C++ on exotic platforms because of the misconception
> that it is inefficient or bloated, but we are already beyond that.
> Getting
> C++11 support as an upgrade should be much easier than getting C++
> support in the first place. 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++.
>
> As for C++ beyond 11, there is https://abseil.io, which maps C++14/17
> features to 11 if the compiler doesn't support the newer versions, and
> uses the native implementation if it does. That might be a pragmatic
> compromise.
Definitly worth looking into.
>
> We should probably begin by checking all platforms that forte
> officially supports. Do we even have access to all of them, or are
> some of them orphaned? We should maybe also explicitly ask users on
> which kind of systems they use forte, so we can discover exotic
> platforms we happen to support without knowing it.
That is one reason I'm happy that Jose brought this to the mailing list to bring it to a broader attention
>
>
> > Therefore, in order to not limit the applicability of 4diac FORTE I
> > think we should proceed here with great caution. Also I don't think we should spend our limited resources on the transformation because of transformation. Especially because of our great set of test case. Thanks to all who worked on that.
>
> I agree that if we do this step (which I really hope to become true),
> we should be fully aware what we break, that there are upgrade options
> for all users, and that these options are reasonable.
>
>
> > There are places where I see some immediate benefits (e.g.,
> > replacing our single linked list with STL vector), which can reduce our memory usage further. But it would need some experiments to see if STL is not bringing other drawbacks regarding memory (e.g., memory blocked by support functions).
>
> When talking about the big three (gcc, clang, Microsoft), using
> library features are highly likely to be better than a hand-coded solution.
> Regarding STL vector, polymorphic memory resources are very
> interesting for memory-constrained platforms (std::pmr:vector). That
> is a C++17 feature, however.
I think it is always better to use standard library. This removes code from 4diac FORTE making it easier to maintain and less stuff to test.
Therefore if I find time to work on 4diac FORTE I will mostly focus on areas to improve RAM usage or reduce concurrency issues. However given my current time budget and tasks I fear I'll mostly work on 4diac IDE in the next months.
Cheers,
Alois
>
>
> Regards,
_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
