Header-only C++, what is the point? In C this would be a obvious mistake

[Christiano]

I come from the C language. I have the impression that in C ++ the ideal
is "C ++ header only" libraries. See Boost, the most important set of
libraries is a clear example of this.But this is very clearly opposite
to the C world where if someone write body code definitions in headers is
considered someone who is learning, a beginner making mistakes. The
separation between definition and statement is very clear.

Books like K & R, Mastering Algorithms, use a separation, which is the
natural way of thinking of C. In fact whenever I used libraries made in C,
I never saw anything that was "header-only".

So, what's the point? Why in C ++ is this way?

[Daniel]

On Thursday, February 2, 2017 at 2:11:29 PM UTC-5, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.
>

> So, what's the point? Why in C ++ is this way?

It's partly for practical reasons. It's easier to use a third party header only
library. With C++, separate libraries have to be built for every version of
every compiler supported, which can be difficult to manage. Particularly if
you're supporting a mix of compilers, compiler versions, and operating systems,
and use travis to test your code, as many open source projects do.

Daniel

[Alf P. Steinbach]

On 02.02.2017 20:11, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.

It's not an ideal, but it's a possibility, and for template code a
necessity.

For non-template code one great advantage is that it simplifies builds
of the client code: there's nothing to do, no choice between umpteen
pre-built variants like debug+DLL+multithreaded runtime, etc.

The main disadvantage is also related to building: that essentially
everything needs to be compiled when one re-builds something.

Another disadvantage is that there's no boundary between interface and
implementation, no compiler firewall. In particular that means that two
modules whose implementations depend on each others interfaces, can be
difficult to express. One example is that exceptions carry strings, but
strings use exceptions.

> See Boost, the most important set of
> libraries is a clear example of this.But this is very clearly opposite
> to the C world where if someone write body code definitions in headers is
> considered someone who is learning, a beginner making mistakes. The
> separation between definition and statement is very clear.

Oh, it can be more clear in C++, via public, protected and private
access, and via namespace conventions such as Boost's `detail` and
others' `impl`.

> Books like K & R, Mastering Algorithms, use a separation, which is the
> natural way of thinking of C. In fact whenever I used libraries made in C,
> I never saw anything that was "header-only".
>
> So, what's the point? Why in C ++ is this way?

Originally, in C++98 and C++03, C++ had an `export` feature for separate
compilation of templates. This was difficult to implement, and AFAIK
only two compilers did, namely Comeau, and, accessible via an
undocumented option, Intel. I think both relied on an Edison group back-end.

Since lots of compilers simply didn't implement `export` it was removed
in C++11, along with some other unsuccessful features.

As a possible replacement there is a module proposal being worked on,
based on a module implementation in clang, and now being fleshed out via
the Visual C++ compiler. IIRC it's Gabriel Dos Reyes (speling?) and one
other guy doing this. I am not at all sure how it connects, if at all,
but hopefully, to separate compilation of templates.


Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

Christiano <chris...@engineer.com> spake the secret code
<58938458$0$10252$c3e8da3$e408...@news.astraweb.com> thusly:

>I come from the C language.

My best general advice for C programmers:

1. Forget what you know about C when reading C++.
2. Treat C++ as a new language and not as a dialect of C.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[woodb...@gmail.com]

On Thursday, February 2, 2017 at 1:38:34 PM UTC-6, Alf P. Steinbach wrote:
> On 02.02.2017 20:11, Christiano wrote:
> > I come from the C language. I have the impression that in C ++ the ideal
> > is "C ++ header only" libraries.
>
> It's not an ideal, but it's a possibility, and for template code a
> necessity.
>
> For non-template code one great advantage is that it simplifies builds
> of the client code: there's nothing to do, no choice between umpteen
> pre-built variants like debug+DLL+multithreaded runtime, etc.
>
> The main disadvantage is also related to building: that essentially
> everything needs to be compiled when one re-builds something.

