On Sat, 14 Jun 2025 at 13:32, саша савельев wrote:
>
>
> To whom it may concern
>
> Why we can’t use in this context?
>
> #include < iostream >
> template < auto N >
> void f () {
> std::cout << N << std::endl ;
> }
> int main () {
> f < 1 >();
> f < '!' >();
> f < "!!" >(); // e
To whom it may concern
Why we can’t use in this context?
#include < iostream >
template < auto N >
void f () {
std::cout << N << std::endl ;
}
int main () {
f < 1 >();
f < '!' >();
f < "!!" >(); // error
return 0 ;
}
Alexander and his classmates
On Sat, 11 Nov 2023 at 02:06, Nima Hamidi via Gcc wrote:
>
> Another similar issue is with alias templates. The following code:
Please report both cases to Bugzilla, thanks.
>
> ```
> template
> struct Cls {
> using ptr = T *;
> };
>
> template
>
Another similar issue is with alias templates. The following code:
```
template
struct Cls {
using ptr = T *;
};
template
using Cls_ptr = typename Cls::ptr;
Cls_ptr ai;
Cls_ptr af;
```
produces
```
< 1><0x0029> DW_TAG_typedef
DW_AT_type <0x003d>
DW_AT_na
Hello all,
When I compile
```
template
struct Cls {
static const int v = 0;
};
template
int constexpr Cls_v = Cls::v;
int func() {
return Cls_v + Cls_v;
}
```
using `g++ -c main.cpp -o main.o -g`, I see two indistinguishable DIEs in the
generated debug info:
```
< 1><0x003a> DW_TAG_v
ecuted:100.00% of 10
File 'demo.cc'
Lines executed:88.89% of 18
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:100.00% of 4
Creating 'demo.cc.gcov'
Lines executed:88.89% of 18
So it reports lines and branches accurately for templates with a single
On 2017-05-12 15:59:44 -0500, Daniel Santos wrote:
> [...] But from a conceptual standpoint, I believe the term
> "constant-expression" would be incorrect because the C standard
> defines this constraint: (6.6.3 of C11) "Constant expressions shall
> not contain assignment, increment, decrement, fun
or C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being considered.
I don't expect C2X to go as far as to add something as complex
as templates but some on the committee are working on enhancing
support for generic programming (via _Ge
On Fri, 12 May 2017, Daniel Santos wrote:
> > Note that while "other forms" might be accepted in initializers, they
> > would still not be integer constant expressions (see DR#312).
>
> What is DR#312?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm
(but cf the older
http://www.open
Sorry for my delayed response.
On 05/11/2017 09:35 AM, Joseph Myers wrote:
On Thu, 11 May 2017, Jonathan Wakely wrote:
On 10 May 2017 at 23:14, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification
luding the syntax, especially the reuse
of the register keyword, are likely to evolve):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf
The C committee's charter for C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being cons
On Thu, 11 May 2017, Jonathan Wakely wrote:
> On 10 May 2017 at 23:14, Daniel Santos wrote:
> > Well my primary goal is programming with values that are constant in the
> > compiler. There is no language in any C specification (that I'm aware of)
> > for a "compile-time constant", but the concept
On Thu, May 11, 2017 at 11:12:24AM +0100, Jonathan Wakely wrote:
> On 10 May 2017 at 23:14, Daniel Santos wrote:
> > Well my primary goal is programming with values that are constant in the
> > compiler. There is no language in any C specification (that I'm aware of)
> > for a "compile-time consta
On 10 May 2017 at 23:14, Daniel Santos wrote:
> Well my primary goal is programming with values that are constant in the
> compiler. There is no language in any C specification (that I'm aware of)
> for a "compile-time constant", but the concept is very important. So just
> because some expressio
On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
I'm only speaking out of jealousy being that most of my recent work has
been in C.
hadn't gone so far as to investigate using this new attribute on
However, I
Because writing functions in normal C++ is much simpler and more
expressive than writing class templates and recursive partial
specializations.
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
> hadn't gone so far as to in
you don't use them.
Put simply, there are many projects who will not likely be converting to
C++ in the in our lifetimes. As far as abstractions, I meant the
abstraction penalty of static types which doesn't exist when using C++
templates (not at run-time anyway). In C, generic
Thanks for your feedback!
On 05/09/2017 04:36 AM, Florian Weimer wrote:
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition
of a c-family attribute to declare a parameter, variable (and
possibly other declarations) as "constprop" or
On Tuesday 09 May 2017, Daniel Santos wrote:
> The primary aim is to facilitate high-performance generic C
> libraries for software where C++ is not suitable, but the cost of
> run-time abstraction is unacceptable. A good example is the Linux
> kernel, where the source tree is littered with more th
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition of
a c-family attribute to declare a parameter, variable (and possibly
other declarations) as "constprop" or some similar word. The purpose of
the attribute is to:
1.) Emit a warn
rce) either
cloning or inlining of a function with such a parameter.
This will enable the use of pseudo-templates and:
1.) Eliminate the need for __attribute__((always_inline, flatten)) and
complicated ASSERT_CONST() macros,
2.) Eliminate the need for an __attribute__((flatten) wrapper function,
Hi,
the following program does not compile with g++4.9.2:
#include
template
auto tt(T x) -> decltype(~x) // <-- here
{ return ~x; }
int main()
{
std::cout << tt(10) << std::endl;
return EXIT_SUCCESS;
}
ptomulik@tea:$ g++ -std=c++11 -g -O0 -Wall -Wextra -Werror -pedantic -o
test-gcc test.
On 17 February 2015 at 15:10, Paweł Tomulik wrote:
> Is this a bug? The original program compiles with clang.
Yes, please report it as described at https://gcc.gnu.org/bugs/
In any case, "is this a bug?" questions are inappropriate on this
mailing list, they belong on the gcc-help list.
On 7 February 2015 at 00:05, Jonathan Wakely wrote:
> This question would have been more appropriate on the gcc-help mailing list.
I should have said it *was* more appropriate on that list, and should
have remained there. You could have pinged the gcc-help list, or just
been patient, before sendin
On 6 February 2015 at 12:12, Victor wrote:
>
>
>
> --- the forwarded message follows ---
>
>
> -- Forwarded message --
> From: Victor
> To: gcc-h...@gcc.gnu.org
> Cc:
> Date: Wed, 04 Feb 2015 15:41:56 +0600
> Subject: Vararg template
--- the forwarded message follows ---
--- Begin Message ---
Code:
#include
#include
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
int main()
{
f(std::tuple{});
}
GCC accepts this code silently. But
On Wed, Feb 13, 2013 at 5:18 PM, wrote:
>
> On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote:
>
>> ...
>> Ah, so if we rename a file with 'svn rename', its history will be
>> preserved across the rename? In that case, renaming files should not
>> be a problem.
>
> Yes, that's one of many ways th
On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote:
> ...
> Ah, so if we rename a file with 'svn rename', its history will be
> preserved across the rename? In that case, renaming files should not
> be a problem.
Yes, that's one of many ways that SVN (or most other source control systems)
are su
On Wed, Feb 13, 2013 at 5:00 PM, Joseph S. Myers
wrote:
> On Wed, 13 Feb 2013, Philip Martin wrote:
>
>> The new file must have been explicitly added, rather than copied or
>> moved, and so the history is broken. An example of a history preserving
>
> The issue there is that cvs2svn doesn't / didn
On Wed, 13 Feb 2013, Philip Martin wrote:
> The new file must have been explicitly added, rather than copied or
> moved, and so the history is broken. An example of a history preserving
The issue there is that cvs2svn doesn't / didn't at the time support
detecting moves, so moves from before the
On 13/02/13 17:11, Jonathan Wakely wrote:
On 13 February 2013 17:01, Alec Teal wrote:
On 13/02/13 17:00, Jonathan Wakely wrote:
I read it. That's not debate, just ill-informed speculation ("cpp is
the recommended extension for C++ as far as I know"). We already have
C++ code in GCC, the runt
On 13 February 2013 17:01, Alec Teal wrote:
>
> On 13/02/13 17:00, Jonathan Wakely wrote:
>>
>>
>> I read it. That's not debate, just ill-informed speculation ("cpp is
>> the recommended extension for C++ as far as I know"). We already have
>> C++ code in GCC, the runtime library uses .cc and the
On 02/13/2013 05:01 PM, Alec Teal wrote:
> Why not rename them to?
See the "archaeology" discussion. This is so vitally important
to GCC maintainers that you change things at everyone's peril.
Andrew.
Diego Novillo writes:
> One problem I've noticed is that renames seem to confuse svn diff.
> For example:
>
> $ cd gcc/cp
> $ svn log -r81829 cp-gimplify.c
>
> r81829 | dnovillo | 2004-05-13 22:29:32 -0400 (Thu, 13 May 2004)
On 13/02/13 17:00, Jonathan Wakely wrote:
On 13 February 2013 16:32, Alec Teal wrote:
On 13/02/13 16:11, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
A few questions, what is this stage 1? (link to documentation please, or
a
descriptive answer).
See http://gcc.gnu.org/
On 13 February 2013 16:32, Alec Teal wrote:
> On 13/02/13 16:11, Jonathan Wakely wrote:
>>
>> On 13 February 2013 15:33, Alec Teal wrote:
>>>
>>> A few questions, what is this stage 1? (link to documentation please, or
>>> a
>>> descriptive answer).
>>
>> See http://gcc.gnu.org/develop.html
>>
>>
On 13/02/13 16:11, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
A few questions, what is this stage 1? (link to documentation please, or a
descriptive answer).
See http://gcc.gnu.org/develop.html
for the choice of file extension, this is really a tiny thing, but I do ha
On 13/02/13 16:24, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
I'm also thinking of re-writing the C++ parser there are some interesting
todos (using lookahead rather than "try the next option") it's a topic I
enjoy and something I could (probably) do, especially given a w
On 13 February 2013 15:33, Alec Teal wrote:
> I'm also thinking of re-writing the C++ parser there are some interesting
> todos (using lookahead rather than "try the next option") it's a topic I
> enjoy and something I could (probably) do, especially given a working
> version already. thoughts and
On 13 February 2013 15:33, Alec Teal wrote:
>
> A few questions, what is this stage 1? (link to documentation please, or a
> descriptive answer).
See http://gcc.gnu.org/develop.html
> for the choice of file extension, this is really a tiny thing, but I do have
> a reason for .cpp
> http://stacko
On 02/13/2013 03:06 PM, Diego Novillo wrote:
> One problem I've noticed is that renames seem to confuse svn diff. For
> example:
>
> $ cd gcc/cp
> $ svn log -r81829 cp-gimplify.c
>
> r81829 | dnovillo | 2004-05-13 22:29:32
On 13/02/13 13:47, Diego Novillo wrote:
I feel silly now, why not use .cpp? SVN's move not good enough?
(or is it just because no one could be bothered?)
The latter. Perhaps we should start renaming the files. It will help
with this confusion and it will also be useful for tools like editors
On Wed, Feb 13, 2013 at 9:59 AM, Ian Lance Taylor wrote:
> I have no opinion on whether it is better to rename files now or later.
>
> I do think it is better to rename the files at some point.
>
> I would vote for renaming to an extension of ".cc".
Likewise.
One problem I've noticed is that re
On Wed, Feb 13, 2013 at 5:47 AM, Diego Novillo wrote:
> On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal wrote:
>> On 13/02/13 12:39, Richard Biener wrote:
>>>
>>> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
>>> It's just a filename ... we compile it with a C++ compiler.
>>>
>>> Richard.
>>
>> I
On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal wrote:
> On 13/02/13 12:39, Richard Biener wrote:
>>
>> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
>> It's just a filename ... we compile it with a C++ compiler.
>>
>> Richard.
>
> I feel silly now, why not use .cpp? SVN's move not good enough?
>
On 13/02/13 12:39, Richard Biener wrote:
On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
It's just a filename ... we compile it with a C++ compiler.
Richard.
I feel silly now, why not use .cpp? SVN's move not good enough?
(or is it just because no one could be bothered?)
Alec
I am sorry if
lename ... we compile it with a C++ compiler.
Richard.
> I am on a different computer now but it was vec< and occurred about 1/6th of
> the way in, it should be easy to find.
>
> Is that allowed? Is my main question. I would support a c with templates it'd
> save macro u
in, it should be easy to find.
Is that allowed? Is my main question. I would support a c with templates it'd
save macro usage, that could only be good! Or is there some construct of c I do
not know of.
Searching for c templates proved fruitless I got loads of c++ results
Alec
is for somebody to write one.
>
>
> Hello
>
> Is that statement above still true please ?
>
> I know export is now to be made deprecated by the next version of the C++
> standard
On a point of information: Support for exported templates has been
removed, not merely deprecated, in the current version of the C++
standard (C++11).
-- James
On 25.01.2010 20:12, Ian Lance Taylor wrote:
Timothy Madden writes:
[...]
g++ is free software. A clean implementation of export would
certainly be accepted. All it takes is for somebody to write one.
Hello
Is that statement above still true please ?
I know export is now to be made depr
Hey Manuel,
I would like to be able to change this behaviour so non-instantiated
code templates are considered as blocks (I think this is the term used
by GCC/GCov). This would help me greatly to uncover unused/untested
codes in a header/template-only library.
First of all: Is this feasible
Dear all,
I would like to instrument uninstantiated C++ function templates. When
compiling the program below with the -ftest-coverage and -fprofile-
arcs flags, I get according .gcno and .gcda files to run gcov and get
a coverage report.
In this report, the line marked with XXX will be
On 17 February 2011 17:26, Pascal Francq wrote:
> In fact, since it is related on how g++ is implementing its heritage mechanism
> in C++, I was thinking it was the right mailing-list. In fact, by adding a
> convenient method in Super2, the code compiles :
> template inline void Test(C* ptr)
In fact, since it is related on how g++ is implementing its heritage mechanism
in C++, I was thinking it was the right mailing-list. In fact, by adding a
convenient method in Super2, the code compiles :
template inline void Test(C* ptr) {Super::Test(ptr);}
This trick let me suppose that a
On 17 February 2011 11:03, Pascal Francq wrote:
>
> Is this a problem related to a misunderstood concept from me, a wrong
> implementation or a technical problem of g++ ?
In any of those cases, such questions are off-topic on this mailing
list, which is for development of gcc, not help using it.
Hi,
While compiling the following code, I got an error :
template class Super
{
public:
Super(void) {}
void Test(C*) {}
};
class A
{
public:
A(void) {}
};
class A1 : public A
{
public:
A1(void) : A() {}
};
class A2 : public A
{
public:
A2(void) : A() {}
Dodji Seketeli wrote:
> On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote:
>
>> So nobody here wants to try a big thing ? :(
>>
>
> This question strikes me as being not very fair because many GCC people
> are already pretty much involved. Would you fancy giving a hand?
>
>
> It depends on who owns the code that you write. If you own the code,
> then you need to sign papers as an individual contributor.
I don't think it's that simple. "who owns the code" is not always clear.
There's often a question of who that is. That's why if somebody HAS
an employer we usually
> I do not know the correct wording in English for this but I am legally
> licensed as an individual to offer software consulting services and to
> develop software.
>
> So the so-called employer is really my client, with whom I have signed
> a contract for consulting services.
If you have exactl
Timothy Madden writes:
> On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner
> wrote:
>>> I see that what I need is an assignment for all future changes. If my
>>> employer is not involved with any contributions of mine, the employer
>>> disclaimer is not needed, right ?
>>
>> It's safest to have it.
On Wed, Feb 3, 2010 at 4:19 AM, Richard Kenner
wrote:
>> I see that what I need is an assignment for all future changes. If my
>> employer is not involved with any contributions of mine, the employer
>> disclaimer is not needed, right ?
>
> It's safest to have it. The best way to prove that your
On 02/02/2010 05:04 AM, Michael Witten wrote:
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini
wrote:
it's extremely unlikely that the C++ front-end maintainers could
even consider reviewing patches from a novice for such an hard to
implement feature.
That says more about the tangled mess th
On 2/2/10 7:19 PM, Richard Kenner wrote:
I see that what I need is an assignment for all future changes. If my
employer is not involved with any contributions of mine, the employer
disclaimer is not needed, right ?
It's safest to have it. The best way to prove that your employer is
not in
> I see that what I need is an assignment for all future changes. If my
> employer is not involved with any contributions of mine, the employer
> disclaimer is not needed, right ?
It's safest to have it. The best way to prove that your employer is
not involved with any contributions of yours is w
On Mon, Feb 1, 2010 at 2:38 AM, Paolo Carlini wrote:
> On 02/01/2010 01:26 AM, Timothy Madden wrote:
[...]
> As I see the issue, you should first check over the next months that the
> feature is not deprecated by ISO.
I know, I tried to talk about it on std.c++. I am afraid I can not see
a consens
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini wrote:
> it's extremely
> unlikely that the C++ front-end maintainers could even consider
> reviewing patches from a novice for such an hard to implement feature.
That says more about the tangled mess that is gcc then about any
particular programmer'
Timothy Madden writes:
> On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini
> wrote:
> [...]
>> Even for implementors knowing *very* well both the details of the C++
>> standard and the internals of a specific front-end, implementing export
>> is an *highly* non-trivial task. [...]
>
> Yes, everyon
On 02/01/2010 01:26 AM, Timothy Madden wrote:
> Since such a change must happen in small steps, I would be interested
> to know how 'acceptable' would a limited implementation be at first ?
> Like the command line options I have seen declared 'experimental' in
> the gcc manual before ...
>
As I
On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini wrote:
[...]
> Even for implementors knowing *very* well both the details of the C++
> standard and the internals of a specific front-end, implementing export
> is an *highly* non-trivial task. [...]
Yes, everyone is telling me that, but could someon
On Sat, Jan 30, 2010 at 4:23 AM, Michael Witten
[...]
> However, I have a gut feeling that at least a restricted version of
> 'export' (or a cousin of 'export') could be both useful and trivial to
> implement: [...]
>
Those were my thoughts too.
Since such a change must happen in small steps, I w
On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote:
> So nobody here wants to try a big thing ? :(
This question strikes me as being not very fair because many GCC people
are already pretty much involved. Would you fancy giving a hand?
> How long would it take for someone to understa
Paolo Carlini writes:
> Anyway, modulo a possible deprecation (I believe M$ through Herb is
> still pushing for it) I think the slightly more serious side of this
> export thing is something Mark, if I'm not mistaken, said some time
> ago, at the very beginning of the Lto ideas, to the effect th
Hi
I already tried to tell him that upthread.
Sorry about that, last night was tired and didn't follow the whole
thread.
Anyway, modulo a possible deprecation (I believe M$ through Herb is
still pushing for it) I think the slightly more serious side of this
export thing is something Ma
, or experience frequent
corruption or the like; I've had such problems making such systems work
that we've generally resorted to turning it off (e.g. tell Sun's compiler
to expand templates into static functions).
These problems might be overcome, but it hasn't been done
Paolo Carlini writes:
> On 01/30/2010 01:14 AM, Ian Lance Taylor wrote:
>> I don't think you need to understand the build system to implement
>> export in C++. You do clearly need to understand the g++ frontend.
>> However, it's impossible for me to estimate how long it would take
>> somebody to
On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini wrote:
> Even for implementors knowing *very* well both the details of the C++
> standard and the internals of a specific front-end, implementing export
> is an *highly* non-trivial task.
However, I have a gut feeling that at least a restricted versi
On 01/30/2010 01:14 AM, Ian Lance Taylor wrote:
> I don't think you need to understand the build system to implement
> export in C++. You do clearly need to understand the g++ frontend.
> However, it's impossible for me to estimate how long it would take
> somebody to understand it. It would depe
Timothy Madden writes:
> How long would it take for someone to understand how parsing works in
> g++ ? Or to understand the build system in gcc ?
I don't think you need to understand the build system to implement
export in C++. You do clearly need to understand the g++ frontend.
However, it's i
On Mon, Jan 25, 2010 at 8:12 PM, Ian Lance Taylor wrote:
> Timothy Madden writes:
>
>> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote:
>>> Timothy Madden writes:
>>>
Why is it so hard to store template definitions (and the set of
symbols visible to them) in an
object fil
Timothy Madden writes:
> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote:
>> Timothy Madden writes:
>>
>>> Why is it so hard to store template definitions (and the set of
>>> symbols visible to them) in an
>>> object file, probably as a representation of the parsed template source
>>>
On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote:
> Timothy Madden writes:
>
>> Is there any progress or start yet in implemententing export for C++
>> templates ?
>
> Not to my knowledge.
>
> The C++0x standards committee considered deprecating export for
Timothy Madden writes:
> Is there any progress or start yet in implemententing export for C++
> templates ?
Not to my knowledge.
The C++0x standards committee considered deprecating export for C++0x,
but I think they have decided to retain it for now.
> Why is everybody such not i
Hello
Is there any progress or start yet in implemententing export for C++ templates ?
A search in the mailing list archive shows the last time the issue was
discussed was in 2006.
Why is everybody such not interested in this ? It would be such a
great feature, especially for
a leading C
On 11/19/09 18:28, Larry Evans wrote:
On 11/19/09 17:23, Jason Merrill wrote:
On 11/17/2009 09:36 AM, Larry Evans wrote:
Could g++ provide this feature? How hard would it be to implement.
It probably wouldn't be difficult to implement, but I'd want someone
to champion the extension with the
pedef v...@n type; // or implementation_defined::type -
> guaranteed linear
> };
> template get_type::type get(V...v) {
> return ::implementation_defined(v...);
> }
This is probably the most-requested feature for variadic templates,
and it never it made it because we never found a good, u
On 11/17/2009 09:36 AM, Larry Evans wrote:
Could g++ provide this feature? How hard would it be to implement.
It probably wouldn't be difficult to implement, but I'd want someone to
champion the extension with the C++ committee as well. Have you asked
Doug Gregor what he thinks? I assume th
As mentioned in a post of comp.std.c++:
http://preview.tinyurl.com/yaqvnnq
there's a need for some way to get the nth element of a pack
expansion. For example, boost::mpl::arg:
http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/arg.html
wouldn't need the preprocessor for its impl
2009/3/10 Sylvain Pion:
> Manuel López-Ibáñez wrote:
>> 2009/3/10 Sylvain Pion:
>>>
>>> Yes, but like any extension, it's nice to be able to disable them
>>> as errors, so as to be able to use GCC for checking code portability.
>>
>> So use -pedantic-errors as it says in the manual. You should real
-pedantic-errors will make it an error.
I don't feel strongly about whether these should be pedwarn or something
stronger, but I note that libstdc++ wants to use variadic templates in
the default mode, so we can't just disable them entirely.
Jason
On Tue, Mar 10, 2009 at 7:57 AM, Manuel López-Ibáñez
wrote:
> 2009/3/10 Sylvain Pion :
>>>
>>> But then probably, variadic templates are implemented as a GCC
>>> extension to C++98 and they work fine with -std=c++98 despite what the
>>> warning says.
Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 6:58 AM, Sylvain Pion
wrote:
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
But then probably, variadic templates are implemented as a GCC
extension to C++98 and they work fine with -std=c++98 despite what the
warning says. Or don't they?
Yes, but like any extension, it's nice to be able to disable them
as
2009/3/10 Sylvain Pion :
>>
>> But then probably, variadic templates are implemented as a GCC
>> extension to C++98 and they work fine with -std=c++98 despite what the
>> warning says. Or don't they?
>
> Yes, but like any extension, it's nice to be able
On Tue, Mar 10, 2009 at 6:58 AM, Sylvain Pion
wrote:
> Manuel López-Ibáñez wrote:
>>
>> 2009/3/10 Sylvain Pion :
>>>
>>> The problem I fear is that variadic templates are already conveniently
>>> used as an implementation detail in libstdc++. And the w
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by the "system header" warning removal machinery.
But then probably
2009/3/10 Sylvain Pion :
>
> The problem I fear is that variadic templates are already conveniently
> used as an implementation detail in libstdc++. And the warning there
> is probably hidden by the "system header" warning removal machinery.
>
But then probabl
Sylvain Pion wrote:
> The problem I fear is that variadic templates are already conveniently
> used as an implementation detail in libstdc++. And the warning there
> is probably hidden by the "system header" warning removal machinery.
It is, you are right.
Paolo.
Jan van Dijk wrote:
Consider the one-liner C++ 'program':
template struct pack;
With the trunk, g++ -c [-std=gnu++98] gives:
warning: variadic templates only available with -std=c++0x or -std=gnu++0x
Should this not be an *error* instead? Variadic templates really should not be
Manuel López-Ibáñez wrote:
> In any case the wording of the warning is weird: it says variadic
> templates are not available but then it is accepted with just a
> warning.
>
I agree.
>> to variadic templates. It also happens, for example, for:
>>
>> enum class e {
2009/3/10 Paolo Carlini :
>>
>> warning: variadic templates only available with -std=c++0x or -std=gnu++0x
>>
> I'm afraid the behavior you are seeing is by design, and is not specific
In any case the wording of the warning is weird: it says variadic
templates are no
1 - 100 of 193 matches
Mail list logo
