[jira] [Comment Edited] (AVRO-1936) avrogencpp, includes should have more guards or generate more headers

["Thiruvalluvan M. G. (JIRA)" <ji...@apache.org>]

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