Another disadvantage is that the size of executables grows.
That may be a bigger disadvantage than increased build times.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Alf P. Steinbach]

On 03.02.2017 05:34, woodb...@gmail.com wrote:
> On Thursday, February 2, 2017 at 1:38:34 PM UTC-6, Alf P. Steinbach wrote:
>> On 02.02.2017 20:11, Christiano wrote:
>>> I come from the C language. I have the impression that in C ++ the ideal
>>> is "C ++ header only" libraries.
>>
>> It's not an ideal, but it's a possibility, and for template code a
>> necessity.
>>
>> For non-template code one great advantage is that it simplifies builds
>> of the client code: there's nothing to do, no choice between umpteen
>> pre-built variants like debug+DLL+multithreaded runtime, etc.
>>
>> The main disadvantage is also related to building: that essentially
>> everything needs to be compiled when one re-builds something.
>
> Another disadvantage is that the size of executables grows.

Huh. How, do you think?

> That may be a bigger disadvantage than increased build times.

Cheers!,

- Alf

[woodb...@gmail.com]

I wasn't sure if you meant why it grows or why that's not good.
I'll assume you meant the latter. I think there's more
redundancy in executables built from header only libs. Say
the header only version of a program is 100k and the alternative
is 85k. The smaller version is easier for an operating system
to work with.

[Gareth Owen]

woodb...@gmail.com writes:

> I wasn't sure if you meant why it grows or why that's not good.
> I'll assume you meant the latter. I think there's more
> redundancy in executables built from header only libs. Say
> the header only version of a program is 100k and the alternative
> is 85k.

Oh, I know this. "What is 'Begging the question', Alex?"

[Wouter van Ooijen]

Op 03-Feb-17 om 06:24 schreef woodb...@gmail.com:

But why would the header-only version be larger?

Wouter "Objects? No Thanks!" van Ooijen

[Robert Wessel]

On Fri, 3 Feb 2017 08:01:23 +0100, Wouter van Ooijen <wou...@voti.nl>
wrote:

Because it may well have duplicated code in a number of places that
might otherwise have been a single copy in a linked in library.
Similar to how using std::sort<> instead of qsort() can lead to bigger
code, since you'll get a copy of the sort code for each
specialization. OTOH, the specialized code may well run faster.

And this is at least somewhat a QoI issue - there's little preventing
a compiler and linker from creating specializations of qsort if the
code is available. Or from the implementation from implementing
std::sort as little more than a single line call to qsort (yes, it
would not actually be quite that simple, but you could leave the
majority of the code in a library so that it has overhead more like
qsort calling an external comparison function).

[David Brown]

There is also the case that with templates, you quite often only need
one instance in the program. std::sort<double> is going to generate
smaller code than a general library function that can handle multiple
different types. A template class might have dozens of methods of which
you only use a few - with header-only versions, only those few get
generated while with a library version, /all/ of them are needed.

I think Brian's fear of template code size stems from the old days in
which toolchains effectively generated a new copy of each used template
function/method for every file that used it, leading to bloat.

[Manfred]

On 2/2/2017 8:37 PM, Alf P. Steinbach wrote:
> As a possible replacement there is a module proposal being worked on,
> based on a module implementation in clang, and now being fleshed out via
> the Visual C++ compiler. IIRC it's Gabriel Dos Reyes (speling?) and one
> other guy doing this.

Gabriel Dos Reis

[Öö Tiib]

On Thursday, 2 February 2017 21:11:29 UTC+2, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries. See Boost, the most important set of
> libraries is a clear example of this.But this is very clearly opposite
> to the C world where if someone write body code definitions in headers is
> considered someone who is learning, a beginner making mistakes. The
> separation between definition and statement is very clear.

You likely oversimplify C++.

When I write my own classes then those are usually straight
to the point, exactly what is needed in concrete application.
Also only bare minimum what is needed for other classes
of application is exposed in header files.

