e2 studioでC++ソースでのINDEXER/CODANの調子が悪そうなので調べてみようと思います

こんにちは、NoMaYです。

先日、別スレッドをきっかけに、最近のe2 studioでは(実は結構昔から？)プロジェクトウィザードでGNURXやCC-RXのC++プロジェクトを作成する場合にもRXスマートコンフィグレータを選択可能になっていることを知りました。同時に、C++ソースに対してはCソースよりもe2 studioのINDEXER/CODANの調子が悪そうなことも知りました。そこで、ちょっと調べ始めてみました。

脱線しますけど、実は、C++標準ヘッダファイルのインクルードパスのことを何とかしてもまだ挙動がおかしいので、string等のヘッダファイルを追っていて気になったのですが、C++標準ヘッダファイル(というかC++標準ライブラリ)はGPLなのかな？(例外条項が付与されているのであまり厳しくないでしょうけど。) 無知を晒すことになりそうですが、てっきりnewlibにC++版があるのだと思ってました、、、

GNURX 8.3.0.202102のC++標準ヘッダファイルstringの初めの部分(これはnewlibでは無いですよね、、、)

// Components for manipulating sequences of characters -*- C++ -*-

// Copyright (C) 1997-2018 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.

// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.

// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
// <www.gnu.org/.../>.

/** @file include/string
 *  This is a Standard C++ Library header.
 */

　
他方、GNURX 8.3.0.202102のC標準ヘッダファイルstring.hの初めの部分(これはnewlibですよね、、、)

/*
 * string.h
 *
 * Definitions for memory and string functions.
 */

#ifndef _STRING_H_
#define    _STRING_H_

#include "_ansi.h"
#include <sys/reent.h>
#include <sys/cdefs.h>
#include <sys/features.h>

#define __need_size_t
#define __need_NULL
#include <stddef.h>

#if __POSIX_VISIBLE >= 200809
#include <xlocale.h>
#endif

#if __BSD_VISIBLE
#include <strings.h>
#endif

> 本来は以下のようにC++標準ヘッダファイルのインクルードパスがe2 studioに自動認識されているべき
プロジェクトプロパティの「C/C++一般」→ Preprocessor Include ... の
「エントリー」タブ「GNUC++」で、「CDTユーザー設定項目」に
${TCINSTALL}/rx-elf/include/c++/${GCC_VERSION}
${TCINSTALL}/rx-elf/include/c++/${GCC_VERSION}/backward
${TCINSTALL}/rx-elf/include/c++/${GCC_VERSION}/rx-elf
を追加してやっても解決できます。
(それぞれ入力時に「ファイル・システム・パス」を選択、"Treat as built-in","システム・ヘッダーを含む"にチェックを入れてください)
※ユーザー設定でない方に最初から入っていれば良かったということですね

コンパイル時にはエラーになっていないので、コンパイルオプションに追加しなくて済む分だけこちらの方が良いと思います。

みんさんこんにちは。

NoMayさん、ほやさんありがとう。

VSCode でも、gcc 系クロスコンパイラ設定で、インテリセンスが正しく動かなくて、色々設定をしていましたが、最近のバージョンでは、簡単な設定で、正しくincludeパスを認識するようになっています。

こんにちは、NoMaYです。

コトはインクルードパスだけで無く組み込みマクロ定義にも及んでいるようで、以下の画面コピーのようにコンパイルエラーになる箇所がe2 studioの編集ウィンドウで条件コンパイルのグレー表示になっている側である場合もあります。


　

コンパイラは201402L(C++14と同じ値)を返していますね。
C++1yとC++14は同じではないのでどうなんだというのはともかく、
他のスレッドでC++14や17が選択肢にない件が指摘されていますが、これも同様にUIが追い付けてない結果だと思います。
こうなる事が分っていれば騙されないのですが、非常に紛らわしくはあります。

こんにちは、NoMaYです。

e2 studio(というか元となっているEclipse)では、とあるオプションを指定してGCCを呼び出し、GCCからインクルードパスや組み込みマクロ定義の情報を自動的に取得するようになっています。(推測ですけど、VSCodeも同じメカニズムではないか、と思っているのです。) その時のオプションや取得した情報は、e2 studioの以下の画面コピーの設定を有効にすることで確認することが出来ます。

実際に確認してみて気になったのですが、Cソースに対するコマンド呼び出しとC++ソースに対するコマンド呼び出しが以下のようになっていましたが、MinGWでの知見から推測すると、本来は以下のようになっているべきだと思うのです。

e2 studioがGNURXから情報を取得する際に実際に発行しているコマンド (取得された情報ともども以下のzipに固めました。)

