C++

[egavrin]

Hi folks,
We'd like to use the following C++ features in our code base:

• class
  • single inheritance
    • reduce source code size
  • copy / move constructors
    • improve perf.
    • much simplifies GC related logic
  • virtual functions (very limited, advisable usage)
    • reduce cross-module dependencies
• constexpr
  • improve perf, reduce code size
• static_assert
  • quality
• static_cast (already used), reinterpret_cast
  • quality
• try/catch (only for ECMA exception handling, instead of completion_value)
  • performance, simplifies code
• enum classes (desirable: replace all enums with enum classes)
  • quality (type safety)
• assignment operator implementation (very limited usage)
  • simplifies code
  • may be, other operators, for example, to replace ecma_number_add with simple '+')
• explicitly instantiated templates (very limited, advisable usage, controlled with -fno-implicit-templates)
  • reduce source code size

What do you think about this?

[zherczeg]

Ruben will decide this so I am reassigning this to him.

[ruben-ayrapetyan]

@zherczeg, this list was prepared by @egavrin, @sand1k and me. We've shared it for your review.

[egavrin]

@zherczeg very strange behavior. We prepared this list to discuss with you.

[akosthekiss]

Hi guys. I cannot wholeheartedly support C++ in a very constrained environment like what we are aiming to target with JerryScript. Although it is true that static_assert, casts, and enum classes can improve type safety, and several above-listed feaures reduce source code size, but isn't binary size (and runtime memory usage) what we would like to keep at minimum? E.g., I'm truly concerned about the EH frames that try/catch-es would introduce. Inheritance and templates also ring the alarm bell in the back of my mind. Is there a proof-of-concept work that could show the effect of the proposed changes to the measurable properties of the project (binary size, memory usage, performance)? I'd definitely like to see the results of some experiments that underpin the hypotheses above before we make a decision with such a future-defining effect.

[zherczeg]

I agree with Akos. We should prove somehow that these features are useful from our perspective before using it. I think we should decide our target benchmark suites first, where we can measure progression. What do you think of SunSpider?

[egavrin]

@zherczeg regarding benchmarks I see not many options for now:

• ubench (fully supported)
• several SunSpider 1.0.2 benchmarks (several benchmarks are supported)
• possibly several Kraken ones

[zherczeg]

These are ok for me. We should also decide the platform where we do measurements. I think the STM4 boards would be a good choice, since it has an ARM Thumb2 32-bit CPU, which is the most likely target for our engine.

Perhaps an automated measurement system would be the best option, where we can submit patches, and it measures these patches and compare them to trunk automatically. We should measure: runtime, memory consumption, and binary size (release with -Os optimization). The measurement system could upload the results to github automatically (part of the CI).

[egavrin]

STM measurements may take much time. Additionally, these boards are not stable and sometimes require manual reconnect. I'd prefer ARM board with Linux on board, like RaspPi.