The Google coding guide opposes to forward declarations, but I
disagree with that opinion. In my opinion, forward declarations are
useful. Ceph build times are miserable due to header dependency bloat
and template bloat, both of which can be reduced using forward
declarations.
All cons listed in https://google.github.io/styleguide/cppguide.html
> Forward declarations can hide a dependency, allowing user code to
> skip necessary recompilation when headers change.
That is a pro, not a con. Skipping (unnecessary) recompilation is a
good thing, it's the goal of forward declarations.
> A forward declaration as opposed to an #include statement makes it
> difficult for automatic tooling to discover the module defining the
> symbol.
That certainly depends on the tools one uses, but I cannot imagine
today's IDEs are limited to one compilation unit.
> A forward declaration may be broken by subsequent changes to the
> library.
True, and that will lead to a compiler error.
> Forward declarations of functions and templates can prevent the
> header owners from making otherwise-compatible changes to their
> APIs, such as widening a parameter type, adding a template parameter
> with a default value, or migrating to a new namespace.
Forward declarations do not prevent any of that. But if you change
the "real" declaration, all incompatible forward declarations will
cause a compiler error.
> Forward declaring symbols from namespace std:: yields undefined
> behavior.
Sad, but true. But that is not an argument against forward
declarations for Ceph's own types.
> It can be difficult to determine whether a forward declaration or a
> full #include is needed.
If it compiles without the `#include`, then the forward declaration is
fine. (Or the primary header happened to be already included by
somebody else.)
> Replacing an #include with a forward declaration can silently change
> the meaning of code: [...] If the #include was replaced with forward
> decls for B and D, test() would call f(void*).
True, but this is a contrived example, and is bad coding style because
it is error prone. Casts to `void*` can and should be avoided. There
are rare examples where such casts are necessary (boundary to C APIs),
and then it's very unusual to pass derived incomplete types.
> Forward declaring multiple symbols from a header can be more verbose
> than simply #includeing the header.
True, but that misses the point of forward declarations.
> Structuring code to enable forward declarations (e.g., using pointer
> members instead of object members) can make the code slower and more
> complex.
True, but that is not a property of forward declarations. I don't
suggest doing such a thing.
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
The primary motivation to relicense is a desire to integrate with projects
that are licensed under the Apache License version 2.0. Although opinions
vary, there are some who argue the the LGPL-2.1 and Apache-2.0 licenses
are not fully compatible. We would like to avoid the ambiguity and
potential for controversy.
Projects we would like to consume that are Apache-2.0 licensed include
Seastar, OpenSSL (which is in the process of relicensing to Apache-2.0),
and Swagger (swagger.io). Note that some of these are dynamically linked
or consumed via a high-level language and may or may not require a change
to LGPL-3.0, but providing the option for LGPL-3.0 certainly avoids any
uncertainty.
A few other source files are already incorporated into Ceph that claim an
Apache-2.0 license:
src/common/deleter.h
src/common/sstring.h
src/include/cpp-btree
The Ceph developers would further like to provide a license option that is
more modern than the current LGPL-2.1. LGPL-3.0 includes updated,
clarified language around several issues and is widely considered
more modern, superior license.
Signed-off-by: Sage Weil <sage@redhat.com>
The C++ style was originally adopted in 2011. Most of the guidelines
have been followed but some have not. Drop the ones we haven't been
following.
Signed-off-by: Sage Weil <sage@redhat.com>
As we are rapidly expanding our code base beyond C++ and C, it is a good
idea to enforce coding styles for other languages.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Back in commit 7469f26a33 when the COPYING
file was added to the repository and the project was "licensed," the
license file was
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
However, the license was abbreviated as LGPL2 in various places (pretty
much everywhere, actually), due to my own ignorance/carelessness. (I was
distinguishing it from shiny new version 3, released 6 months earlier.)
Version 2 of LGPL is the "Library General Public License," published in
June 1991: https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
Note that this ambiguity persists for most of the project's lifetime. For
example, the original debian/copyright in 8adc9dac1d
said "LGPL2" bug in 4545f8b929 (2009, a year
later) it is changed to LGPL2.1 to satisfy Debian's lintian checks. (It's
remained LGPL2.1 ever since.)
"Correct" the record by changing LGPL2 references to LGPL2.1.
Signed-off-by: Sage Weil <sage@redhat.com>
- _d suffix for naked struct/class types (not _t!)
- m_ prefix for class members
- prefer braces for single line ifs.
Signed-off-by: Sage Weil <sage@newdream.net>
Max Kellermann
Nizamudeen A
Ponnuvel Palaniyappan
Daniel Gryniewicz
Sage Weil
Tiago Melo
Joao Eduardo Luis
Kefu Chai
Dan Mick
Sage Weil
Tommi Virtanen