When someone writes libraries like in Boost then they are
trying to be maximally generic, flexible and feature-rich.
That means templates. However hiding information to have
faster builds and reduced dependencies is impossible to do
with templates currently.

>
> Books like K & R, Mastering Algorithms, use a separation, which is the
> natural way of thinking of C. In fact whenever I used libraries made in C,
> I never saw anything that was "header-only".
>
> So, what's the point? Why in C ++ is this way?

The problem is with that #include text copy-paste interface.
That is good for C but is screwed in C++ because it does not
work with templates. That #include thingy simply can't pull
the weight.

[Wouter van Ooijen]

Op 03-Feb-17 om 08:16 schreef Robert Wessel:

The same design, minimally modified for a headers-only approach, will
generate the same code.

> Similar to how using std::sort<> instead of qsort() can lead to bigger
> code, since you'll get a copy of the sort code for each
> specialization. OTOH, the specialized code may well run faster.

But that not due to the header-only nature of sort<> but to the fact
that it uses templates, which is not possible with a split
header/implementation approach.

The line I was specifically responding to was "redundancy in executables
built from header only libs" which suggest that the writer thinks that
each time a header is included a separate block of code will be
generated, all to be included in the executable. It is possible to
achieve this, but it is far from typical.

[woodb...@gmail.com]

I didn't use the word template.

In this file
https://github.com/Ebenezer-group/onwards/blob/master/ErrorWords.cc

I have this function:

cmw::failure& cmw::failure::operator<< (char const* s)
{
whatStr.append(s);
return *this;
}

If I move the implementation into the header, the size of
an executable increases by 511 bytes (over 1%). That's
using GCC 7 with -O2 on FreeBSD 12. Something similar happens
with Clang 3.9.1.


Brian
Ebenezer Enterprises - "Fear of man will prove to be a snare,
but whoever trusts in the L-RD is kept safe." Proverbs 29:25

http://webEbenezer.net

[Wouter van Ooijen]

Op 03-Feb-17 om 18:30 schreef woodb...@gmail.com:

And if you move it to the header and mark it as never_inline (with
whatever syntax your compiler uses for that)?

[Jorgen Grahn]

On Thu, 2017-02-02, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.

My view on that is, that what the authors of some library used by
thousands of others do, has very little to do with what *I* do to
my own non-library code.

You don't have to write your own code that way. Possibly, you
shouldn't even try.

> See Boost, the most important set of libraries is a clear example of
> this.But this is very clearly opposite to the C world where if
> someone write body code definitions in headers is considered someone
> who is learning, a beginner making mistakes. The separation between
> definition and statement is very clear.

Maybe not so much in the past two decades, after the 'inline' keyword
got introduced with C99. Look at the Linux kernel, for example: there
are plenty of inline functions in header files, and they are carefully
chosen to balance readability and performance.

> Books like K & R, Mastering Algorithms, use a separation, which is
> the natural way of thinking of C. In fact whenever I used libraries
> made in C, I never saw anything that was "header-only".
>
> So, what's the point? Why in C ++ is this way?

Why not?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[woodb...@gmail.com]

That helps a little, but the text segment of the executable is
still 336 bytes larger than when it's in the .cc.

36,881 -- in the .cc
37,217 -- in the .hh using __noinline
37,392 -- in the .hh


Brian

[Ian Collins]

On 02/ 4/17 09:00 AM, woodb...@gmail.com wrote:
> On Friday, February 3, 2017 at 12:40:10 PM UTC-6, Wouter van Ooijen wrote:
>> Op 03-Feb-17 om 18:30 schreef woodb...@gmail.com:
>>

>> And if you move it to the header and mark it as never_inline (with
>> whatever syntax your compiler uses for that)?
>
> That helps a little, but the text segment of the executable is
> still 336 bytes larger than when it's in the .cc.
>
> 36,881 -- in the .cc
> 37,217 -- in the .hh using __noinline
> 37,392 -- in the .hh

