Hello

Re-reading the thread I realise that the inclusion model is very similar to
what I was proposing, with the template code being protected by encryption.
The encryption exists only to enforce this protection, nothing else. It was
my opinion that this was the main 'use' of the export template. Stroustrup
suggests the use of export as a method of eliminating accidental
dependancies (13.7 C++ P.L.), which admittadly I do not think my suggestion
solves.

"Daveed Vandevoorde" <google@vandevoorde.com> wrote in message
news:52f2f9cd.0202081428.785bb012@posting.google.com...

> // File templ.c:
> static int call_count = 0;
>
> export template<typename T> void f(T x) {
>    ++call_count;
>    g(x);
> }
>
> // File main.c:
> export template<typename T> void f(T x);
>
> void g(x) {}
>
> int main() {
>    g(3);
> }
>
> Can you walk me through a slightly more detailed explanation
> of your proposed scheme.  Do I encrypt all of templ.c or just
> the body of its templates?  In either case, I assume I should
> decrypt it when I compile main.c?  What happens when it is
> decrypted?

In this case I would assume also an additional templ.h, prototyping the
template function. This would expose any dependancies. The templ.c would be
encrypted and distributable, similar to a library file. At compilation time
it would be decrypted and treated exactly as if it had been originally
#include'd. Although in Stroustrups example he places the template code into
a .c/.cpp file, and #include's this, I think this adding of one .c/.cpp into
another is poor form, and error prone. I prefer to make template code bodies
more explicit, and use the .inl suffix (this is purely a style issue).

Cheers,
D   ire Stockale









---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a43gup$kfv$1@news6.svr.pol.co.uk>,
Solosnake <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
>The encryption is simply 'hiding' the normal templated code body. It is
>treated by the compiler (after decryption) exactly as it would have been had
>it been a valid non-exported template. A valid difficulty is that the
>decrypted file/exported template definition is not #include'd anywhere. As
>the template definition is now being treated in a similar fashion to a
>'.cpp' file, I do not think it would be difficult for a compiler to find the
>matching template body for the given declaration.

Whether it's encrypted or not, the body still needs to be located
(among other things).   This is like saying that encryption
would help inlining _across_ source files, but it's really
a seperate issue than solving the immediate problem.
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote in message news:a3pol2$ve4$1@newsg3.svr.pol.co.uk...

> The standard does not apply to their description. Would it not be possible
> to implement a form of 'export' via encryption of the template code?

Short answer: no.

> For all
> extents and purposes the encrypted file (which naturally the compiler can
> decrypt to use)

That way I'd not call it 'encryption' but obfuscation.
Obfuscation never works. Not agauinst anyone willing to read your code. It would take about a week until you can download a 'template decryptor' from internet, so you would not achieve anythng, just put in some work.

Also, I think the intention of having export is not the code hiding for copyright or similar reasons, and encryption, even if someone could summon a working scheme, does not address those at all.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
> Hello
>
> Re-reading the thread I realise that the inclusion model is very similar to
> what I was proposing, with the template code being protected by encryption.

Indeed.

> The encryption exists only to enforce this protection, nothing else. It was
> my opinion that this was the main 'use' of the export template. Stroustrup
> suggests the use of export as a method of eliminating accidental
> dependancies (13.7 C++ P.L.), which admittadly I do not think my suggestion
> solves.

(Unfortunately, I don't think the separation model (i.e., export)
solves that problem either.)

> "Daveed Vandevoorde" <google@vandevoorde.com> wrote in message
> news:52f2f9cd.0202081428.785bb012@posting.google.com...
>
> > // File templ.c:
> > static int call_count = 0;
> >
> > export template<typename T> void f(T x) {
> >    ++call_count;
> >    g(x);
> > }
> >
> > // File main.c:
> > export template<typename T> void f(T x);
> >
> > void g(x) {}
> >
> > int main() {
> >    g(3);
> > }
> >
> > Can you walk me through a slightly more detailed explanation
> > of your proposed scheme.  Do I encrypt all of templ.c or just
> > the body of its templates?  In either case, I assume I should
> > decrypt it when I compile main.c?  What happens when it is
> > decrypted?
>
> In this case I would assume also an additional templ.h, prototyping the
> template function. This would expose any dependancies. The templ.c would be
> encrypted and distributable, similar to a library file. At compilation time
> it would be decrypted and treated exactly as if it had been originally
> #include'd. Although in Stroustrups example he places the template code into
> a .c/.cpp file, and #include's this, I think this adding of one .c/.cpp into
> another is poor form, and error prone. I prefer to make template code bodies
> more explicit, and use the .inl suffix (this is purely a style issue).

