If I have the following:
/**
* #brief (x,y,z) points for block
*/
int x, y, z;
It will only generate that documentation for x, is it possible in doxygen to get it to comment all x, y and z with one comment?
EDIT
Following the suggestions of envu I now have the following (based off http://www.doxygen.nl/manual/grouping.html#memgroup)
//#{
/** some documentation here */
int x, y, z;
//#}
or
//#{
/**
* #brief some documentation here
*/
int x, y, z;
//#}
However both of these still only document x.
Trying it with different forms I have yet to get the same documentation string to span multiple variables
Been banging my head on this one for a while. Turns out you have to set DISTRIBUTE_GROUP_DOC = YES in the configuration.
I would use member groups http://www.doxygen.nl/manual/grouping.html#memgroup for this. The syntax and output is a little bit different to what you want to achieve, but I think that shouldn't hurt.
I realize this is an old question, but I've been having a similar problem and found a workaround that doesn't exactly solve the problem but might be an acceptable substitute in certain cases.
By putting a comment above the member group block and prefixing it with the \name decorator, you get a description that shows up above all of the variables in the member group in the attributes list of the Doxygen page. I believe this is intended to be a short description, but you can put arbitrarily long descriptions here if you wish.
This doesn't have the effect of putting the same comments in the detail field for each of the variables in the member group (the detail fields will be empty, or if you put a comment inside the member group block it will still only apply to the first variable), but it does have the effect of documenting a related group of variables together, which seems like what the original intent of the question was.
Example:
/*! \name This will be the description for the following group of variables
It can be arbitrarily long, but the first line will show up in bold,
and any subsequent lines will show up like a description under it
*/
//#{
int relatedVariable1;
int relatedVariable2;
char* relatedVariable3;
//#}
I've set the option "DISTRIBUTE_GROUP_DOC" in the "Expert" tab. Then all the members of the group received the same comment.
//#{
/** same comment for all members */
char aaa;
char bbb;
int ccc;
//#}
Related
Hello and thank you for reading.
I want to ask whether it is possible to add your own header in description of a method. I can not find any answer anywhere.
Lets say:
/**
* #brief Adds a Character to a container. That monster will be updated and drawn. The monster is not added if monster with samee ID exists
* #param m Character to add
* #return false if the character was not added.
*/
bool AddZombie(Zombie * m);
Now this will in doxygen create a field with bold headers saying "Parameters" and "Returns".
What I want, however, is to add a paragraph for a complexity. The following code does not do what I want, however
/**
* #brief Adds a Character to a container. That monster will be updated and drawn. The monster is not added if monster with samee ID exists
* #param m Character to add
* #return false if the character was not added.
* #complexity The complexity is O(n)
*/
bool AddZombie(Zombie * m);
Now is there any way to do this?
When I am asking here, please allow me to ask one small little question:
Would it be possible to make a list of all complexities of methods, maybe sorted? Meaning not by coding html, by only using doxygen.
This might seem like a stupid question to people who know alot about doxygen, but, allthough I red documentation and the website, I still sometimes learn something new and hidden I did not know.
Thank you all for any response.
Have a nice day, and thank you for your time
I use Stata since several years now, along with other languages like R.
Stata is great, but there is one thing that annoys me : the generate/replace behaviour, and especially the "... already defined" error.
It means that if we want to run a piece of code twice, if this piece of code contains the definition of a variable, this definition needs 2 lines :
capture drop foo
generate foo = ...
While it takes just one line in other languages such as R.
So is there another way to define variables that combines "generate" and "replace" in one command ?
I am unaware of any way to do this directly. Further, as #Roberto's comment implies, there are reasons simply issuing a generate command will not overwrite (see: replace) the contents of a variable.
To be able to do this while maintaining data integrity, you would need to issue two separate commands as your question points out (explicitly dropping the existing variable before generating the new one) - I see this as method in which Stata forces the user to be clear about his/her intentions.
It might be noted that Stata is not alone in this regard. SQL Server, for example, requires the user drop an existing table before creating a table with the same name (in the same database), does not allow multiple columns with the same name in a table, etc. and all for good reason.
However, if you are really set on being able to issue a one-liner in Stata to do what you desire, you could write a very simple program. The following should get you started:
program mkvar
version 13
syntax anything=exp [if] [in]
capture confirm variable `anything'
if !_rc {
drop `anything'
}
generate `anything' `exp' `if' `in'
end
You then would naturally save the program to mkvar.ado in a directory that Stata would find (i.e., C:\ado\personal\ on Windows. If you are unsure, type sysdir), and call it using:
mkvar newvar=expression [if] [in]
Now, I haven't tested the above code much so you may have to do a bit of de-bugging, but it has worked fine in the examples I've tried.
On a closing note, I'd advise you to exercise caution when doing this - certainly you will want to be vigilant with regard to altering your data, retain a copy of your raw data while a do file manipulates the data in memory, etc.
I am trying to write an HDF5 file from C++. The file basically contains a large timeseries matrix in the following format
TimeStamp Property1 Property2
I have managed to write the data successfully, I created a dset and used the H5Dwrite function.
Now my question is how do I create a file header, in other words, if I want to write the following array to the file...
['TimeStamp', 'Property1', 'Property2']
...and tag it to the columns for ease of later use ( I am planning to analyze the matrix in Python). How to do that?
I tried to use H5Dwrite to write a string array but failed, I guess it wanted consistent datatypes, so it just wanted floats, which is the datatype for my data. Then I read about this metadata thing, but I am a bit lost as to how to use it? Any help would be much appreciated.
A related side question is can the first row of a matrix be a string and the others rows contain doubles?
Clean solution(s)
If you store your data as a 1D array of a compound datatype with members TimeStamp, Property1, Property2, etc. then the field names will be stored as metadata and it should be easy to read in Python.
I think there is another clean option but I will just mention it since I never used it myself: HDF5's Table Interface. Read the docs to see if you would prefer to use that.
Direct answers to your question
Now the dirty options: you could add string attributes to your existing dataset. There are multiple ways to do that. You could have a single string attribute with all the field names separated by semicolons, or one attribute per column. I don't recommend it since that would be terribly non-standard.
A related side question is can the first row of a matrix be a string and the others rows contain doubles?
No.
Example using a compound datatype
Assuming you have a struct defined like this:
struct Point { double timestamp, property1, property2; };
and a vector of Points:
std::vector<Point> points;
as well as a dataset dset and appropriate memory and file dataspaces, then you can create a compound datatype like this:
H5::CompType type(sizeof(DataPoint));
type.insertMember("TimeStamp", HOFFSET(Point, timestamp), H5::PredType::NATIVE_DOUBLE);
type.insertMember("Property1", HOFFSET(Point, property1), H5::PredType::NATIVE_DOUBLE);
type.insertMember("Property2", HOFFSET(Point, property2), H5::PredType::NATIVE_DOUBLE);
and write data to file like this:
dset.write(&points[0], type, mem_space, file_space);
My first question is simple, but cannot find any answer anywhere and it's driving me crazy:
When defining a local list in Stata how do I do a carriage return if the list is really long?
The usual /// doesn't work when inside double quotations marks.
For example, this doesn't work:
local reglist "lcostcrp lacres lrain ltmax ///
ltmin lrainsq lpkgmaiz lwage2 hyb gend leducavg ///
lageavg ldextn lfertskm ldtmroad"
It does work when I remove the quotation marks, but I am warned that I should include the quotations.
My second question is a more serious problem:
Having defined the local reglist, how can I get Stata to remember it for multiple subsequent uses (that is, not just one)?
For example:
local reglist lcostcrp lacres lrain ltmax ///
ltmin lrainsq ///
lpkgmaiz lwage2 ///
hyb gend leducavg lageavg ldextn lfertskm ldtmroad
reg lrevcrp `reglist' if lrevcrp~=.,r
mat brev=e(b)
mat lis brev
/*Here I have to define the local list again. How do I get Stata to remember
it from the first time ??? */
local reglist lcostcrp lacres lrain ltmax ///
ltmin lrainsq ///
lpkgmaiz lwage2 ///
hyb gend leducavg lageavg ldextn lfertskm ldtmroad
quietly tabstat `reglist' if lrevcrp~=., save
mat Xrev=r(StatTotal),1
mat lis Xrev
Here, I define the local reglist, then run a regression using this list and do some other stuff.
Then, when I want to get the means of all the variables in the local reglist, Stata doesn't remember it anymore and have to define it again. This defeats the whole purpose of defining a list.
I would appreciate it if someone could show me how to define a list just once and be able to call it as many times as one likes.
The best answer to your first question is that if you are typing a long local definition in a command, then (1) you don't need to type a carriage return, you just keep on typing and Stata will wrap around and/or (2) there is a better way to approach local definition. I wouldn't usually type long local definitions interactively because that is too tedious and error-prone.
The quotation marks are not essential for examples like yours, only essential for indicating strings with opening or closing spaces.
Your second question is mysterious. Stata won't forget definitions of local macros in the same program (wide sense) unless you explicitly blank out that macro, i.e. redefine it to an empty string. Here program (wide sense) means program (narrow sense), do-file, do-file editor contents, or main interactive session. You haven't explained why you think this happens. I suspect that you are doing something else, such as writing some of your code in the do-file editor and running that in combination with writing commands interactively via the command window. That runs into the difficulty alluded to: local macros are local to the program they are defined in, so (in the same example) macros defined in the do-file editor are local to that environment but invisible to the main interactive session, and vice versa.
I suggest that you try to provide an example of Stata forgetting a local macro definition that we can test for ourselves, but I am confident that you won't be able to do it.
I just learned about the i/o part of the STL, more specifically fstream. Although I can now save binary info and classes I've made to the hard drive, I am not sure how to define how the info should be read.
I saw the answer for making a file format from this post:
Typically you would define a lot of records/structures, such as
BITMAPINFOHEADER, and specify in what order they should come, how they
should be nestled, and you might need to write a lot of indices and
look-up tables. Such files consists of a number of records (maybe
nestled), look-up tables, magic words (indicating structure begin,
structures end, etc.) and strings in a custom-defined format.
What I want to know specifically is how to do this with the STL and C++...
Since the format is meant simply for the use of a game I would think it would be much easier though. The format should:
Be traversable (I can look through it and find the start of structure and maybe check its name
Be able to hold multiple classes and data in a single file
Have identifiable starts and ends to sections: such as the space in text files
Maybe have it's own icon to represent it??
How do I do this in c++ ?
The first stage in determining how to structure your save-file is determining what information needs to be stored. Presumably, you have a list of entities, each of which with generic information (probably derived from one of a few base classes), such as position, velocity etc.
One of the best things you can do to implement a map format is to have a save-parser for each class (some can just derive from the base class' save-parser). So for instance, if you have a player class, which derives from CBaseNPC, you could most-likely simply derive from CBaseNPC, override the parser, calling the base-class function, and adding any other necessary fields, for example, if we had (pseudocode):
void CBaseNPC::Save() {
SaveToFile( health );
SaveToFile( armor );
SaveToFile( weapons );
SaveToFile( position );
SaveToFile( angles );
}
Then for your player class:
void CPlayer::Save() {
CBaseNPC::Save();
SaveToFile( achievement_progress );
}
Obviously, this is just a simple example, and no doubt your saving parsers will have more fields etc. to deal with.
Dealing with the structure of the file itself, the main thing you need to worry about is delimiters, how will your main load-parser recognise what each field corresponds to?
I suppose the best way to explain this would be with an example, the following could be a simple start to a save-file:
Map: {mapname}
Gametime: {gametime}
===Player===
Health: {health}
Armor: {armor}
Weapons: {wep1 (wep1Ammo), wep2 (wep2Ammo), wep3 (wep3Ammo)}
Position: {x, y, z}
Angles: {yaw, pitch, roll} // Could be quaternion instead.
AchievementProgress: {arbritraryData}
===Player===
===NPC-npc_name===
Health: {health}
Armor: {armor}
Weapons: {wep1 (wep1Ammo), wep2 (wep2Ammo), wep3 (wep3Ammo)}
Position: {x, y, z}
Angles: {yaw, pitch, roll} // Could be quaternion instead.
===NPC-npc_name===
===Entity-item_name===
Position: {x, y, z}
Angles: {yaw, pitch, roll}
Model: {modelname}
===Entity-item_name===
Here we have used the "===" string as a delimiter for the start of a class's parameters, and a new line as the delimiter for the parameters within each class.
It is then a relatively simple matter of structuring your parser so it reads in the map name, and loads it. Then sets the game-time to the value specified in the save-file.
It then looks through the file until it finds a "===" reads the string it encounters, and looks it up from a dictionary (possibly an std::map or std::unordered_map) to determine the class to create (or edit) with the information in the file. Once it has determined the class type, it can then proceed to call the Load() function from that class, which will retrieve all the information contained. The parser then looks for the next instance of the "==={string encountered}===" and closes that class. It then proceeds following the same procedure with the next class encountered.
Sorry for the length of this post, and I'm sure it could be made briefer and there are probably some things I have missed, I just wrote this off the top of my head, so there may be erroneous things here, but I hope it puts you on the right path to getting a workable save-file format. :)
If you still have any problems or questions regarding my post, please comment, I'll do my best to answer promptly.