Does anyone, other than you, care?

--
Ian

[Andrey Tarasevich]

On 2/2/2017 11:11 AM, Christiano wrote:
>
> So, what's the point? Why in C ++ is this way?
>

On the one hand, in the traditional approach "header-only" libraries in
C++ are typically purely (or predominantly) _template_ libraries. They
consist of "immaterial" template definitions. In such cases
"header-only" is not a goal in itself, it is a natural consequence (or
even a necessity) rooted in the functionality of templates. The moment a
C++ library acquires a regular "material" definition, like a global
variable or a non-inline function, it usually ceases to be "header-only".

The same thing would happen is you decided to write a C library
consisting of macros and nothing else. You'd have no choice but to put
everything into a header file. You'd ended up with a typical
"header-only" library. No way around it.

On the other hand, if some C++ library is 99.9% template/inline and only
a very small portion of it are "regular" functions (i.e. functions that
would typically use non-header definitions), then one can say that
erecting the traditional .h/.cpp/.a infrastructure on both the library
side and client side just for some odd function might be an overkill. In
cases like that it might make more sense to keep things "header-only" by
declaring the function 'inline' (even if it is large).

However, I'm also not surprised we see a tendency towards _non-template_
"header-only" libraries these days, i.e. libraries where everything is
just indiscriminately declared 'inline'. It is just easier to write,
maintain and use, even if it requires the compiler to waste quite a bit
of effort translating it [almost] from scratch every time it is
#include-d and then eliminating the resultant code duplication. Within
certain reasonable limits this is a viable approach.

--
Best regards,
Andrey Tarasevich

[Wouter van Ooijen]

Op 04-Feb-17 om 00:23 schreef Ian Collins:

I do, because I program very small chips and I like to get a grip on
what the compiler exactly does. But I'm not going to analyse >30k of
output :)

[Ian Collins]

Quite. When working with small chips, use the appropriate compiler or
linker options to get the best size and performance tradeoff.

--
Ian

[Christiano]

Okay, I understand, when someone does non-generic programs (not using
templates) then the traditional method of separating between .h and .cpp
happens naturally (even though there are projects using non-traditional
alternatives).
But when using templates, the template itself does not produce code (only
in the instance) and is then placed in the .h, in a natural way.

So, curiosity arises, does this imply that every generic library in c ++
is necessarily open source?

[Adam C. Emerson]

On 2017-02-05, Christiano <chris...@engineer.com> wrote:
[snip]

> But when using templates, the template itself does not produce code
> (only in the instance) and is then placed in the .h, in a natural
> way.
>
> So, curiosity arises, does this imply that every generic library in
> c ++ is necessarily open source?

No. See https://opensource.org/osd-annotated .

For software to qualify as 'open source', the author must not only
release the source code, but grant license for redistribution and
modification.

In Berne Convention countries, software is automatically covered by
copyright law, so unless there is a specific license grant, one is not
legally permitted to modify and redistribute it.

[woodb...@gmail.com]

Probably James Kanze. In the past, at least, he wasn't a
fan of header-only libraries.

And it's not like this is an isolated example. There's
another function in the same class that increases the size,
more than this function, if it's in the header.


Brian
Ebenezer Enterprises - "Respect thrift and economy, and
beware of debt." Philip Reed

http://webEbenezer.net

[Ian Collins]

On 02/ 5/17 03:56 PM, woodb...@gmail.com wrote:
> On Friday, February 3, 2017 at 5:23:14 PM UTC-6, Ian Collins wrote:
>> On 02/ 4/17 09:00 AM, woodb...@gmail.com wrote:
>>> That helps a little, but the text segment of the executable is
>>> still 336 bytes larger than when it's in the .cc.
>>>
>>> 36,881 -- in the .cc
>>> 37,217 -- in the .hh using __noinline
>>> 37,392 -- in the .hh
>>
>> Does anyone, other than you, care?
>>
>
> Probably James Kanze. In the past, at least, he wasn't a
> fan of header-only libraries.

Most header only libraries are that way because they have to be.

> And it's not like this is an isolated example. There's
> another function in the same class that increases the size,
> more than this function, if it's in the header.

Probably because it gets inlined more often. The code may well run
faster because of this.

--
Ian

[woodb...@gmail.com]

It might run faster on a machine that has spare memory.
Programs that don't hog resources though make for better
neighbors.


Brian
Ebenezer Enterprises - "Our world is a college, events are teachers,
happiness is the graduating point, character is the diploma G-d gives
man." Newell Dwight Hillis

http://webEbenezer.net

[Juha Nieminen]

Christiano <chris...@engineer.com> wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.

Where did you get that impression? I have never heard of such an ideal.

Many libraries with heavy use of templates may be header-only, mostly
because of necessity. Some non-template libraries may also be header-only,
but there seldom is any good reason for it (unless the library is really
small), and it often only needlessly increases compilation times (sometimes
to an extraordinary extent, when we are talking about humongous libraries
with tens of thousands of lines of code).

[woodb...@gmail.com]

On Tuesday, February 7, 2017 at 1:13:34 AM UTC-6, Juha Nieminen wrote:
> Christiano <chris...@engineer.com> wrote:
> > I come from the C language. I have the impression that in C ++ the ideal
> > is "C ++ header only" libraries.
>
> Where did you get that impression? I have never heard of such an ideal.
>
> Many libraries with heavy use of templates may be header-only, mostly
> because of necessity. Some non-template libraries may also be header-only,
> but there seldom is any good reason for it (unless the library is really
> small),

The nature of the library and how it is (typically) used might be
a factor also. My generated messaging and marshalling libraries
are header-only. In my experience, the functions in the libraries
are usually called once by an application. There's an exception to
that where a message that conveys error information is called 3 times
in one app. This thread got me thinking about my use of header-only
libraries so I checked how much difference it would make size-wise if
that function was in a .cc file. Doing so reduced the size of the
application's text segment by 128 bytes.

In this messaging context, it seems like most of the time I'll be
able to get away with header-only libraries. But for my hand-written
library code:
https://github.com/Ebenezer-group/onwards

I don't have that luxury.


Brian
Ebenezer Enterprises -

"Everybody makes mistakes,
A fault we all must share;
But attitudes have changed with time:
Too few of us now care." Art Buck

http://webEbenezer.net

[woodb...@gmail.com]

On Tuesday, February 7, 2017 at 11:22:22 AM UTC-6, woodb...@gmail.com wrote:
> On Tuesday, February 7, 2017 at 1:13:34 AM UTC-6, Juha Nieminen wrote:
> > Christiano <chris...@engineer.com> wrote:
> > > I come from the C language. I have the impression that in C ++ the ideal
> > > is "C ++ header only" libraries.
> >
> > Where did you get that impression? I have never heard of such an ideal.
> >
> > Many libraries with heavy use of templates may be header-only, mostly
> > because of necessity. Some non-template libraries may also be header-only,
> > but there seldom is any good reason for it (unless the library is really
> > small),
>
> The nature of the library and how it is (typically) used might be
> a factor also. My generated messaging and marshalling libraries
> are header-only. In my experience, the functions in the libraries
> are usually called once by an application. There's an exception to

s/once/in one place/

> that where a message that conveys error information is called 3 times

s/times/places/

> in one app. This thread got me thinking about my use of header-only
> libraries so I checked how much difference it would make size-wise if
> that function was in a .cc file. Doing so reduced the size of the
> application's text segment by 128 bytes.
>
> In this messaging context, it seems like most of the time I'll be
> able to get away with header-only libraries. But for my hand-written
> library code:
> https://github.com/Ebenezer-group/onwards
>
> I don't have that luxury.
>

Brian
Ebenezer Enterprises

http://webEbenezer.net

[woodb...@gmail.com]

On Tuesday, February 7, 2017 at 12:16:24 PM UTC-6, woodb...@gmail.com wrote:
> On Tuesday, February 7, 2017 at 11:22:22 AM UTC-6, woodb...@gmail.com wrote:
> > On Tuesday, February 7, 2017 at 1:13:34 AM UTC-6, Juha Nieminen wrote:
> > > Christiano <chris...@engineer.com> wrote:
> > > > I come from the C language. I have the impression that in C ++ the ideal
> > > > is "C ++ header only" libraries.
> > >
> > > Where did you get that impression? I have never heard of such an ideal.
> > >
> > > Many libraries with heavy use of templates may be header-only, mostly
> > > because of necessity. Some non-template libraries may also be header-only,
> > > but there seldom is any good reason for it (unless the library is really
> > > small),
> >
> > The nature of the library and how it is (typically) used might be
> > a factor also. My generated messaging and marshalling libraries
> > are header-only. In my experience, the functions in the libraries
> > are usually called once by an application. There's an exception to
> s/once/in one place/
>
> > that where a message that conveys error information is called 3 times
> s/times/places/
>
> > in one app. This thread got me thinking about my use of header-only
> > libraries so I checked how much difference it would make size-wise if
> > that function was in a .cc file. Doing so reduced the size of the
> > application's text segment by 128 bytes.

Since writing this I realized I could achieve the same effect
by not emitting the "inline" keyword in the generated header.
So I added support for an @no_inline option to my code
generator. A few days ago I thought I was going to have to
leave those 128 bytes on the table, as a tradeoff for the
convenience of having a header-only library. This allows me
to snag those bytes and keep the convenience. I only need
to include the generated header in one translation unit so
can get away with removing that inline.

https://github.com/Ebenezer-group/onwards/commit/27951bcf9594b6cf9e0a5b514a2fdced17a5f6b1

[Christiano]

On Thu, 02 Feb 2017 19:11:21 +0000, Christiano wrote:

> I come from the C language. I have the impression that in C ++ the ideal

> is "C ++ header only" libraries. See Boost, the most important set of

> libraries is a clear example of this.But this is very clearly opposite
> to the C world where if someone write body code definitions in headers is
> considered someone who is learning, a beginner making mistakes. The
> separation between definition and statement is very clear.
>

> Books like K & R, Mastering Algorithms, use a separation, which is the
> natural way of thinking of C. In fact whenever I used libraries made in C,
> I never saw anything that was "header-only".
>

> So, what's the point? Why in C ++ is this way?

I know that this question is a little old, but I found this page in the
stroutrup's book ( ISBN-13: 978-0321992789 ) very relevant and I decided
to do a scan and post here:

http://imgur.com/FPkvQ91

[Alf P. Steinbach]

Oh goodie. But it's best to post /pure text/, and to not refer to
storage elsewhere: that Imgur image will probably disappear in a few
weeks or months, while these Usenet postings will continue to be
archived by various services, including by Google Groups. So that end, I

(1) googled "online ocr",
(2) clicked the first result,
(3) uploaded your image,
(4) downloaded the resulting Word file,
(5) copied the relevant text over to Notepad++ and replaced tabs with
spaces, as well as adding blank lines between paragraphs,

resulting in


<quote>
Writing the definition of a member function within the class definition
has three effects:

• The function will be inline; that is, the compiler will try to
generate code for the function at each point of call rather than using
function-call in¬structions to use common code. This can be a
significant performance advantage for functions, such as month(), that
hardly do anything but are used a lot.

• All uses of the class will have to be recompiled whenever we make a
change to the body of an inlined function. If the function body is out
of the class declaration, recompilation of users is needed only when the
class declaration is itself changed. Not recompiling when the body is
changed can be a huge advantage in large programs.