You've almost reinvented the Cfront model, except you add
encryption.  My personal preference is to avoid implicit
inclusions.  However, as I mentioned in an earlier posting
your scheme could also be associated with:

 #include "templ.inl"  // Following your convention

where the compiler would recognize that only an encrypted
version of "templ.inl" is available and decrypt that as
needed.  That more general approach also takes care of some
developer's desire to hide inline function bodies as well
as private class type interfaces.

There are some downsides (some mentioned earlier):
   . How do we report diagnostics involving entities
     declared inside the encrypted header?  Quoting
     parts of the header defeats the purpose of the
     encryption and may not be sufficient.  Referring
     to line numbers in the encrypted header is useless.
   . Eventually someone is going to break the encryption
     since a binary of the decoder is present in the
     compiler.
   . Any option to produce preprocessed output must be
     disabled (e.g., -E on many compilers in Unix-like
     environments).  That makes it much harder to
     reproduce problems when communicating between
     users and implementors.

As I mentioned earlier, I believe Sun used a somewhat
similar technique for a version of their compiler.  It
would be interesting to hear from them why they no longer
do it that way.

Incidentally, the diagnostic problem also constrains the
export model.

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a3tmhs$mki$1@newsg4.svr.pol.co.uk>, Solosnake
<solosnake@solosnake.without_this.freeserve.co.uk> writes
>What other reasons do you think drive the desire for 'export'? I doubt any
>implementation can be linked to directly, but will in fact be a further
>abstraction of the template, a machine friendly synthax.

I do not think that it is productive to explore too much history, but
export was introduced as a technical fix to a political problem (the
closest we ever came to complete breakdown in producing the standard).
In the event, perhaps it will prove to be more of a political fix but I
am willing to wait and see.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
> I suspect that this post will irritate the purists and compiler writers,

Why do you think so?

> however I post it only as a suggestion, a thought exercise, and to stimulate
> some debate.
>
> I have read with interest the frequent posts about the difficulty of
> implementing the export keyword, and also arguments about the usefulness and
> intentions behind the keyword. I can understand the difficulty in
> 'compiling' a template .cpp file, and as far as I understand the main reason
> most people desire the 'export' is for copyright protection of their code.
> As much of the code I write is template based, I too would like the privacy
> of 'export'.

Well, "implementation privacy" and "export" are quasi-orthogonal
issues really.  See below.

> As far as I know, .lib files are compiler specific: my VC++ .lib files will
> not function with my Borland .lib files, although the header files might.
> The standard does not apply to their description. Would it not be possible
> to implement a form of 'export' via encryption of the template code? For all
> extents and purposes the encrypted file (which naturally the compiler can
> decrypt to use) can be considered to be an 'exported' template unit.
> Arguments that the file could be deciphered are possibly true, however it is
> equally possible to reverse-engineer software, and your compiled code is not
> guaranteed safe.

I'm reading that as equating "a form of export" with "template
implementations are not visible as plain text" which I would find
misleading terminology.

However, what you propose is entirely feasible both with the inclusion
model and the export model.  In fact, I believe Sun at some point did
something like it for their standard C++ library (using the inclusion
model).

For example, using the inclusion model an implementation could decide
that every time it encounters
 #include X
it would not only look up X in the usual places, but also in associated
places (e.g. BinHeader/X).  Note that this is not even specific to
templates; it can also e.g. hide inline function implementations and
private interfaces.

Implementations of the separation (export) model could use similar
techniques (if they keep a source version of the implementation at
all).

In any of these model, however, a (small) challenge that arises is the
handling of diagnostics.  Often template instantiation errors point to
the implementation of the template to clarify why the instantiation
failed.  If the implementation cannot be revealed, the use of templates
would be (even) more difficult.

 Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Daveed Vandevoorde" <google@vandevoorde.com> wrote in message
