From: CornedBee on
On Aug 2, 11:50 am, Edward Rosten <edward.ros...(a)gmail.com> wrote:
> I assume by this that you are referring to the need to
> scatter .template within templated code? I presume then that DMC++
> doesn't need them (much like GCC 3.x series of compilers), and 4.x
> with appropriate compiler flags?

Template and typename, yes. Clang needs them.

Sebastian


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: CornedBee on
On Aug 1, 4:53 pm, Seima Rao <seima...(a)gmail.com> wrote:
> The IR(AST as is cited by you) has extra node types just for
> templates,
> if I understand you correctly?

Yes. In Clang's AST, we have various declaration nodes for templates,
we have the dependent type, we have dependent-sized array types, and
we have various pseudo-types for templates and parameters. All in all,
I'd say there's about a dozen AST node types specific to templates
(out of about 200).

> You assumed incorrectly. What I am interested in is the two
> scenarios that a compiler has to contend with:
>
> 1) template declaration
> 2) template instantiation
>
> Your reply seems to suggest that compilers piggyback on
> preprocessing technology(aka macro substitution) to
> get template instantations to work admittedly
> in a transparent fashion to the rest of the toolchain.

No, Clang does tree substitution on its ASTs. It has nothing to do
with the preprocessor. Token-caching implementations like VC++ and DMC+
+ use mechanics that are similar to the preprocessor, but I doubt
there's any code sharing going on.

> Any one with suggestions for compiling templates
> only during declaration and skipping name lookup
> and other sundries during instantiation?
> [C++ makes it impossible, but still...]

I have no clue what you want to know.

Sebastian


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nikolay Ivchenkov on
On 5 Aug, 06:15, Walter Bright <newshou...(a)digitalmars.com> wrote:
> Nikolay Ivchenkov wrote:
> > On 4 Aug, 08:30, Walter Bright <newshou...(a)digitalmars.com> wrote:
> >> My reading of C++98 was that the compiler was not required to issue a diagnostic
> >> for a malformed definition if it was never instantiated.
>
> > What's the malformed definition?
>
> One that doesn't follow the grammar.
>
> > (I want to see normative criteria if
> > they exist). For example, can we consider the following sequence of
> > tokens
>
> > %+*!^~
>
> > as a malformed template definition (according to your interpretation)?
>
> Yes.

If any ill-formed according to syntactic rules sequence of tokens
might be interpreted as an ill-formed template definition for which no
diagnostic is required, then syntactic rules would be non-diagnosable
at all. Actually the set of diagnosable rules includes syntactic rules
- see C++03 - 1.4:

[quote]
The set of diagnosable rules consists of all syntactic and semantic
rules in this International Standard except for those rules containing
an explicit notation that "no diagnostic is required" or which are
described as resulting in "undefined behavior."

Although this International Standard states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:
- If a program contains no violations of the rules in this
International Standard, a conforming implementation shall, within its
resource limits, accept and correctly execute that program.
- If a program contains a violation of any diagnosable rule, a
conforming implementation shall issue at least one diagnostic message,
except that
- If a program contains a violation of a rule for which no diagnostic
is required, this International Standard places no requirement on
implementations with respect to that program.
[/quote]

A compiler is allowed to consider a sequence of tokens as an ill-
formed template definition for which no diagnostic is required only if
it can prove that the sequence of tokens is really a template
definition. The only way to do this is to check whether the sequence
of tokens matches the syntax of possible template definitions.

On 5 Aug, 13:13, CornedBee <wasti.r...(a)gmx.net> wrote:
>
> [temp.res]p8 gives an explicit example of completely nonsensical code
> (not even syntactically correct), with the note that it *may* be
> diagnosed even if the template is never instantiated. In other words,
> as long as a template is not instantiated, you can have whatever you
> want in there, as long as the parser is still able to find the end of
> the template.

Lets consider the following ill-formed program:

template <class T>
void f()
{
(
} // is this the end of the template definition?
)
} // is this the end of the template definition?

int main()
{
} // is this the end of the template definition?

There are two mutually exclusive options:
* no diagnostic is required for this program;
* a diagnostic message shall be issued.

There shall be standard criteria for determining which option is
right. Can you show these criteria?

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
CornedBee wrote:
> On Aug 4, 7:15 pm, Walter Bright <newshou...(a)digitalmars.com> wrote:
>> Felipe Magno de Almeida wrote:
>>
>>> On Aug 4, 1:30 am, Walter Bright <newshou...(a)digitalmars.com> wrote:
>>>> My reading of C++98 was that the compiler was not required to issue a
diagnostic
>>>> for a malformed definition if it was never instantiated.
>>> Unless I'm missing something, I think it is required to diagnose.
>> At this point, I'll require a specific quote from C++98 <g>.
>
> [temp.res]p8 gives an explicit example of completely nonsensical code
> (not even syntactically correct), with the note that it *may* be
> diagnosed even if the template is never instantiated. In other words,
> as long as a template is not instantiated, you can have whatever you
> want in there, as long as the parser is still able to find the end of
> the template.

Right, so it's not required.


> Getting diagnostics early is simply a QoI issue.
> Clang aims at diagnosing things as early as possible and as thoroughly
> as possible (there are many things in the area that are ill-formed, no
> diagnostic required; we want to diagnose them), so blindly caching
> tokens is simply not an option. We would have to cache them and parse
> them at definition time, and then parse them again at instantiation
> time. (For every instantiation, of course.) Now *that* is a waste of
> effort.

It's a worthy goal to try and do that.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Felipe Magno de Almeida on
On Aug 5, 7:18 am, CornedBee <wasti.r...(a)gmx.net> wrote:
> On Aug 1, 10:51 pm, Walter Bright <newshou...(a)digitalmars.com> wrote:
>
> > CornedBee wrote:
> >> I am pretty sure, from observing its behaviour, that MSVC caches the
> >> token stream instead of building an AST, but that's not a good
> >> approach: there are various bugs that can be traced to this
> >> implementation choice.
>
> > Please give an example.

[snipped example]

> This is what surprises me about your statement that token-caching is
> easier than tree substitution. I would have thought that really
> getting name lookup (in particular two-phase name lookup) right for
> token caching is devilishly hard. You either have to attach the lookup
> result to the cached identifier tokens (but you can't do that, because
> you need a proper parse to determine if you're even supposed to look
> up a name), or you need to be able to recreate the exact lookup
> context at the template definition point.

That's what I was thinking. How can you make two-phase lookup in just
one phase?
Specially since the lookup must be done in the template's defintion as
well, not just
its signature, AFAIU.
You can't pick context that comes after the template definition.
Though I see I was wrong about the diagnose part.

> I don't know about DMC++,
> but in Clang that would be a major challenge.
> If you have a better idea, I'd be interested in hearing about it.

So am I.

> --

Regards,
--
Felipe Magno de Almeida


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: basic concatenation question
Next: type casting issue