• The class definition gets larger. Consequently, it can be harder to
find the members among the member function definitions.

The obvious rule of thumb is: Don't put member function bodies in the
class declaration unless you know that you need the performance boost
from inlining tiny functions. Large functions, say five or more lines of
code, don't benefit from inlining and make a class declaration harder to
read. We rarely inline a function that consists of more than one or two
expressions
</quote>


Bjarne Stroustrup is over-simplifying a bit here, for the novice audience.

I think that as language creator we can be assured that he knows better
than to assert what the compiler will do with the `inline` hint.

It's worth noting that this page, in particular the part with a
rectangle around it quoted here, is not about header only modules but
about how to structure a class definition so as to make it *clear*.

Even for a class definition in a header for a conventional separately
compiled module, it can make sense to have some short member functions
inline in the class.

For example, a public short function can check preconditions and
postconditions, but delegate the main work to a private virtual function
that can be arbitrarily complex, possibly with some transformation of
the argument(s). The short public wrapper's body is then part of the
class' public interface. And that body is not subject to change unless
the class interface is changed, in which case recompilation is needed
anyway.


Cheers!, & sorry for mailing this by mistake,

- Alf

[woodb...@gmail.com]

I hope you wrote to the author and publisher and got their
permission to post that.


Brian

[Scott Lurndal]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>On 13.02.2017 21:06, Christiano wrote:

><quote>
>Writing the definition of a member function within the class definition
>has three effects:
>
>• The function will be inline; that is, the compiler will try to
>generate code for the function at each point of call rather than using
>function-call in¬structions to use common code. This can be a
>significant performance advantage for functions, such as month(), that
>hardly do anything but are used a lot.
>
>• All uses of the class will have to be recompiled whenever we make a
>change to the body of an inlined function. If the function body is out
>of the class declaration, recompilation of users is needed only when the
>class declaration is itself changed. Not recompiling when the body is
>changed can be a huge advantage in large programs.
>
>• The class definition gets larger. Consequently, it can be harder to
>find the members among the member function definitions.

And this is the key argument!

>
>The obvious rule of thumb is: Don't put member function bodies in the
>class declaration unless you know that you need the performance boost
>from inlining tiny functions. Large functions, say five or more lines of
>code, don't benefit from inlining and make a class declaration harder to
>read. We rarely inline a function that consists of more than one or two
>expressions
></quote>

Actually, it's been the practice of projects that I've worked on
since 1989 to not put member function bodies in the class declaration
_even if they should be inline_, but rather to place the member
function bodies following the class declaration in the same header file
using the 'inline' keyword.

[Wouter van Ooijen]

Op 14-Feb-17 om 14:43 schreef Scott Lurndal:

> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> On 13.02.2017 21:06, Christiano wrote:
>
>> <quote>
>> Writing the definition of a member function within the class definition
>> has three effects:
>>

>> • The function will be inline; that is, the compiler will try to

>> generate code for the function at each point of call rather than using

>> function-call in¬structions to use common code. This can be a

>> significant performance advantage for functions, such as month(), that
>> hardly do anything but are used a lot.
>>

>> • All uses of the class will have to be recompiled whenever we make a

>> change to the body of an inlined function. If the function body is out
>> of the class declaration, recompilation of users is needed only when the
>> class declaration is itself changed. Not recompiling when the body is
>> changed can be a huge advantage in large programs.
>>

>> • The class definition gets larger. Consequently, it can be harder to

>> find the members among the member function definitions.
>
> And this is the key argument!

Yes, way back when the source was the interface documentation. Nowadays
we have documentation generators (extracter/formatters would be a better
term) that generate something that is much better readable, so that key
argument is no longer valid.

In my experience (but YMMV) I find the code *more* readable when the
implementation is in the header file.

[Tim Rentsch]

I believe it would be allowed under the "Fair use" doctrine.
(Needless to say IANAL.)

