- PPL-devel - BUGSENG Mailman

ppl/src Matrix.inlines.hh
by Enea Zaffanella 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: zaffanella(a)cs.unipr.it 2002-03-11 14:53:57 Modified files: src : Matrix.inlines.hh Log message: Fixed a \relates doxygen comment pointing to the wrong class. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Matrix.inlines.hh.diff?cv…

1 0

ppl/src Variable.defs.hh
by Enea Zaffanella 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: zaffanella(a)cs.unipr.it 2002-03-11 14:52:11 Modified files: src : Variable.defs.hh Log message: Removed a redundant namespace qualification. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Variable.defs.hh.diff?cvs…

1 0

ppl/doc devref-browse.doxyconf-latex.in devref ...
by Enea Zaffanella 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: zaffanella(a)cs.unipr.it 2002-03-11 14:49:12 Modified files: doc : devref-browse.doxyconf-latex.in devref-print.doxyconf-latex.in devref.doxyconf-html.in Log message: Set the WARN_IF_UNDOCUMENTED flag to YES. This will have no effect until we will set EXTRACT_ALL to NO. Added the *.types.hh files to the INPUT variable. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/devref-browse.doxyconf-la… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/devref-print.doxyconf-lat… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/devref.doxyconf-html.in.d…

1 0

ppl/interfaces/Prolog Prolog_interface.dox
by Patricia Hill 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: hill(a)cs.unipr.it 2002-03-11 14:23:35 Modified files: interfaces/Prolog: Prolog_interface.dox Log message: Documentation describing the PPL Prolog predicates revised. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/Prolog_inte…

1 0

ppl/interfaces/Prolog Prolog_interface.dox
by Patricia Hill 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: hill(a)cs.unipr.it 2002-03-11 12:22:46 Modified files: interfaces/Prolog: Prolog_interface.dox Log message: Documentation for ppl_copy_polyhedron corrected. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/Prolog_inte…

1 0

ppl/interfaces/Prolog clpq.pl clpq2.pl
by Roberto Bagnara 11 Mar '02

11 Mar '02

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2002-03-11 12:06:47 Modified files: interfaces/Prolog: clpq.pl clpq2.pl Log message: Now consulting 'file' will try also 'file.pl' in case 'file' does not exist or is not readable. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/clpq.pl.dif… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/clpq2.pl.di…

1 0

Friend and related functions discard the static and inline qualifiers.
by Enea Zaffanella 11 Mar '02

11 Mar '02

Hi all. I am not sure if the following is a bug or I am simply overlooking some of the basics of doxygen ... It seems to me that friend functions (or functions that are related to a class by using the command \relates) lose their "inline" and "static" attributes when they are reported in the "Friends And Related Function Documentation" section of the _class_ (note that the attributes of the friend function are correctly reported in the "Function Documentation" section of the _namespace_). Apparently, the "friend" (or "related") attribute is overriding the other attributes, while in my opinion it should just be added to the list of attributes. I am using doxygen 1.2.14 and a standard configuration file where I set EXTRACT_PRIVATE = YES EXTRACT_STATIC = YES SOURCE_BROWSER = YES INLINE_SOURCES = YES Regards, Enea Zaffanella. //! This is a namespace. namespace MyNamespace { //! This is an inlined friend function. inline static void foo_friend(); //! This is an inlined related function. /*! \relates A */ inline static void foo_related(); } namespace MyNamespace { //! This is A class. class A { inline static void foo(); friend inline static void foo_friend(); }; } namespace MyNamespace { /*! Detailed description for the static member. */ inline static void A::foo() { // Bla bla. } /*! Detailed description for the friend. */ inline static void foo_friend() { // Bla bla. } /*! \relates A Detailed description for the related. */ inline void foo_related() { // Bla bla. } }

1 0

ppl/src Constraint.cc Constraint.defs.hh Gener ...
by Enea Zaffanella 11 Mar '02

11 Mar '02

1 0

Namespaces can cause function declaration/definition mismatches.
by Enea Zaffanella 11 Mar '02

11 Mar '02

Hi all. The attached sample code shows a problem whereby functions definitions and declarations are not matched properly when using namespaces. In particular, it seems that the matching depends on _how_ my classes and functions are inserted into a particular namespace. I found the following message in the archives, which seems to report a very similar problem ... > From: Carlos.Guerreiro(a)nokia.com > To: doxygen-users(a)lists.sourceforge.net > Date: Mon, 7 Jan 2002 16:29:10 +0200 > Subject: [Doxygen-users] Problem with namespaces and templates > > Hi, > > I think I found a problem in Doxygen related to the matching between a > functions's declaration and it's definition, when namespaces and > templates are used: //! This is a namespace. namespace MyNamespace { //! This is a friend function (will be matched). void foo1_friend(); //! This is another friend function (won't be matched). void foo2_friend(); } namespace MyNamespace { //! This is A class. class A { friend void foo1_friend(); }; } //! This is Another class, inserted in the namespace //! by using an alternative, legal syntax. class MyNamespace::Another { // Here the function foo2_friend() _has_ to be qualified // with the namespace. friend void MyNamespace::foo2_friend(); };

1 0

A bug when using <CODE>.
by Enea Zaffanella 11 Mar '02

11 Mar '02

Hi all. The following small program shows a bug related to the use of the <CODE> and </CODE> tags. The error is visible when the code tags enclose both the template instantiation "<...>" and the scope "::" syntactic operators of C++. I am using version 1.2.14 and a default configuration file. Apologies if this bug has already been reported ... Regards, Enea Zaffanella /*! \file bug.cc */ //! This comment <CODE>vector<int></CODE> //! does not cause problems. void foo(int x) {} //! Neither this one <CODE>std::swap()</CODE> //! causes problems. void foo2(int x) {} //! But when writing this one, combining the two syntactic //! features above, <CODE>vector<int>::iterator</CODE> //! the \tt LaTeX environment is not closed. void foo3(int x) {}

1 0