Does Mendix generates a source code in any particular language, which can be edited and reused?
I have never used Mendix
Mendix does not generate source code, apart from the boilerplate source code for custom Java actions. The model you create is interpreted at runtime.
Full disclosure: I am a Mendix employee but what I post here is personal, not an official statement.
Related
In unreal engine, what is the difference between the two?
I could not find it in the API, just this: https://docs.unrealengine.com/5.0/en-US/gameplay-classes-in-unreal-engine/
I suspect that it adds .generated if you create the class from the Unreal editor, but I do not understand if it is any different with or without it.
Ah, so the .generated header is required inside the actual header file of the class (specifically as the last header).
https://forums.unrealengine.com/t/creating-classes-in-visual-studio/282386/4
Unreal has a code generation tool called "Unreal Header Tool" or UHT for short. During the build process of the project, it runs right before the actual compiler to generate code for the reflection, based on the UPROPERTY(), UFUNCTION(), etc. calls that you have in your code.
All that information is stored in two files: <Class>.generated.h and <Class>.generated.cpp
The header needs to be included last in the header to ensure that all references in a file are potentially valid in the generated code. Everything within the generated header file can be accessed via the UClass reflection system.
You can find the generated files in the "Intermediate/Build" directory of your project.
You can find the implementation of the UHT in the project on GitHub and a little more info about it in the docs.
I need a tool that I can use to get a better understanding of a large C
project. I'd like to be able to see the relationship between the various C
modules and what calls what, most used functions, what headers are used, etc.
I've searched here and Google but all the source code analysis tools seem to give
you the number of lines of code and other metrics that I'm not interested in. I just
want to get a high level view of how things are structured and interconnected before jumping into the code.
Does anything like this exist?
I've looked at these but they do not seem to do what I want: Source Code Tools
Since posting this I've tried Doxygen and it seems to give me some of what I need. Any others?
Try GNU cflow, that will analyze the call tree of the functions - you will nicely see the call hierarchy of the functions. Or browse the code with Eclipse.
Source Navigator may be helpful for some things (I used it to see call trees). See screenshots.
cxref builds annotated source code cross reference that's easy to view and navigate (I used to create HTML reference of some of my code). See cxref's output on its own source code here. Can be used to document the code.
It is not OSS, but the tool CppDepend can certainly help when it comes to understand a large legacy application written in C or C++.
I am trying to use the <code> tag inside the <example> tag to show a sample code in xml documentation. However, when I build the Sandcastle project, I see that it is shown as C#. There is no language attribute in <code> tag. And I could not find a setting in Sandcastle's project properties. Am I missing something?
BTW, I am using HtmlHelp1 format.
Actually, if you move beyond Sandcastle to Sandcastle Help File Builder (SHFB),
you will get both an easier to use interface to Sandcastle and additional features for your documentation set, including just what you want: a language attribute (language) for the <code> element.
Note that SHFB generates a language selector menu but that only lets you
show or hide a particular set of languages (C#, VB.NET, C++, J#, JScript.NET, XAML, and JavaScript). It supports colorizing, though, of a larger set (C#, VB.NET, JScript.NET, C++, J#, C, JavaScript, VBScript, XAML, XML, HTML, SQL script, PowerShell script, and Python). (From the Code Block Component section of the SHFB documentation.)
I have written extensively on this point, as well as many other tips and pitfalls of Sandcastle and SHFB, in my article Taming Sandcastle: A .NET Programmer's Guide to Documenting Your Code published on Simple-Talk.com. Besides the main article, I also put together a wallchart/quick reference that gives you everything you need to know to use Sandcastle/SHFB on one page--the link also appears at the end of the article.
You can find more details about the <code> element in the Displaying Sample Code section of my article, as well as from the official SHFB documentation at Importing and Colorizing Code from Source Files.
i have created my own graphical editor using GMF.
i want to generate code based on the diagram created by editor? any pointers how to proceed
This might help you:
http://www.vogella.de/articles/EclipseBuilder/article.html
That page doesn't have the actual code example but the points to the necessary concepts: Builders. For example, the java compiler is hooked in through a builder that's registered for the .java type.
We've got a large codebase of Java (with a smattering of Groovy mixed in) that, by and large, has no javadocs written for it.
However, much of the code is reasonably well documented in "old-school" comments scattered throughout the body.
We're now on something of a push to try and get things documented a little better - Javadocs are now being generated on a regular basis, for example. As a stopgap measure, it would be really nice if javadoc would "scrape" the body of the class (or function, or whatever) and toss all the comments within into a "stub" javadoc.
Is there a way to do that?
Sounds like a bad idea, given that javadocs typically describe purpose and usage of elements, and code body comments are (or should be) about the details of implementation.
But if you must, you clearly need to write your own custom doclet that works in concert with a java source file parser (either 3rd party or your own). For each processed class, you would first run the parser on the source file for that given java class and harvest the internal comments, and then augment the (standard) html produced by the (standard) doclet to add the code comments.
A possible strategy that would help make the resultant javadocs sensible would be to include a given method's internal comments for the javadoc for that method. Just use a 'pre' closure and append the parsed comments of the method at the end of the generic javadoc html.