Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of template members #179

Closed
vitaut opened this issue Mar 14, 2015 · 4 comments · Fixed by #191
Closed

Handling of template members #179

vitaut opened this issue Mar 14, 2015 · 4 comments · Fixed by #191
Assignees

Comments

@vitaut
Copy link
Contributor

vitaut commented Mar 14, 2015

Currently there is an inconsistency in handling class and non-class members of class templates. Consider the following example:

/** A class */
template <typename T>
class C {
 public:
  /** An inner class. */
  class D {};

  /** A method. */
  void f();
};

Inner class is passed as class C::D to the domain directive while function is passed as void C<T>::f(). Note that C has template arguments in the case of member function, but not in the case of the class.

While it doesn't change rendering, it affects how the domain targets are generated and, in particular, it means that in some cases cross references are not generated as in the following example:


/** A class */
template <typename T>
class C {
 public:
  /** An inner class. */
  class D {};

  /** A method. */
  void f(D);  // reference to D will not be generated
};

Therefore, we should either strip template arguments in the case of functions (making void C::f() in the above example) or add them in the case of classes (making class C<T>::D). I tend to prefer the first option because technically a template argument is just placeholder and not part of a signature until you instantiate a template.

@michaeljones do you have any ideas or comments about this?

@michaeljones
Copy link
Collaborator

Great catch! I don't have any strong ideas on this one. I guess the template parameters are unnecessary from an identification stand point. You can't have two difference classes with the same name and different template parameters to tell them apart so dropping it seems to be a simplifying step with any downsides. I agree with you!

@vitaut
Copy link
Contributor Author

vitaut commented Mar 14, 2015

OK, I'll try implementing removal of template parameters then.

@vitaut vitaut self-assigned this May 24, 2015
vitaut added a commit that referenced this issue May 26, 2015
Otherwise links to nested classes (in parameter or return types) defined
in the same template are not generated correctly, because the latter
don't include template arguments. Fixes #179.
vitaut added a commit that referenced this issue May 27, 2015
Otherwise links to nested classes (in parameter or return types) defined
in the same template are not generated correctly, because the latter
don't include template arguments. Fixes #179.
@vitaut
Copy link
Contributor Author

vitaut commented May 29, 2015

Reopening as the same should be done for data members as well.

@vitaut
Copy link
Contributor Author

vitaut commented Jun 2, 2015

Fixed in c9d73f6 for all members.

@vitaut vitaut closed this as completed Jun 2, 2015
vermeeren pushed a commit that referenced this issue Jun 4, 2018
Otherwise links to nested classes (in parameter or return types) defined
in the same template are not generated correctly, because the latter
don't include template arguments. Fixes #179.
vermeeren pushed a commit that referenced this issue Jun 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants