I have an enum in my .h file like so:
/** \memberof MyClass
Values for keypress bitmasks for #method and MyClassDelegate#otherMethod */
enum MY_KEYS {
MY_KEY_1_DOWN, /**< KEY 1 press */
MY_KEY_1_UP, /**< KEY 1 release */
MY_KEY_2_DOWN, /**< KEY 2 press */
MY_KEY_2_UP, /**< KEY 2 release */
};
Doxygen generates an entry for this enum under "Public Types" as well as "Member Enumeration Documentation" where the detailed descriptions show up. However, it generates no documentation for the members of the enumeration. I want to list the members of my enumerations and comment them, so that my users can know which values to use where they formal type of an argument is this enumeration.
Don't know if it's relevant--this is in Objective-C, hence \memberof MyClass to show up on this class's page.
Not sure why doxygen doesn't see enum values as inherited by the \memberof command. It doesn't work if you manually set the individual values as members of the enum or class either.
Anyway, the workaround is that if you want the enum to actually appear inside the class, you need to define it within the class interface:
#interface MyClass : NSobject
/**
Values for keypress bitmasks for #method and MyClassDelegate#otherMethod
*/
enum MY_KEYS {
MY_KEY_1_DOWN, /**< KEY 1 press */
MY_KEY_1_UP, /**< KEY 1 release */
MY_KEY_2_DOWN, /**< KEY 2 press */
MY_KEY_2_UP, /**< KEY 2 release */
};
#end
This actually makes more sense IMO, as there's no guarantee that header files contain related types - it's just expected of good design.
I stumbled over the same problem (although for a pure C documentation) - unfortunately this seems to be an issue with Doxygen, see the corresponding Bugzilla entry
individual values in enum not documented if the enum is a member of a
C class
https://bugzilla.gnome.org/show_bug.cgi?id=762320
or the older related bug:
When #relatesalso is used, Doxygen does not output members of enum.
https://bugzilla.gnome.org/show_bug.cgi?id=609299
Update:
A quick fix which solves this problem (tested in Doxygen 1.8.11):
Edit src/doxygen.cpp and remove (or comment) line 7375 in function addEnumValuesToEnums:
if (!e->name().isEmpty() && (fmn=(*emnsd)[e->name()]))
// get list of members with the same name as the field
{
MemberNameIterator fmni(*fmn);
MemberDef *fmd;
for (fmni.toFirst(); (fmd=fmni.current()) ; ++fmni)
{
/* REMOVED LINE 7375: if (fmd->isEnumValue() && fmd->getOuterScope()==md->getOuterScope()) // in same scope */
{
//printf("found enum value with same name %s in scope %s\n",
// fmd->name().data(),fmd->getOuterScope()->name().data());
if (nd && !nd->name().isEmpty() && nd->name().at(0)!='#')
{
The "outer scope" of the C enum was still set to global, i.e. the block which adds enum member values had not been reached.
Please note that I made just a short check and did not thoroughly test the fix - it might have side-effects....
Related
Is there a way to not have to repeatidly write this(parent class args) {super(parent class args);} when the arguments are exactly the same?
The code:
class Parent {
string name;
this(string name) {
this.name = name;
}
}
class Child : Parent {
}
unittest {
auto child = new Child("a name");
assert(child.name == "a name");
}
https://run.dlang.io/is/YnnezI
Gives me the compilation error:
Error: class onlineapp.Child cannot implicitly generate a default constructor when base class onlineapp.Parent is missing a default constructor
Java and C# don't inherit constructors either (unless that's changed in the last few years - I don't think C++ allowed it either until c++11), and D follows the same reasoning so you can read more by looking up things about them.
Basically though the reason is that subclasses must have their own unique state - at very least stuff like the vtable even if you don't declare any of your own variables - and thus a unique constructor is required. Otherwise you can have uninitialized members.
And if inheritance went the whole way, since Object has a this(), new AnyClass(); would compile and lead to a lot of invalid objects. (In regular D, if you declare any ctor with arguments, it disables the automatically-generated zero arg one.)
Now, D could in theory do what C++ does and auto-generate other args too... it just doesn't. Probably mostly because that is a relatively new idea in C++ and D's class system is primarily based on Java's older system.
But all that said, let me show you a trick:
this(Args...)(auto ref Args args) { super(args); }
stick that in your subclass and you basically inherit all the parent's constructors in one go. If the super doesn't compile for the given args, neither will this, so it doesn't add random things either. You can overload that with more specific versions if needed too, so it is a reasonable little substitute for a built-in language feature.
I'm looking for a way to set up code formatting to keep javadoc in enums in separate blocks. Right now wrapping of enum members works as intended, but for some reason javadoc comments start/end on the same line as the members
I'd keep getting this:
public enum FormatTest {
FOO, /**
* some description
*/BAR, BAZ;
}
but I want it to look something like this:
public enum FormatTest {
FOO,
/**
* docs either like this
*/
BAR,
/** or like this */
BAZ;
}
It works perfectly well for class members strangely enough...
try changing the Code Style settings.
In IntelliJ, go to: Settings -> Code Style -> Java -> Wrapping and Braces tab.
Scroll down untill you see Enum constants, and change the value to: Wrap always.
See screenshot
In other programming languages like Java if you want to chain fields, you do like: String a, b, c, d;
Is it possible to chain fields in Kotlin too, like val a, b, c, d?
here doesn`t provide any info
No, Kotlin does not support declaration of multiple variable in a statement.
Kotlin has learned some good lessons from Java. One of that is variable declaration. Though Java support multiple variable declaration in a line, Oracle's Java Guidelines says use only one declaration per line.
Following is mentioned in Oracle Java Standard:
One declaration per line is recommended since it encourages commenting. In other words,
int level; // indentation level
int size; // size of table
is preferred over
int level, size;
In absolutely no case should variables and functions be declared on the same line. Example:
long dbaddr, getDbaddr(); // WRONG!
Do not put different types on the same line. Example:
int foo, fooarray[]; //WRONG!
Note: The examples above use one space between the type and the identifier. Another
acceptable alternative is to use tabs, e.g.:
int level; // indentation level
int size; // size of table
Object currentEntry; // currently selected table entry
Refer this link for Oracle convention: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf. Page no. 14 > Declarations.
There has been some huge debates on this topic of type of declaration should be used for Java. So Kotlin just removed that as an option.
First, Kotlin is a null-safety language which means you can't declare fields without initializing them, and Kotlin has no default value for any types even if it is nullable, but there is an exception for the primitive array, e.g:IntArray(size) the default value likes as java are 0. So you can't write the form of the field declaration as in Java, for example:
//Java
private String a,b,c;// they are `null` by default.
private val a:String? // error: property must be initialized
Secondly, If you are concerned about the definition of fields/variables, they are totally different. the field/variable type is declared at the right-side, which means you can't declare a unified fields/variables in Kotlin at all, so it doesn't make sense in Kotlin, for example:
//Java
String a,b;
//Kotlin
val a, b;
// ^---^--- how to declare the variables type?
// v-- just more than one `val` after introduce the variable types
val a:String; val b:String;
Finally, field is a heavy component in Kotlin. when you declare a field in Java it is merely a field, no more. but in Kotlin when you declare a field, it maybe a property/field. and a property has getter/backing field(?)/setter(?), for example:
// java
String a; //just a field
// kotlin
var a:String = "a" // has a backing field, getter & setter
private var b:String = "b" // it is just a field
#JvmField var c:String = "c"
// ^--- it is a field but it has getter/setter in reflect
// e.g: this::c.getter & this::c.setter
I was not able to reference a specific class method using the doxygen #see command.
Suppose I have a class Server with a method start like below
#interface Server : NSObject
- (void) start:(NSInteger) mask;
#end
And suppose I have another class that has an object of Server.
#interface RandomNumberGeneration
/// How can I reference the method start from
/// class server using the command #see
/// #see ????
+ (NSInteger) generate;
#end
So, is there a way to reference the method start of class Server?
Copied from here
#see text | URL | classname | classname#methodname Use this to tag to
refer the reader to some other source of related information.
So I guess it should be:
/// #see Server#start:
See the doxygen manual page Automatic link generation for more information on referencing classes and functions. In particular see the section "Links to Functions".
Typically, I use the function refernce pattern
<className>::<functionName>
So in your case, I would use
/// \see Server::start
However, from the doxygen manual
For JavaDoc compatibility a # may be used instead of a :: in the patterns above
as stated in #PeterG.'s answer.
For completeness, note that if you a reference a member in the same class
In the documentation of a class containing a member foo, a reference to a global variable is made using ::foo, whereas #foo will link to the member.
What is the difference between
typedef enum {
...
} Name;
and
enum {
...
};
typedef NSUInteger Name;
? If functionality is the same, what is the second form good for? Isn't it unnecessarily messy?
enum is as old as C, therefore a part of Objective-C.
It is just explicit coding of an int type. It's quite useful for debugging and most newer compilers can make optimizations based on it. (Which you should totally ignore). It's most useful in making your code more readable (to anyone else, or to yourself after you've slept).
typedef enum {
...
} NameType ;
would be followed by
NameType name;
and that's typically the preferred style of a typedef,
your second example will not tie the typedef to the values you want to specify should only be of the given type.
Note that this does not prevent you from executing
name = 10244; // some non-valid value not listed in the enumeration
but some compilers might generate a warning in that case,
I ran across Apple's use of the following today:
enum {
NSFetchedResultsChangeInsert = 1,
NSFetchedResultsChangeDelete = 2,
NSFetchedResultsChangeMove = 3,
NSFetchedResultsChangeUpdate = 4
};
typedef NSUInteger NSFetchedResultsChangeType;
They do this because they really want the NSFetchedResultsChangeType to be of the type they have defined as NSUInteger. This can be an int but it can also be something else. And with values of 1, 2, 3, and 4, it's somewhat irrelevant to us what the type is. But they are coding to a different level of abstraction because they are a tools provider.
You should never look to Apple for coding style hints. If you see something that looks like it's cleaner/better way to code, it usually is. As Kevin mentioned, API stability is of paramount importance for them.
Edit (Jan 2013) If you have access to the WWDC 2012 Session Videos, you should watch Session 405 - Modern Objective-C 6:00-10:00. There is discussion a new syntax in the newer compiler that allows explicit sizing of a type and tight bonding of values to types. (borrowed from C++ 11)
enum NSFetchedResultsChangeType : NSUInteger {
NSFetchedResultsChangeInsert = 1,
NSFetchedResultsChangeDelete = 2,
NSFetchedResultsChangeMove = 3,
NSFetchedResultsChangeUpdate = 4
};
The former defines a type name to refer to an enum. This is the way most enums are named in C. The latter is a bit different though, and it's prevalent in the Cocoa frameworks. There's two reasons to use the latter. The first is if your enum defines a bitfield, and you'd want it here because when you're providing a "Name" value you'll be providing a combination of the enum values. In other words, if you say something like
[self doSomethingWithBitfield:(Enum1 | Enum2)]
you're not passing a value of Name but rather an integer that's a combination of the two.
However, Cocoa frameworks use this idiom even for non-bitfield values, for a very good reason: API stability. According to the C standard, the underlying integral type of an enum is requires to be able to contain all values in the enum, but is otherwise chosen by the compiler. This means that adding a new enum value could change the integral type of the enum (e.g. adding -1 can make it signed, adding 6 billion can make it into a long long, etc). This is a bad thing from an API stability standpoint, because the type encoding of methods which take values of this enum could change unexpectedly and potentially break existing code and binaries. In order to prevent this, the Cocoa frameworks generally define the type as being an NSUInteger (or NSInteger if they need negative numbers), so the API and type encodings stay stable.