news:52f2f9cd.0202061532.d40b730@posting.google.com...
> "Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
> > I suspect that this post will irritate the purists and compiler writers,
>
> Why do you think so?

I wrote this because I suspected that the implementation of export
presented compiler writers with a difficult challenge, one that they would
rather overcome using standard methods, as opposed to my suggestion,
which simply 'appears' to implement compilation. The end user would not be
able to tell the difference between the two methods though.


> >Would it not be possible
> > to implement a form of 'export' via encryption of the template code?
>
> I'm reading that as equating "a form of export" with "template
> implementations are not visible as plain text" which I would find
> misleading terminology.

Perhaps it is misleading, however I am merely spelling out how the compiler
might implement the exporting. In fact this form of export might be entirely
compliant with the standard, and almost trivial to implement.Would you feel
unhappy if a compiler which offered the export feature merely encrypted your
template code body as opposed to really compiling it? How would you ever
know the difference?

Thanks,
D   ire Stockdale












---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote :
> "Daveed Vandevoorde" <google@vandevoorde.com> wrote:
> > "Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
> > > I suspect that this post will irritate the purists and compiler writers,
> >
> > Why do you think so?
>
> I wrote this because I suspected that the implementation of export
> presented compiler writers with a difficult challenge, one that they would
> rather overcome using standard methods, as opposed to my suggestion,
> which simply 'appears' to implement compilation. The end user would not be
> able to tell the difference between the two methods though.

I'm quite sure they would.  Independently of how the sources are
fed, the name binding ends up being different.  What is hindering
implementors is not the packaging aspect, but the semantics of
"export".

> > >Would it not be possible
> > > to implement a form of 'export' via encryption of the template code?
> >
> > I'm reading that as equating "a form of export" with "template
> > implementations are not visible as plain text" which I would find
> > misleading terminology.
>
> Perhaps it is misleading, however I am merely spelling out how the compiler
> might implement the exporting. In fact this form of export might be entirely
> compliant with the standard,

As I mentioned in the unquoted part of my post: the two issues
are orthogonal.

> and almost trivial to implement.Would you feel
> unhappy if a compiler which offered the export feature merely encrypted your
> template code body as opposed to really compiling it? How would you ever
> know the difference?

I think you're leaving out the part that is hard.

For the sake of argument, let's work through a tiny example:

 // File templ.c:
 static int call_count = 0;

 export template<typename T> void f(T x) {
    ++call_count;
    g(x);
 }

 // File main.c:
 export template<typename T> void f(T x);

 void g(x) {}

 int main() {
    g(3);
 }

Can you walk me through a slightly more detailed explanation
of your proposed scheme.  Do I encrypt all of templ.c or just
the body of its templates?  In either case, I assume I should
decrypt it when I compile main.c?  What happens when it is
decrypted?

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a3vsum$hm$1@newsg2.svr.pol.co.uk>,
Solosnake <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
>Would you feel
>unhappy if a compiler which offered the export feature merely encrypted your
>template code body as opposed to really compiling it? How would you ever
>know the difference?

I'm not following this.  export is not about encrypting, but
about encapsulation.  And an implementation may choose to
use encrypting in its solution, but certainly that's only
one part of the implementation of export.
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hello

The encryption is simply 'hiding' the normal templated code body. It is
treated by the compiler (after decryption) exactly as it would have been had
it been a valid non-exported template. A valid difficulty is that the
decrypted file/exported template definition is not #include'd anywhere. As
the template definition is now being treated in a similar fashion to a
'.cpp' file, I do not think it would be difficult for a compiler to find the
matching template body for the given declaration.

Cheers,

D   ire Stockdale







---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote in
message news:a3pol2$ve4$1@newsg3.svr.pol.co.uk...
> As far as I know, .lib files are compiler specific: my VC++ .lib files
will
> not function with my Borland .lib files, although the header files might.
> The standard does not apply to their description. Would it not be possible
> to implement a form of 'export' via encryption of the template code? For
all
> extents and purposes the encrypted file (which naturally the compiler can
> decrypt to use) can be considered to be an 'exported' template unit.
> Arguments that the file could be deciphered are possibly true, however it
is
> equally possible to reverse-engineer software, and your compiled code is
not
> guaranteed safe.

