[
https://issues.apache.org/jira/browse/AVRO-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602631#comment-15602631
]
ASF GitHub Bot commented on AVRO-1936:
--------------------------------------
GitHub user moriarty reopened a pull request:
https://github.com/apache/avro/pull/142
AVRO-1936: C++: adds new include guards
This change adds additional include guards in a different format.
https://issues.apache.org/jira/browse/AVRO-1936
Removes the random numbers from the include guards, instead guarding
only by NAMESPACE_TYPE_ where TYPE is the Enum, Record or Union Type.
Adds #ifndef NAMESPACE_TYPE_... checks before each struct declaration.
Adds #define NAMESPACE_TYPE_... to the generate(Enum/Record/Union)Traits
funtion.
This allows including multiple of the generated C++ files into one
source C++ file, where the avsc files were generated from avdl, and the
avdl files contained includes with shared basic types.
The previous way to achieve this, as was done in the AvrogencppTests,
was to abuse or take advantage adding additional meaningless namespaces.
This doesn't fail the existing AvrogencppTests, but I would like input from
avro-cpp users how they've gotten around this and if this breaks anything.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/moriarty/avro
avro-1936/cpp-include-guards-enhancement/dev
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/avro/pull/142.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #142
----
commit 92549ed69c56e2f393c361143c3b8ee90e05d538
Author: Alexander Moriarty <alexander.moria...@tba.nl>
Date: 2016-10-24T11:59:19Z
AVRO-1936: C++: adds new include guards
This change adds additional include guards in a different format.
Removes the random numbers from the include guards, instead guarding
only by NAMESPACE_TYPE_ where TYPE is the Enum, Record or Union Type.
Adds #ifndef NAMESPACE_TYPE_... checks before each struct declaration.
Adds #define NAMESPACE_TYPE_... to the generate(Enum/Record/Union)Traits
funtion.
This allows including multiple of the generated C++ files into one
source C++ file, where the avsc files were generated from avdl, and the
avdl files contained includes with shared basic types.
The previous way to achieve this, as was done in the AvrogencppTests,
was to abuse or take advantage adding additional meaningless namespaces.
I have left one line of Commented out Code for input from avro-cpp
users on this proposal.
----
> avrogencpp, includes should have more gaurds or generate more headers
> ---------------------------------------------------------------------
>
> Key: AVRO-1936
> URL: https://issues.apache.org/jira/browse/AVRO-1936
> Project: Avro
> Issue Type: Bug
> Affects Versions: 1.8.1
> Reporter: Alexander Moriarty
>
> 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
(v6.3.4#6332)
