Error constexpr does not name a type

Я пытаюсь скомпилировать этот код C ++, используя IDE Arduino 1.0.5-r2

#include <cstdint>
#include "mcal_reg.h"
class led
{
public:
// Use convenient class-specific typedefs.
typedef std::uint8_t port_type;
typedef std::uint8_t bval_type;

// The led class constructor.
led(const port_type p,
const bval_type b) : port(p),
bval(b)
{
// Set the port pin to low.
*reinterpret_cast<volatile bval_type*>(port)
&= static_cast<bval_type>(~bval);

// Set the port pin to output.
*reinterpret_cast<volatile bval_type*>(port - 1U)
|= bval;
}

void toggle() const
{
// Toggle the LED via direct memory access.
*reinterpret_cast<volatile bval_type*>(port)
^= bval;
}

private:
// Private member variables of the class.
const port_type port;
const bval_type bval;
};

namespace
{
// Create led_b5 on portb.5.
const led led_b5
{
mcal::reg::portb,
mcal::reg::bval5
};
}

int main()
{
// Toggle led_b5 in a loop forever.
for(;;)
{
led_b5.toggle();
}

И включаемый файл mcal_reg.h это:

  #ifndef _MCAL_REG_2011_11_04_H_
#define _MCAL_REG_2011_11_04_H_

#include <cstdint>

namespace mcal
{
namespace reg
{
constexpr std::uint8_t portb = 0x25U;

constexpr std::uint8_t bval0 = 0x01U;
constexpr std::uint8_t bval1 = 0x01U << 1U;
constexpr std::uint8_t bval2 = 0x01U << 2U;
constexpr std::uint8_t bval3 = 0x01U << 3U;
constexpr std::uint8_t bval4 = 0x01U << 4U;
constexpr std::uint8_t bval5 = 0x01U << 5U;
constexpr std::uint8_t bval6 = 0x01U << 6U;
constexpr std::uint8_t bval7 = 0x01U << 7U;
}
}

#endif // _MCAL_REGISTERS_2011_11_04_H_

}

Попытка скомпилировать приводит к следующей ошибке компиляции:

mcal_reg.h:17: error: 'constexpr' does not name a type

ссылаясь на эту строку:
constexpr std :: uint8_t portb = 0x25U;

Я установил каталог mcal_reg в моей папке библиотек, которая содержит файл mcal_reg.h. Это мой первый проект Arduino, и я пишу программу, которая будет установлена ​​на отдельном чипе AVR. Но я не могу скомпилировать эту программу. Мои системы — Windows 7. У меня есть только программное обеспечение, поставляемое с установленной Arduino IDE. (Нет отдельного GNU, MS Visual Studio … и т. Д.) Пожалуйста, помогите.

1