rx_e2studio_cpp_20210716.zip

Cソース: (正直なところ -std=gnu99 の出所が分かりません)
rx-elf-gcc -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -Wstack-usage=100 -g2 -mcpu=rx72t -misa=v3 -mlittle-endian-data -std=gnu99 -E -P -v -dD C:/Renesas/Work/workspaces/workspace_e2v202104/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c 

C++ソース:
rx-elf-gcc -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -Wstack-usage=100 -g2 -mcpu=rx72t -misa=v3 -mlittle-endian-data -std=c++1y -E -P -v -dD C:/Renesas/Work/workspaces/workspace_e2v202104/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c 
略
cc1.exe: warning: command line option '-std=c++14' is valid for C++/ObjC++ but not for C
略

　
MinGWでの知見から推測して本来そうあるべきだと思われるコマンド

Cソース: 実際の内容と同じ (もっとも、正確には -std=gnu99 の出所が分かりません、けれども)
rx-elf-gcc -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -Wstack-usage=100 -g2 -mcpu=rx72t -misa=v3 -mlittle-endian-data -std=gnu99 -E -P -v -dD C:/Renesas/Work/workspaces/workspace_e2v202104/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c 

C++ソース: 赤文字の箇所のようになっているべきな気がするのです (rx-elf-gcc ⇒ rx-elf-g++、 spec.c ⇒ spec.cpp)
rx-elf-g++ -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -Wstack-usage=100 -g2 -mcpu=rx72t -misa=v3 -mlittle-endian-data -std=c++1y -E -P -v -dD C:/Renesas/Work/workspaces/workspace_e2v202104/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.cpp

　
続く。

以下、e2 studioの画面コピーです。

e2 studioがGNURXからインクルードパスや組み込みマクロ定義の情報を自動的に取得した内容を確認したい時の設定


Cソースに対して得られた情報




C++ソースに対して得られた情報



　

CとC++の設定が共通なので、コマンドを呼び分けるにはファイル単位でオプションを設定してやる必要があります。面倒くさいですが。
LLVMのC++プロジェクトだとCとC++用の設定を別々に与えられ、かつコマンドも呼び分けるようになっていますが、それがあるべき姿なのかな、と思います。

こんにちは、NoMaYです。

あっ、苦節三昼夜、回避策を見付けた、かもしんない、、、

こんにちは、NoMaYです。

＞ C++ソース: 赤文字の箇所のようになっているべきな気がするのです (rx-elf-gcc ⇒ rx-elf-g++、 spec.c ⇒ spec.cpp)

推測ですけれど、これって、e2 studio(あるいはその前身のKPIT Eclipse)でC++プロジェクトがサポートされるようになった時から、ずーっと存在していた、(基本的なことだけれども幸か不幸か誰にも明確には気付かれてなかった)バグなのだろうなぁ、と私は思いました。

その当時(あるいは暫く後になってEclipseがC/C++の混在をサポートするようになったという可能性もありますが)に、e2 studio(あるいはその前身のKPIT Eclipse)の仕様(Cのみ or C++のみ)とEclipseの仕様(Cのみ or C++ではCとC++で別々に設定が可能)との間の溝を埋めようとして、C++プロジェクトではCソースに関してはGNU99であることに決め打ちしよう、といった判断が行われたのでは無いかと推測するのですが、そしてその結果、Cソースには出所不明の -std=gnu99 が付くことになったのかな、と推測するのですが、そこまでは気付いたけれど、rx-elf-g++にし忘れた(し忘れたままだった)、spec.cppにし忘れた(し忘れたままだった)、のではないかなぁ、と推測します。

見付けた(と思っている)回避策でどうにかなったとしても、これはルネサスさんに直して欲しいなぁ、と思うのです。

[追記]

新人のプログラマさんに画面付きユーザインターフェイスソフトの開発をお願いすると、ダイアログで設定した通りにソフトが動作するかとか、ウィンドウに表示されている内容が正しいかとか、その辺りをチェックせず、ダイアログを閉じて開いたら設定がとりあえず保持されている、ウィンドウにとりあえず何かが表示されている、でコトを済ませてしまうことがありますが、そんな感じだったのかもなぁ、と思ったりします。(でも、今になるまで明確には気付かれなかったのだから、当時のプログラマさんだけがどうのこうのということでも無いだろうなぁ、とも思ったりします。)

> そこまでは気付いたけれど、rx-elf-g++にし忘れた(し忘れたままだった)、

gccコマンドが呼ばれても、渡されたファイル名の拡張子で判断してg++が呼ばれるようになっているのでコンパイルは通ります。
それなりに使えるようになっているからそのままになってしまったのかもしれません。