RE: Named parameters
Note that a proposal for named arguments was recently presented to the C++ standards committee [1], and they did not seem receptive to it [2]. The proposal was for a different syntax (name : value), but the objections were not related to the syntax. Regards, Nate [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm [2] http://theres-waldo.ca/2014/11/23/trip-report-c-standards-meeting-in-urbana-champaign-november-2014/ (see list of rejected proposals in section "Evolution Working Group")
Re: g++ extension for Concepts TS
cc Andrew Sutton
From: gcc-ow...@gcc.gnu.org on behalf of Christopher Di
Bella
Sent: April 2, 2017 8:57 AM
To: gcc Mailing List
Subject: g++ extension for Concepts TS
Hey all,
I've been working on a concept extension that permits type aliases
inside the requires-seq.
The grammar addition is fairly simple.
```
requirement-seq
requirement
alias-declaration
requirement-seq requirement
```
Semantically, this change forces a requirement-body to open a new
scope to house the alias.
I've managed to get it working for variable concepts, but not function concepts.
It looks like type aliases for some concepts are tricking the compiler
into thinking that there are multiple statements.
For example:
```cpp
template
concept bool Foo =
requires(T a) {
using type = T;
using value_type = typename std::vector::value_type;
{a + a} -> value_type;
{a - a} -> type;
{a + a} -> typename std::vector::value_type;
{a - a} -> T;
};
```
works, but
```cpp
template
concept bool Foo() {
requires(T a) {
using type = T;
using value_type = typename std::vector::value_type;
{a + a} -> value_type;
{a - a} -> type;
{a + a} -> typename std::vector::value_type;
{a - a} -> T;
};
}
```
fails with
```
test.cpp: In function 'concept bool Foo()':
test.cpp:4:14: error: definition of concept 'concept bool Foo()' has
multiple statements
concept bool Foo() {
^~~
test.cpp: In function 'int main()':
test.cpp:17:10: error: deduced initializer does not satisfy
placeholder constraints
Foo i = 0;
^
test.cpp:17:10: note: in the expansion of concept '(Foo)()'
template concept bool Foo() [with T = int]
```
After some inspection, I've deduced that the issue is flagged in
constraint.cc:2527, where a DECL_EXPR is identified, instead of a
RETURN_EXPR.
I'm wondering if it's trivially possible to ignore these declarations?
E.g. a loop that somewhat resembles:
```cpp
while (body != TREE_NULL && TREE_CODE(STATEMENT_LIST_HEAD(body)) ==
DECL_EXPR && is also an alias declaration)
body = STATEMENT_LIST_TAIL(body);
if (body != TREE_NULL)
error...
// else cleared of all charges
```
Cheers,
Chris
Re: Tracing C++ template instantiations
> On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
>
> When I'm working on complicated template code and debugging a mixture
> of bugs in my templates and ICEs in g++ caused by my buggy templates I
> sometimes wish I could see a dump of all the templates that the
> compiler is instantiating, so I can see at which point in a
> deeply-nested instantiation things don't happen the way I expected
> them to. With variadic templates in particular it's sometimes hard to
> visualize what's happening to your code.
>
> Someone else asked for this the other day on gcc-help
> (http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
> I'd take a look at implementing it. It turns out that or class
> templates all that's needed is something like:
> verbatim ("instantiating class template %qT", type)
> in instantiate_class_template_1 in gcc/cp/pt.c
> Presumably it wouldn't be much harder to do the same for function templates.
>
> Is there something that does this already that I've missed? If I were
> to add a switch like -ftrace-template-instantiation to control this,
> is there any chance of getting it accepted?
>
> It might be useful if the trace said something like:
> attempting to instantiate foo...
> attempting to instantiate foo::baz ...
> successfully instantiated foo::baz
> failed to instantiate foo
> with nesting to see which instantiations depend on others and to see
> which pass/fail, but I've already found it useful just to see a list
> of instantiations, in order to verify whether some refactoring reduces
> the number of instantiations.
>
> Would anyone else find this useful, or should I just keep it in my own
> source tree for my own use?
+1 for this feature. I would find it very useful too!
Regards,
Nate.
C++11 no longer experimental
Hello, Now that the C++11 standard has been officially voted in, there is nothing "experimental" about it any more. Would it be possible to remove the warning about GCC's C++11 support being experimental from http://gcc.gnu.org/projects/cxx0x.html, and to modify the __GXX_EXPERIMENTAL_CXX0X__ macro to be just __GXX_CXX0X__ (or even better, __GXX_CXX11__)? Thanks, Nate
new C++11 features in GCC 4.7
Hi, I'm wondering, are there are other new C++11 features planned for GCC 4.7 besides "Extended friend declarations" and "Explicit virtual overrides" (which are marked as already implemented at http://gcc.gnu.org/projects/cxx0x.html)? Thanks, Nate
missing return statement
Hello,
So many times I write code like this:
SomeType function()
{
SomeType result;
// do something with result
return result;
}
except I often forget the "return result" statement.
Why does gcc not give an error about this?
If I compile with "-Wall", it will give a WARNING saying
"control reaches end of non-void function".
However, shouldn't it be an ERROR to return nothing
from a function that's supposed to return something?
Does this not result in undefined behaviour? Why goes gcc allow it?
Thanks,
Nate.
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734
RE: missing return statement
> On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
>> Nathan Ridge wrote:
>>
>>> Why does gcc not give an error about this?
>>> If I compile with "-Wall", it will give a WARNING saying
>>> "control reaches end of non-void function".
>>> However, shouldn't it be an ERROR to return nothing
>>> from a function that's supposed to return something?
>>> Does this not result in undefined behaviour? Why goes gcc allow it?
>>
>> Because the standard does not make this an error, you can't tell
>> if anyone needs a result, perhaps function is always called in
>> a void environment.
>>
>> A warning is all you can get, always pay attention to warnings!
>
> The standard does make it an error, in that if such a function
> (meaning a function that unconditionally falls off the end, when
> declared to return a value) is called _at all_ then undefined behavior
> results. More general cases can't be established at compile time, of
> course.
>
> To be conservative, a compiler would issue the error only at the call
> site, with possibly a warning (as gcc does) for the definition.
>
> -- James
I get no error when I compile the following code, even though a call to the
function does take place:
class A {};
A function()
{
A result;
}
int main()
{
function();
return 0;
}
Regards,
Nate.
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734
g++ segfault when using C++0x feature
Hello,
The attached minimal code (test.cpp) causes g++ to
segfault. It uses the C++0x features variadic templates and initializer
lists.
The command used to compile it is:
g++ -std=c++0x test.cpp
The output is:
test.cpp: In function ‘void f(const Args& ...) [with Args = ]’:
test.cpp:21: instantiated from here
test.cpp:16: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The output of "g++ -v" is:
Using built-in specs.
Target: i486-linux-gnu
Configured
with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --enable-targets=all
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
I also attached the preprocessed source file, as requested (test.ii when
compiling using -save-temps).
Please let me know if you need any more information.
Regards,
Nate. #include
template
class my_vector
{
public:
my_vector(std::initializer_list l);
template
my_vector(InputIterator first, InputIterator last);
};
template
void f(const Args&... args)
{
my_vector commands{args...};
}
int main(int argc, const char** argv)
{
f();
}
test.ii
Description: Binary data
internal compiler error in gcc trunk when using std::map
Hello,
I've just build the gcc trunk and tried to compile some code that compiled fine
with gcc 4.5.
It gave an internal compiler error.
I've reduced it to the following minimal test case:
#include
#include
int main()
{
std::map m;
std::pair p;
m.insert(p);
return 0;
}
Here's the command used to compile:
g++-4.6 --std=c++0x test.cpp
Here's the output:
In file included from
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ice.cpp:1:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor âconstexpr std::pair<_T1, _T2>::pair(const std::pair<_U1,
_U2>&) [with _U1 = std::basic_string, _U2 = int, _T1 = const
std::basic_string, _T2 = int]â:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:780:68:
instantiated from âconst bool
std::__is_convertible_helper, int>&,
std::pair, int>, false>::__valueâ
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:787:12:
instantiated from âstd::is_convertible,
int>&, std::pair, int> >â
test.cpp:8:15: instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:107:43:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
And here's the output of g++-4.6 -v:
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../src/configure --program-suffix=-4.6 --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101209 (experimental) (GCC)
Thanks,
Nate.
gcc interprets C++0x initialization construct as function declaration
Hello,
For the following code:
struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}
gcc 4.6 trunk gives the following errors (with the --std=c++0x option):
decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{'
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token
It seems gcc is interpreting the statement as a function declaration.
Is this the desired behaviour?
Regards,
Nate.
RE: std::count leaked outside namespace std?
> Here's a simple program:
>
> #include
> #include
>
> int main()
> {
> std::vector vec;
> count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
> }
>
> The above compiles successfully, but I think it shouldn't. I expect a
> message like "error: `count` not declared in scope" because I meant to
> say std::count. Isn't this a bug, or am I missing something?
It is not a bug. std::count is being found by argument-dependent lookup [1].
Regards,
Nate
[1] http://en.wikipedia.org/wiki/Argument-dependent_name_lookup
PR 50025 (uniform initialization of class member of reference type)
Hi, I'm just wondering, is there any chance of fixing PR 50025 [1] soon? It concerns uniform initialization of a class member of reference type. I have been using GCC to do C++11 development for a while now, and this one bug has been a bit of an eyesore IMO, that has been keeping the "uniform" out of uniform initialization. I think a lot of people would be happy to see thix fixed! Thanks, Nate [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
> Lots of warnings like this: > > ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally > defined but not used [-Wunused-local-typedefs] > > when building 1.54.0 with gcc-4.8.1 (fedora f19) This warning is new in GCC 4.8, and I have been seeing a ton of them not just in boost, but in every codebase I've built. IMO gcc should not have this warning turned on by default. CC'ing the gcc folks. Regards, Nate
RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
> On 3 July 2013 02:41, Nathan Ridge wrote: >>> Lots of warnings like this: >>> >>> ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally >>> defined but not used [-Wunused-local-typedefs] >>> >>> when building 1.54.0 with gcc-4.8.1 (fedora f19) >> >> This warning is new in GCC 4.8, and I have been seeing a ton of them >> not just in boost, but in every codebase I've built. > > It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html I stand corrected. (What's new in 4.8 is it being included in -Wall, which is why I never noticed it in 4.7). > It affects Boost more than most code because of the prevalent use of > concept checks and static assertions which are usually implemented > using typedefs but only conditionally compiled. I've seen spews of that warning for other large projects, such as clang or wxWidgets, not just boost. Would GCC consider removing it from -Wall? >> CC'ing the gcc folks. > > That's not very helpful because posting to the Boost list is > subscription only (you'll have two copies of this mail, because the > first one I sent from an address subscribed to the GCC list but not > this one.) My apologies. Regards, Nate
RE: Could we start accepting rich-text postings on the gcc lists?
> > Similarly for text-only vs. "rich text". You may argue that there's no > > compatibility issue, but I disagree. As was pointed out upthread, when > > people use "rich text", they often start to use colors or other mechanisms > > to express themselves, which can now be dependent on the rendering agent > > used to read the email. Requiring people to express themselves using only > > words seems to me to encourage the sorts of discipline that we require in > > contributors. > > We disagree on this point, then. While rich-text can be abused, it is > not my experience that people do abuse it to the point of making their > postings illegible. The markings you see commonly used are monospace > font alterations, bolding and lists. I have noticed no correlation > between the ability to use a markup language and quality of > contributions. I am regular reader of several mailing lists, some of which (such as this one) require plain text, and some (like cdt-dev) which allow rich text. My experience has been that the formatting of messages on plain-text lists is consistent across the board, while on rich-text lists you get a mess by mixing together different formatting conventions. A prominent example is the formatting convention used for quoting the message you're replying to. Plain-text lists always use one convention: greater-than signs (>) before each line of the quote, one for each level of quoting. On rich-text lists, some messages use greater-than signs, some use a vertical line to the left of the text, some use a different color, etc. The result is a mess that's difficult to follow. I think rich-text works well when everyone uses the same mail client. For example, at a company I used to work, for everyone used Microsoft Outlook as their mail client, and emails were sent in rich text. There was no readability problem there because everyone used the same formatting conventions. However, requiring that everyone that posts to a public mailing list use the same mail client is even more restrictive than requiring that they use plain text. The only other way to ensure consistency of formatting conventions is to use the lowest common denominator between mail clients, which is plain text. Regards, Nate