Чтобы использовать функции C ++ 11, такие как constexpr, вам необходимо обновить вашу IDE до текущей бета-версии (http://arduino.cc/en/main/software#toc3). А затем включите поддержку C ++ 11 через флаг компилятора -std=c++11,

Чтобы добавить флаг компилятора, найдите нужный platform.txt (см. Вот) а также
затем добавить / изменить на

## Compiler global definitions
compiler.path={runtime.ide.path}/tools/avr/bin/
compiler.c.cmd=avr-gcc
compiler.c.flags=-c -g -Os -w -ffunction-sections -fdata-sections -MMD -std=c++11

2

Description

Jakub Jelinek

2016-10-10 13:47:27 UTC

constexpr int a = 1;
with -std=c++98 gives
pr.C:1:1: error: ‘constexpr’ does not name a type; did you mean ‘constexpr’?
 constexpr int a = 1;
 ^~~~~~~~~
 constexpr
pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or -std=gnu++11

I'd say we should just not print the bogus "did you mean" if the identifier fuzzy matching found is the same as the one used originally.  Or not add constexpr into the suggestions in this case because it is not C++98?

Comment 1

Jonathan Wakely

2016-10-10 14:44:10 UTC

A similar thing happens with other C++11 keywords:

bad.cc:1:1: warning: identifier ‘decltype’ is a keyword in C++11 [-Wc++11-compat]
 decltype i = 0;
 ^~~~~~~~
bad.cc:1:1: error: ‘decltype’ does not name a type; did you mean ‘decltype’?
 decltype i = 0;
 ^~~~~~~~
 decltype

It's even worse in this case, because the code isn't valid even in C++11, so the fix-it can never be a useful change.

(In reply to Jakub Jelinek from comment #0)
> I'd say we should just not print the bogus "did you mean" if the identifier
> fuzzy matching found is the same as the one used originally.  Or not add
> constexpr into the suggestions in this case because it is not C++98?

Not adding non-C++98 keywords into the suggestions make sense, and would solve both of these examples. (Another option for the constexpr case would be to suggest dropping the -std=c++98/-std=gnu++98/-std=c++03/-std=gnu++03/-ansi option).

If there are still other ways that the match could end up being the same as the original then suppressing the "did you mean" would still make sense.

Comment 2

Jonathan Wakely

2016-10-10 14:47:35 UTC

(In reply to Jakub Jelinek from comment #0)
> pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> -std=gnu++11

Also this note isn't true, because it's also available with -std=gnu++14, or with no option, etc.

Comment 3

David Malcolm

2016-10-11 13:36:50 UTC

(In reply to Jakub Jelinek from comment #0)
> constexpr int a = 1;
> with -std=c++98 gives
> pr.C:1:1: error: ‘constexpr’ does not name a type; did you mean ‘constexpr’?
>  constexpr int a = 1;
>  ^~~~~~~~~
>  constexpr
> pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> -std=gnu++11
> 
> I'd say we should just not print the bogus "did you mean" if the identifier
> fuzzy matching found is the same as the one used originally.  Or not add
> constexpr into the suggestions in this case because it is not C++98?

If we accidentally add the goal string to the list of candidate strings when building the list, then we'll get the goal string back, with an edit distance of 0, and it will always be a bad suggestion.

So we probably should put a check for this case into get_best_meaningful_candidate.  It seems to me that doing so could mask an error: we've mispopulated the candidate list; the bad suggestion could still be offered if someone typed something similar (e.g. "consexpr" or somesuch).  But at least if they then try the suggestion, they'll get the:
  note: C++11 ‘constexpr’ only available with -std=c++11 or -std=gnu++11

So I think there are three parts to fixing this:
(a) fix get_best_meaningful_candidate to detect the distance == 0 case and return NULL
(b) filter the identifiers based on "-std" when figuring out the candidate strings
(c) update the note's text as noted in comment #2.

Comment 4

Martin Sebor

2016-10-11 15:07:20 UTC

(In reply to Jonathan Wakely from comment #2)
> (In reply to Jakub Jelinek from comment #0)
> > pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> > -std=gnu++11
> 
> Also this note isn't true, because it's also available with -std=gnu++14, or
> with no option, etc.

This is similar to the text of some other C++ diagnostics where GCC says something like "in C++ 11, this must be that" when the meaning is sometimes "in C++ 11 and prior" and other times "in C++ 11 and later."

As we discussed (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02422.html) I think it would be helpful to decide which style is clearer (or come up with one that is) and adopt it throughout.

Comment 5

David Malcolm

2016-11-14 21:21:54 UTC

Confirmed.  I'm working on a fix.

Comment 6

David Malcolm

2016-11-29 16:25:33 UTC

Author: dmalcolm
Date: Tue Nov 29 16:25:01 2016
New Revision: 242965

URL: https://gcc.gnu.org/viewcvs?rev=242965&root=gcc&view=rev
Log:
spellcheck bugfixes: don't offer the goal string as a suggestion

gcc/cp/ChangeLog:
	PR c++/77922
	* name-lookup.c (lookup_name_fuzzy): Filter out reserved words
	that were filtered out by init_reswords.

gcc/ChangeLog:
	PR c++/72774
	PR c++/72786
	PR c++/77922
	PR c++/78313
	* spellcheck.c (selftest::test_find_closest_string): Verify that
	we don't offer the goal string as a suggestion.
	* spellcheck.h (best_match::get_best_meaningful_candidate): Don't
	offer the goal string as a suggestion.

gcc/testsuite/ChangeLog:
	PR c++/72774
	PR c++/72786
	PR c++/77922
	PR c++/78313
	* g++.dg/spellcheck-c++-11-keyword.C: New test case.
	* g++.dg/spellcheck-macro-ordering.C: New test case.
	* g++.dg/spellcheck-pr78313.C: New test case.


Added:
    trunk/gcc/testsuite/g++.dg/spellcheck-c++-11-keyword.C
    trunk/gcc/testsuite/g++.dg/spellcheck-macro-ordering.C
    trunk/gcc/testsuite/g++.dg/spellcheck-pr78313.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/spellcheck.c
    trunk/gcc/spellcheck.h
    trunk/gcc/testsuite/ChangeLog

Comment 7

David Malcolm

2016-11-29 16:34:16 UTC

Should be fixed by r242965; marking as resolved.