Reverse engineering software is relatively hard, and reverse engineering one
piece of software doesn't get you anything with another.  With encryption,
breaking it once breaks it for all, then there's no effort to decrypt
others.

Additionally, the decryption key must be included in the compiler.  This has
many effects, first, it makes retrieving the key much easier, even if it is
obfuscated and hidden (and someone trying to break it could pick the least
obfuscated of the compilers).  Second, and more damning, you can't have an
open source compiler, because if the open source compiler has the decryption
key, it can be modified trivially to supply the unencrypted source.  In
fact, no one without some sort of clearance to have a key would be able to
work on the source of any compiler, and some group would have to provide,
facilitate, and police that clearance.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Ken Alverson" <Ken@Alverson.com> wrote in message
news:a3q365$9sj$1@eeyore.INS.cwru.edu...
> "Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote in
> message news:a3pol2$ve4$1@newsg3.svr.pol.co.uk...
> > Would it not be possible
> > to implement a form of 'export' via encryption of the template code?
>
> Reverse engineering software is relatively hard, and reverse engineering
one
> piece of software doesn't get you anything with another.  With encryption,
> breaking it once breaks it for all, then there's no effort to decrypt
> others.
>
> Additionally, the decryption key must be included in the compiler.  This
has
> many effects, first, it makes retrieving the key much easier, even if it
is
> obfuscated and hidden (and someone trying to break it could pick the least
> obfuscated of the compilers).  Second, and more damning, you can't have an
> open source compiler, because if the open source compiler has the
decryption
> key, it can be modified trivially to supply the unencrypted source.  In
> fact, no one without some sort of clearance to have a key would be able to
> work on the source of any compiler, and some group would have to provide,
> facilitate, and police that clearance.

It's all true.  It's also probably true (IMO) that any implementation will
store something not far removed from the source code in some sort of "export
file".  It probably won't be encrypted source code - more likely some kind
of annotated AST.  Nevertheless, it'll have to be so close to source code
that working, while perhaps not identical, source code could probably be
produced from such an export file.   Just look at the reverse engineering
tools available for Java...

-cd


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a3pol2$ve4$1@newsg3.svr.pol.co.uk>,
Solosnake <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
>as far as I understand the main reason
>most people desire the 'export' is for copyright protection of their code.

I do not believe this to be the main reason.
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:a3rhoe$4ng$1@panix3.panix.com...
> In article <a3pol2$ve4$1@newsg3.svr.pol.co.uk>,
> Solosnake <solosnake@solosnake.without_this.freeserve.co.uk> wrote:
> >as far as I understand the main reason
> >most people desire the 'export' is for copyright protection of their
code.
>
> I do not believe this to be the main reason.

What other reasons do you think drive the desire for 'export'? I doubt any
implementation can be linked to directly, but will in fact be a further
abstraction of the template, a machine friendly synthax.

D   ire Stockdale


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hello

I suspect that this post will irritate the purists and compiler writers,
however I post it only as a suggestion, a thought exercise, and to stimulate
some debate.

I have read with interest the frequent posts about the difficulty of
implementing the export keyword, and also arguments about the usefulness and
intentions behind the keyword. I can understand the difficulty in
'compiling' a template .cpp file, and as far as I understand the main reason
most people desire the 'export' is for copyright protection of their code.
As much of the code I write is template based, I too would like the privacy
of 'export'.

As far as I know, .lib files are compiler specific: my VC++ .lib files will
not function with my Borland .lib files, although the header files might.
The standard does not apply to their description. Would it not be possible
to implement a form of 'export' via encryption of the template code? For all
extents and purposes the encrypted file (which naturally the compiler can
decrypt to use) can be considered to be an 'exported' template unit.
Arguments that the file could be deciphered are possibly true, however it is
equally possible to reverse-engineer software, and your compiled code is not
guaranteed safe.

Interested to hear all counter arguments,

D   ire Stockdale






---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]