Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C or C++ #173

Closed
zherczeg opened this issue Jun 11, 2015 · 2 comments
Closed

C or C++ #173

zherczeg opened this issue Jun 11, 2015 · 2 comments
Labels
discussion Ongoing discussion

Comments

@zherczeg
Copy link
Member

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
Copy link
Contributor

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;

#!/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

@zherczeg
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Ongoing discussion
Projects
None yet
Development

No branches or pull requests

3 participants