From: Wilson R. T <rob...@br...> - 2006-10-23 13:34:02
|
Hi all, Thanks for your replies. Unfortunately it is not really feasible to move the code into a .Net class, due to reasons that Oliver mentioned about how memory is dealt with in managed classes. Unless anyone else has any other ideas then presumably that means that I can't use XML documentation in my code. If so, that's a great shame, as it would make things vastly easier for me, but I'm sure I can manage to do it another way. Thanks for all your help, Robin _____ From: Olivier DALET [mailto:od...@gm...] Sent: 23 October 2006 08:03 To: Wim Coenen Cc: Wilson Robin T; ndo...@li... Subject: Re: [Ndoc-users] Documenting functions which are *not* in a class I agree with Wim: In .NET, functions don't exist and a method can't be defined outside of a class (or a structure). C++ allows this kind of construction. Thus your functions "which are not in a class" are regular C++ functions and they can't, by definition, be expressed by any .NET language. Indeed, these functions are compiled to native code and mixed with .NET code in the resulting assembly. It can be a solution to wrap these functions into a .NET class, but only if you don't rely on some native code behavior. If you do so, pay attention to the way you manage memory (native unmanaged pointers and .NET references (managed by the GC) are not quite the same), be careful with strings too. I'm not a managed C++ expert, but this may prove not to be a trivial task. PS: I don't know if you're using the .NET 1 or .NET 2 flavor of Managed C++, but be aware of the fact that even if the latter recognizes the older syntax, there are differences. And so, you may pay attention to this if grabbing samples on the net. Best regards, Olivier DALET On 10/22/06, Wim Coenen <wc...@gm... <mailto:wc...@gm...> > wrote: Your assembly does not contain metadata for those functions because it is a "mixed assembly" with both dotnet IL instructions and native instructions, something which only occurs when compiling "c++ with managed extensions" as far as I can tell. The native part has no dotnet metadata, and is thus invisible to other dotnet assemblies, like the reflector or ndoc application. I would try to move or wrap one of those global function in a static method of a __gc class called "GlobalFuncs", and document it there. Since the "GlobalFuncs" class is managed, it should be visible to ndoc. 2006/10/19, Wilson Robin T <rob...@br... <mailto:rob...@br...> >: > Hi, > > Thanks for your response - sorry for the delay in replying, I've been out of > the office for quite a while. > > I've had a look with the .Net Reflector, and I can't find my standalone > functions in there at all! I'm not sure how my program is working then...I > am using Visual C++ .Net and have some old-style C++ global functions which > don't seem to be appearing in the reflector, but the code is accessing them > fine! How weird! > > Dose anyone know if there's any way I can get them to appear in the > reflector? Or, if there's any way that I can get them to be documented using > NDoc? > > Cheers, > > Robin > > -----Original Message----- > From: Wim Coenen [mailto: wc...@gm... <mailto:wc...@gm...> ] > Sent: 09 October 2006 16:26 > To: Wilson Robin T > Cc: ndo...@li... <mailto:ndo...@li...> > Subject: Re: [Ndoc-users] Documenting functions which are *not* in a class > > 2006/10/6, Wilson Robin T > <rob...@br... <mailto:rob...@br...> >: > > I have lots of functions which are just in separate .cpp files with no > > membership of a class (or even a namespace - though I wouldn't mind > > making them members of a namespace if that would help). Is there any > > way to document these functions using NDoc? If I look at the XML that > > Visual Studio spits out then it does list those functions which aren't > > in a class - NDoc just doesn't seem to do anything with it. > > > > I don't use visual studio or write code in c++, so I obviously cannot > reproduce this problem. However, I do know that dotNET assemblies never > contain standalone functions. Dotnet compilers for languages which do have > this feature (e.g. delphi) have to put such functions in a special class. > > Now if NDOC encounters a member element which for some reason does not match > the CLR metadata of anything in the compiled assembly, then it will ignore > the element. To find out if this is your problem, take a look at your > assembly (e.g. with Lutz Roeder's .NET Reflector), find out in which > namespace+class your function ended up, and then compare that with the XML > element. > > That should shed some more light on the cause of your problem. > > HTH, > Wim Coenen. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> &kid=120709&bid=263057&dat=121642 _______________________________________________ Ndoc-users mailing list Ndo...@li... <mailto:Ndo...@li...> https://lists.sourceforge.net/lists/listinfo/ndoc-users <https://lists.sourceforge.net/lists/listinfo/ndoc-users> -- Olivier DALET --------------------------------- http://odalet.wordpress.com <http://odalet.wordpress.com> http://aspadvice.com/blogs/oliviers_net_blog <http://aspadvice.com/blogs/oliviers_net_blog> |* This e-mail, and any attachments, is confidential and for the use of the addressee only. |* If you are not the intended recipient, please telephone +44 (0) 1506 408700 |* We do not accept legal responsibility for this e-mail or any viruses. |* All e-mails sent and received by us are monitored. |* Contracts cannot be concluded with us by e-mail. |* This message has been sent from a member of the British Energy Group (the "Group"). |* The parent company of the Group is British Energy Group plc, registered number 270184, and having its registered office at |* Systems House, Alba Campus, Livingston EH54 7EG |