From: Peter C. Chapin on
On 2010-07-27 10:42, Timothy Madden wrote:

> It is a useful feature. Separating declaration from implementation is
> good practice that all programmers should follow.

I agree with this. I don't like visually cluttering specification with
implementation. Even if there were no other benefits, I would see
separating those things as a desirable feature of export. On the other
hand I understand that there is a cost/benefits ratio to consider here.
For example even now it is possible to declare templates in one part of
a (header) file and then provide their implementations in a later part
of that file. One can put a big bold comment block across the middle of
the file that says, in effect, "Below are implementation details."

Peter

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Timothy Madden wrote:
> Walter Bright wrote:
>>> If the compiler can get some form of speed benefit with that, which is
>>> likely, that would be great.
>>> I should say here that pre-parsed templates might compile faster than
>>> plain source code templates included everywhere. Pre-parsed templates,
>>> although not fully compiled like object code, are still half-compiled
>>> and that will help with speed.
>>
>> It doesn't work out that way in practice, though, for various reasons
>> - precompiled headers are a far simpler feature and deliver actual
>> speedups.
>
> Exported templates also benefit from pre-compiled headers,

Not in a way that makes (exported templates + precompiled headers) faster at
compiling than (precompiled headers).

> and a lot, as symbol tables is what they work with.

Don't get me wrong, I'm not criticizing you for being enthusiastic about this
feature and thinking it will work. Often times, fundamental advancements are
made by people who reject the conventional wisdom and find a way. The source
code is available for many C++ compilers, including g++ and Digital Mars C++.
Feel free to organize some like-minded developers and try out your ideas.

> So maybe export should be optional. If you do not want to touch the area, you
> have no need to. Would that be acceptable for compiler writers ?

Not for me. I don't care for wishy-washy standards with optional features.
Furthermore, if making it a required feature didn't get it adopted, making it
optional isn't going to make it more palatable.

The best way forward for you is to develop this feature yourself, and prove it
works, delivers real benefits and has a sizable constituency, then take it to
the Committee with an incorporation proposal.

The "I think it will work, let's standardize it and hope for the best" approach
has already been tried and failed.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Peter C. Chapin on
On 2010-07-27 17:39, Andre Kaufmann wrote:

> What's the real benefit of using multiple files for code which makes up
> a single code module - did I miss something ?

It separates design from implementation. When I'm designing a program I
can work in the header files... organize the namespaces, define the
classes and their relationships (along with their methods), and declare
necessary supporting functions. I can do all of this without thinking
about implementation details or writing one line of code into a .cpp file.

Once my design is somewhat in hand I can then start building the
implementation (the .cpp files). Separating a module into two files
encourages me to separate design and implementation in my mind. I find
this very beneficial. Of course the separation isn't perfect because the
private part of classes is implementation material. Still, I find it far
better than, for example, Java where design and implementation are
co-mingled in a single file and sometimes hard to separate mentally
(without using an unnatural style anyway).

In Ada one can even separately compile package specifications (it's not
necessary for the bodies to be present). This allows the compiler to
perform some consistency checks on my design before I even start writing
the implementation. I have often found significant design errors this
way. I think it's a great way to work.

Peter

P.S. When Ada was first being designed some thought was given to the
idea of using *three* files for each package: the public specification,
the body, and the private part of the specification. The last file would
contain the material the compiler needed to know to compile clients of a
package but that was logically part of the implementation. This would
have created a very clean separation of design and implementation and I
rather wish the language had done that. Apparently it was decided at the
time that people would find it just too tedious.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on
On 07/27/2010 11:39 PM, Andre Kaufmann wrote:
[snip]
>
> What's the real benefit of using multiple files for code which makes up
> a single code module - did I miss something ?

Because I want to look at some library's header file and see only things
that I need for using the library. And I like it more if it is human
written, with comments and with functions and other entities ordered
maybe by usage or some other logic and not by their names...
such things... Least of all would I want to see the implementation.
Even the representation and private: stuff is already way too much.

This applies even when I am developing the same library...
Sometimes I just want to see (and change) the interface.
Then later maybe I dedicate my time to the implementation.

And if the maintenance of two files requires too much effort,
then I would argue that their interfaces became fat and need
refactoring...

This was my argument against putting it all in one file,
not generally against modules. Find a way to put private
stuff away and I'm all ears... :-)

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andre Kaufmann on
Walter Bright wrote:
> Dragan Milenkovic wrote:
> [...]
> 1. fast compilation - yes
> 2. no need to write header files - yes
> 3. implementation obfuscation - no
> 4. hygiene - yes
>
> (3) is not, in my opinion, a solvable problem because the compiler
> needs, one
> way or another, far too much information about the template definition
> to hope
> one could conceal it from a determined user.

I don't know why it's a must to be able to obfuscate the implementation.
In Open Source code it doesn't matter and in commercial libraries /
components it's rather a sales argument to ship the sources too, to be
able to fix bugs / debug / or use another compiler, since theres no ABI
compatibility between different compilers.

And if you want to hide secret knowledge, it's IMHO only an illusion
that this information can be hidden by obfuscation / compilation.


Anyways, obfuscation IMHO could be reached by:

a) Simple code reformat obfuscators: Replace every internal variables
and functions by a single character. Remove carriage returns etc.
- the code is then hardly readable and not usable, besides it's
normal usage as a library

b) Precompilation - the compiler could use a binary format, which can
be compiled as normal source code too.
Same as a) but a bit more obfuscated

Andre

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]