[ https://issues.apache.org/jira/browse/AVRO-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730381#comment-16730381 ]
Thiruvalluvan M. G. edited comment on AVRO-1936 at 12/28/18 5:06 PM: --------------------------------------------------------------------- Even though the mechanism of using individual guards for each generated type would work, it is not a common idiom in \{{C++}}. In a single project there would be multiple definitions of the same type (in multiple header files) and exactly one of them would be used based on the order of \{{include}}s. If these multiple definitions are not identical, (it is possible because they are generated using different schema files) the "One definition rule" of +{{+C++}} would be broken. Also, IDEs will have difficulty in locating the definition for a given type. I think the other approach provided namely, generating separate header files for each type (AVRO-1370) is a better idea. Here the developer has explicit control by deciding to {{include}} specific header or move the header files around to suit their needs. A negative of this approach is that build will be slow because of including several files instead of a single file previously. Yet another approach is to allow generating header files from multiple schema files at once where de-duping is done by the code generator. was (Author: thiru_mg): Even though the mechanism of using individual guards for each generated type would work, it is not a common idiom in C++. In a single project there would be multiple definitions of the same type (in multiple header files) and exactly one of them would be used based on the order of \{{include}}s. If these multiple definitions are not identical, (it is possible because they are generated using different schema files) the "One definition rule" of C++ would be broken. Also, IDEs will have difficulty in locating the definition for a given type. I think the other approach provided namely, generating separate header files for each type (AVRO-1370) is a better idea. Here the developer has explicit control by deciding to {{include}} specific header or move the header files around to suit their needs. A negative of this approach is that build will be slow because of including several files instead of a single file previously. Yet another approach is to allow generating header files from multiple schema files at once where de-duping is done by the code generator. > avrogencpp, includes should have more guards or generate more headers > --------------------------------------------------------------------- > > Key: AVRO-1936 > URL: https://issues.apache.org/jira/browse/AVRO-1936 > Project: Apache Avro > Issue Type: Bug > Components: c++ > Affects Versions: 1.8.1 > Reporter: Alexander Moriarty > Priority: Major > > Inside of an avdl file, one can include other avdl files. But the generated > only one header file is generated and it does not include guard the > enums/structs which were defined in the other avdl files. > I have some basic records which I've defined in there own avdl files, and > include them inside of more complicated structures. > All is well, until I try to include multiple of the avro generated header > files. > Inside of your AvrogencppTests you have gotten around this by giving each > generated type there own name space. > As a test, I quickly modified the existing avrogencpp.cc to include an > optional name to CodeGen::guard. > {code:none} > std::string guard(const string& name=""); > [...] > string CodeGen::guard(const string& name) > { > string h = name.empty() ? headerFile_ : name; > makeCanonical(h, true); > return h + "_" + lexical_cast<string>(random_()) + "__H_"; > } > {code} > And then adding guards around each Enum, Record, Union, Traits, etc. > Which works well enough. However... the guards do not include the namespace > names, so this change breaks your unit tests. > As long as two higher level classes in the same namespace do not include the > same subclasses the generated header files can both be used, but if you have > a basic data type like an Point(x,y) which is used throughout the higher > level classes then they will both redefine Point(x,y) > On the Java side, everything is okay. Point(x,y) and all of the classes which > include Point are in their own files inside of a package. > Is there any common way around this problem? -- This message was sent by Atlassian JIRA (v7.6.3#76005)