[
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:09 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)