[Juha Nieminen]

Tim Rentsch <t...@alumni.caltech.edu> wrote:
> I believe it would be allowed under the "Fair use" doctrine.
> (Needless to say IANAL.)

Maybe if you are making a commentary or review on it.
Just copypasting significant portions of the text does not
fall under fair use.

[Scott Lurndal]

"Examples of fair use in United States copyright law include
commentary, search engines, criticism, parody, news reporting,
research, and scholarship."

https://www.copyright.gov/fair-use/more-info.html

[David Brown]

Does the USA definition of fair use apply when published to an
international newsgroup? The source of the copyrighted material may be
in the USA, but "fair use" varies between countries.

[Tim Rentsch]

If you look into the question more fully I think you will
find (a) that there are other factors that bear on the issue
besides the ones you listed, and (b) that the lines between
what is allowed and what is not allowed (ie, under "fair
use") are fuzzy rather than sharp. Here though my best
understanding is that this case is pretty clearcut.

Like I said, IANAL. Feel free to draw your own conclusions.

[woodb...@gmail.com]

Due in part to a lack of spirit that says, "What's yours
is yours and what's mine is yours," I'm afraid it's
increasingly difficult to make money as a book author.
Thankfully, Providence has given on line services as a
way to rescue a few from a flood of immorality. "We few,
we happy few."


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Chris Vine]

On Mon, 20 Feb 2017 08:17:31 -0800 (PST)
woodb...@gmail.com wrote:
> On Saturday, February 18, 2017 at 10:06:32 AM UTC-6, Tim Rentsch
> wrote:

[snip]

> > If you look into the question more fully I think you will
> > find (a) that there are other factors that bear on the issue
> > besides the ones you listed, and (b) that the lines between
> > what is allowed and what is not allowed (ie, under "fair
> > use") are fuzzy rather than sharp. Here though my best
> > understanding is that this case is pretty clearcut.
>
> Due in part to a lack of spirit that says, "What's yours
> is yours and what's mine is yours," I'm afraid it's
> increasingly difficult to make money as a book author.
> Thankfully, Providence has given on line services as a
> way to rescue a few from a flood of immorality. "We few,
> we happy few."

Tim makes a perfectly reasonable response about fair use; and you
respond with irrelevant self-absorbed crap to parade your moral
superiority. Please stop it.

[Tim Rentsch]

woodb...@gmail.com writes:

> On Saturday, February 18, 2017 at 10:06:32 AM UTC-6, Tim Rentsch wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>> Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>>> I believe it would be allowed under the "Fair use" doctrine.
>>>> (Needless to say IANAL.)
>>>
>>> Maybe if you are making a commentary or review on it.
>>> Just copypasting significant portions of the text does not
>>> fall under fair use.
>>
>> If you look into the question more fully I think you will
>> find (a) that there are other factors that bear on the issue
>> besides the ones you listed, and (b) that the lines between
>> what is allowed and what is not allowed (ie, under "fair
>> use") are fuzzy rather than sharp. Here though my best
>> understanding is that this case is pretty clearcut.
>

> [...] I'm afraid it's increasingly difficult to make money as a
> book author. [...]

That's part of the reason I think a "Fair use" exception would be
allowed. The single page made available is unlikely to cause
someone who wants to buy the book not to buy it, but it might
very well convince some people to buy the book who would not have
otherwise. From the author's point of view, the page being
posted is pretty much all free advertsing, with negligible
downside.

[woodb...@gmail.com]

Authors and publishers often give free access to a few pages
of their books. An individual giving away additional pages
is making a higher percentage of the book available for free.
Some people won't buy the cow when they can get the milk for free.

http://nypost.com/2017/02/24/150k-supercar-stolen-during-test-drive/

At some point, the higher percentage that's free the less likely
people are to pay for it. I'm thankful I don't need to make a
living as a traditional author.