C or C++

[zherczeg]

We discussed this question last time, but there was no clear decision. Today this question is raised again, since the PI default compiler is only GCC 4.7. We might also need to support exotic architectures, where we stuck with proprietary compilers, and they might not even support C++.

I think postponing this question is not wise, since we might reach a point, where there is no turning back. It would be great to have a decision about the minimum compiler requirements. My personal preference is C99, but anything is good for me. Just lets have a decision.

[seanshpark]

I think using C++ compiler for more optimised code generation was the reason. People say there are many benefits using C++. For embed systems people say its better with C. IMHO, complexity management is important and with C, it could become a nightmare.

BTW, for as RPi, this is what I got.

/.../iotjs/deps/jerry/jerry-core/lit/lit-literal-storage.cpp:432:30: error: 
template-id 'alloc_record<lit_magic_record_t>' for 
'lit_magic_record_t* rcs_recordset_t::alloc_record(rcs_recordset_t::record_t::type_t)' 
does not match any template declaration

I tried with JerryScript only but could not solve plugin compile/link problem in short time.
What I used;

• Compiler : https://github.com/raspberrypi/tools.git
• Add 'tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin' to PATH
• temporar branch: https://github.com/seanshpark/iotjs/tree/armcc_dev
• 'deps/libuv/armv6linux-configure' file for building libuv for RPi

#!/bin/bash

export AR=arm-bcm2708hardfp-linux-gnueabi-ar
export CC=arm-bcm2708hardfp-linux-gnueabi-gcc
export CXX=arm-bcm2708hardfp-linux-gnueabi-g++
export LINK=arm-bcm2708hardfp-linux-gnueabi-g++
export PLATFORM=linux

./gyp_uv.py -Dtarget_arch=arm -DOS=linux

• JerryScript patch on 'iotjs-with-lit-storage-and-temp-eval' branch

diff --git a/jerry-libc/CMakeLists.txt b/jerry-libc/CMakeLists.txt
index f384d92..79f4249 100644
--- a/jerry-libc/CMakeLists.txt
+++ b/jerry-libc/CMakeLists.txt
@@ -104,6 +104,8 @@ set(COMPILE_FLAGS_LIBC "${COMPILE_FLAGS_JERRY} ${C_FLAGS_JERRY}")
   set(DEFINES_LIBC ${DEFINES_LIBC} ${DEFINES_LIBC_X86_64})
  elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
   set(DEFINES_LIBC ${DEFINES_LIBC} ${DEFINES_LIBC_ARMV7})
+ elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv6")
+  set(DEFINES_LIBC ${DEFINES_LIBC} ${DEFINES_LIBC_ARMV7})
  elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86")
   set(DEFINES_LIBC ${DEFINES_LIBC} ${DEFINES_LIBC_X86})
  else()

• how to build iotjs

./tools/build.py --buildtype=release \
--target-arch=armv6 --target-os=linux \
--noinit-submodule

• RPi2 is OK. it's armv7l as I used arm-gcc 4.8. https://github.com/Samsung/iotjs/wiki/Porting-to-Raspberry-Pi-2 show how I've done.

[zherczeg]

My experiences usually the other way: it is true that C forces you to handle complexity, and the best way to handle complexity is defining simple rules you follow. That is why C programs are so small and efficient. With C++, templates and operator overloading can generate huge amount of code. And classes are an excellent way to loose control of complexity.

Anyway, I am just working on built-ins so whatever you prefer is good for me. I just want to know the available language features when writing new code.