Do C++ Programmers Overuse Templates?

[tonytech08]

The story of C/C++ is about building something on top of something
else: C -> C++ -> STL -> boost

Perhaps you said that just right by calling it a "story". As in past-
tense/history/lessons-learned/experimentation/over-innovation. Just a
few months ago, I found on the net something claiming to be a
"fantabulous new GUI library". Guess what? Everything was a template.
Perhaps even all the source code was in header files as a template! To
each his/her own, but I'm not going to use such a thing. To me, that
is OVERUSING templates. It has a feel of doing HTML or XML (or
remember all those MS macros? ATL?) level stuff rather than real
programming. Sometimes I think people forget that useful software has
been written in C, rather than just word-counting programs of K&R.

Others also added some big and complicated librarys (partly on top
and partly in parallel): Win32, TurboC librarys, .NET and others.
In the end complexity is built on top of complexity.

I disagree. In the end, complexity fails. The current state is just a
stepping stone. Experimentation.

Not everything is suited to be used as base to build something on
top.

I view templates like that. Perhaps because I have programmed having a
macro preprocessor (a LAME one) at my disposal. Perhaps if
indoctrinating new programmers to programming where a preprocessor
doesn't exist in the environment, then templates become more
miraculous. Granted, I'm not coding nuclear physicist equations (or
whatever analogy would apply that would make the less esoteric
template techniques a must have).

 

[tonytech08]

C has good basic concepts but as it can be seen at the complexities
of its descendants not all this concepts are ideal to build a
tower on them.

That of course is a non sequitor: and a particularly obvious one. You
are suggesting that because C++ (and other) languages came after C and
are complex, that surely THEY must be the ones to be built upon. If
you are suggesting the tower of babel, I'm sure it is a tower of
complexity rather than of simple elegance. ("Crushed under it's own
weight", comes to mind).

 

[Vidar Hasfjord]

[...]
Can I memmove tr1 arrays around in memory?
Yes.

http://www.ddj.com/cpp/184402052

[...]

So do tr1 arrays put objects (say, for example, structs) in
continguous memory?
Yes.

[associative tuples]

Begs the question: what's the point of doing that?

Introspection is one motivation. See Boost.Fusion.

[...]
(That may be an
archaic viewpoint, but I don't see any better way of doing that close
to the hardware type of programming. When you get away from structs
and primitives (built-ins), that to me makes it NOT a close-to-the-
hardware language. Whether that level of programming is required
outside of things like device drivers and OSes may be relevant. It is
my programming model though even at the application level.)

You should do what is most productive for you, of course. But while
you clearly prefer to think "close to the hardware", I prefer and
recommend higher-level and safer abstractions; e.g. std::string
instead of C-style strings, tr1::array instead of C-style arrays etc.
With a fairly good understanding of how an abstraction is implemented,
you need not feel removed from the hardware.

[...] Of course I
will avoid stuff way more often then the typical C++ user, but then I
hope to move my codebase to my own (read in-house) language someday.

Ah, that helps explain your viewpoint. Good luck!

Regards,
Vidar Hasfjord

 

[Guest]

Good point, but the caveat is more important: don't use that stuff
just because you know it. Use it only when you have to. Otherwise,
avoid it. Usage of C++ techniques is "underspecified". Of course I
will avoid stuff way more often then the typical C++ user, but then I
hope to move my codebase to my own (read in-house) language someday

does this in-house language exist? Could you be coding in it now?
Might you be better off writing the translator for IHL than the
application?

I can see why you might want to limit the use of certain of C++
features. Maybe your C++ could be mechanically translated into IHL.

 

[James Kanze]

[...]

Can I memmove tr1 arrays around in memory?

You can't do that with C style arrays, in C++. And why would
you want to?

So do tr1 arrays put objects (say, for example, structs) in
continguous memory?

Formally, they are an agglomerate, allowing agglomerate
initialization (including static initialization if the instance
type allows it). (I think that they're even a POD if the
instance type is a POD.)

 

[tonytech08]

    [...]

Can I memmove tr1 arrays around in memory?

You can't do that with C style arrays, in C++.  And why would
you want to?

I'm close to the hardware, you are not. Get off my case. I do stuff
with memory, thats pretty much all I do. You start telling me I can't
do that, I'll call you hitler.


l

 

[Rüdiger Ranft]

I don't believe it. Indeed, isn't, say, the Java VM basically an
abstraction of common machine instructions (or similar that works on
bytecode)?

No, Java defines a virtual environment with their own instructions. The
VM either interprets these instructions, or compiles them into native
code. But the bytecode is not some subset of all different processor
instructions where Java is meant to run, the bytecode is an abstract
format to store program code. It even contains very abstract
instructions like instanceof which are very special to Java and
therefore not implemented in typical processors[1].
There is no common subset of instructions because the existing
processor architectures are to different. There are RISC and CISC
Machines, some have 2 address instructions, others have 3 address
instructions. You can have machines with saturation aritmetic, SIMD
instructions or operand stacks. Some of them have pointers to singe bits
while others have no pointers at all. And this list is far away from
being complete.
Even the easiest instruction of all, NOP, does not exist on all
processors, because in some environments it makes no sense.

bye
Rudi

[1]http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc6.html#instanceof

 

[Jerry Coffin]

I don't have a patent on "it" yet.

That doesn't matter. You have one year after inventing it to apply for a
patent. Publishing "it" during that year does not raise any bar to
patenting (at least under US law). In fact, publishing it prevents
anybody else from getting a patent on it, even if they weren't aware of
the publication. The applicable law (in the US) is 35 US code, section
102, especially 102(a) and 102(b).

 

[Matthias Buelow]

Perhaps if
indoctrinating new programmers to programming where a preprocessor
doesn't exist in the environment, then templates become more
miraculous.

Templates are _compiler macros_, not preprocessor text-substitution
macros. Completely different thing.

Templates are useful to some extent (in C++) but they're also headache
inducing, for example concerning:

* compiler error messages: a small error, and you might over a hundred
lines of barely intelligible gibberish hurled at you, and your only hope
is scanning through the mess trying to spot where the error might be
(with some practice, this becomes quite possible, although still tedious
and frustrating),

* debugging: I use gdb, which has sketchy C++ support at best but once
you venture into template-land, you could just aswell strangle yourself
with piano wire for all the hope that is left by then.

The main problem is that templates, like most of C++' advanced
"features", aren't first-order entities that can be inspected and
manipulated through the language itself, which makes debugging and
reasoning about them really hard.

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

I'd have to read the entire patent to be sure, and even then,
I'm not a patent lawyer. Still, the first sentence of the
abstract says it concerns a "process". The real question then
becomes: what is a process, and what is an algorithm. The fact
that the patent seems to talk about input and output formats
suggests that it is more than an algorithm. (On the other hand,
one might seriously question the novelty or originality. Off
hand, it looks to me that what is being patented is the use of a
program to convert between two formats. Which isn't what I'd
consider a particularly novel or original idea. But from what
I've read, the patent office in the US doesn't really have the
means of verifying such claims, and counts on the applicant
being honest and providing full and detailed "existing
practice".)

The line between what's patentable and what's not ("Statuatory subject
matter") is fine and has been argued repeatedly over the years. In the
US, the Court of Appeals for the Federal Circuit recently handed down a
decision in the "Re: Bilski" case that (at least for the moment) made a
rule that to be valid, the patent has to be drawn to either a
transformation of matter, or the use of a "specific apparatus". As such,
the patent cited previously, along with quite a few others, may well be
invalid, unless a specific mechanism is required for its implementation
-- and chances are that "digital computer" won't qualify as the specific
apparatus, at least in the (likely) case that a computer is the _only_
reasonable apparatus for its implementation. In particular, there's also
an earlier (Benson) case in which the supreme court decided that an
algorithm for converting from binary to BCD could NOT be patented,
specifically because a digital computer was the only reasonable way to
implement the algorithm. Since that was the only reasoanble apparatus
for its implementation, they considered the patent to cover essentially
all possible implementations, not just a specific one -- so it was
essentially equivalent to patenting the (unpatentable) algorithm itself
rather than its implementation with a specific apparatus.

That said, I should also point out that the Bilski case is likely to be
appealed to the Supreme Court -- which seems to reverse decisions made
by the Court of Appeals for the Federal Circuit fairly frequently, so
this rule may be temporary.

[ ... ]

.

US patent law requires (35 USC $112):

The specification shall contain a written description of
the invention, and of the manner and process of making
and using it, in such full, clear, concise, and exact
terms as to enable any person skilled in the art to which
it pertains, or with which it is most nearly connected,
to make and use the same, and shall set forth the best
mode contemplated by the inventor of carrying out his
invention.

The requirement is there (and the PTO is well aware of it) whether it
happened to be mentioned on one specific page or not.

Trade secrets are almost the opposite of patents: reveal your
code, or not take proper and adequate steps to prevent it from
being known, and you forfeit the right of trade secret. You
cannot have a patent and a trade secret for the same thing (and
I'm pretty sure that still holds in the US as well).

I don't think there's any specific law to that effect, but I can't quite
imagine how anybody could claim both at once -- though I can certainly
believe that a single program, especially an "enterprise" type of thing,
could embody both trade secrets and patents.

And of course, you can register almost anything as a trademark.
I've often wondered why trademark protection wasn't used for
"look and feel"---copyright doesn't seem to be right here. (To
me---and again, I'm not an IP lawyer, so there are likely issues
that I don't understand.)

The idea of a trademark protection is consumer protection -- in
particular, it protects a consumer from buying something thinking that
it's something else. The typical example would be thinking you're buying
a Rolex, but upon close examination finding that what you bought was a
"Polex" instead.

This means that a trademark must be something the consumer can/will see
(or hear, or whatever) during the process of deciding what product to
buy. It's also why trademark holders are required to be diligent about
protecting their trademark. If a name that started out with a trademark
falls into common use (e.g. people referring to any photocopier as a
"Xerox") the courts can (and will) decide that there's no real
likelihood that (for example) an IBM copier being sold as a "Xerox" will
lead the consumer to believe he's buy a product built by the Xerox
company rather than just buying a photocopier.

[ ... ]

Of course. You can *publish* anything you want about a patent.
(You might be required to mention that the code is covered by
patent. I'm not sure there. And anyone who uses the code to
compete with the patent holder, without the authorization of the
patent holder, is infringing.)

The law doesn't require that you mention a patent when you publish
something about a patented invention. Some publications do. At least
when a patent holder publishes something, they'll generally want to
mention the patent anyway -- wilful infringement (i.e. when the
infringer is aware of the patent) can lead to increased damages.

[ ... ]

An English rendition is clearly legal; it must appear in the
patent. Beyond that, you'd have to talk to a patent lawyer, to
read the entire patent, and measure exactly what is covered.
And you'd have to ask to what degree the patent is enforceable;
if it is a solution that is evident to any competent
practitionner, you can fight it.

Just a nit: a patent includes claims, and those are what really define
what the patent covers -- the specification may disclose a great deal
more that's not patented. The specification IS, however, your first
reference to figure out the meanings of terms in the claims when/if
you're not sure the usual definition applies.

Note that RSA is patented in the US, but the patent is not
recognized elsewhere. (I think it might be recognized today,
however. As long as the patent covers using the algorithm for
a specific cryptographic purpose, and not the algorithm itself.
It's a "machine" which is realized entirely in software.)

Another minor note: RSA _was_ patented, but 1) that patent expired years
ago, and 2) it may be open to some question whether that patent would be
considered valid under the current rules anyway.

Interestingly many patents, even some that are quite well known, are
never tested in court. Just for one well known example, the Welch patent
on LZW compression was _never_ litigated (and probably never will be,
since it's expired).

 

[Jerry Coffin]

Templates are useful to some extent (in C++) but they're also headache
inducing, for example concerning:

* compiler error messages: a small error, and you might over a hundred
lines of barely intelligible gibberish hurled at you, and your only hope
is scanning through the mess trying to spot where the error might be
(with some practice, this becomes quite possible, although still tedious
and frustrating),

This really is a problem with templates as currently defined -- but C++
0x adds Concepts, which deal with this problem (among several others)
quite nicely. The problem is that you don't have any way of directly
specifying the requirements of a set of types used to instantiate a
template. All the compiler can do is try to instantiate it over the
specified types, and report any errors that arise in the result -- but
even though the error is usually in the instantiating code, the error
will usually be reported as a problem with the type over which it's
instantiated (e.g. that it can't find a ctor to allow an assignment to
take place). Concepts allow you to specify requirements on the type(s)
over which a template can be instantiated -- and the compiler can
directly report problems if you try to instantiate over types that don't
support what's specified.

* debugging: I use gdb, which has sketchy C++ support at best but once
you venture into template-land, you could just aswell strangle yourself
with piano wire for all the hope that is left by then.

This isn't really a problem with templates, but with a particular tool.
There are debuggers that work quite nicely on templated code.

 

[James Kanze]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

I'd have to read the entire patent to be sure, and even
then, I'm not a patent lawyer. Still, the first sentence of
the abstract says it concerns a "process". The real
question then becomes: what is a process, and what is an
algorithm. The fact that the patent seems to talk about
input and output formats suggests that it is more than an
algorithm. (On the other hand, one might seriously question
the novelty or originality. Off hand, it looks to me that
what is being patented is the use of a program to convert
between two formats. Which isn't what I'd consider a
particularly novel or original idea. But from what I've
read, the patent office in the US doesn't really have the
means of verifying such claims, and counts on the applicant
being honest and providing full and detailed "existing
practice".)

The line between what's patentable and what's not ("Statuatory
subject matter") is fine and has been argued repeatedly over
the years.

Yes. What is the difference between an algorithm (explicitly
excluded from patent protection) and a process (explicitly
patentable)? Is quicksort an algorithm, or a process for
sorting an array? And presumably, one can speak of algorithms
when talking about specific workflows.

In the US, the Court of Appeals for the Federal
Circuit recently handed down a decision in the "Re: Bilski"
case that (at least for the moment) made a rule that to be
valid, the patent has to be drawn to either a transformation
of matter, or the use of a "specific apparatus". As such, the
patent cited previously, along with quite a few others, may
well be invalid, unless a specific mechanism is required for
its implementation -- and chances are that "digital computer"
won't qualify as the specific apparatus, at least in the
(likely) case that a computer is the _only_ reasonable
apparatus for its implementation. In particular, there's also
an earlier (Benson) case in which the supreme court decided
that an algorithm for converting from binary to BCD could NOT
be patented, specifically because a digital computer was the
only reasonable way to implement the algorithm. Since that was
the only reasoanble apparatus for its implementation, they
considered the patent to cover essentially all possible
implementations, not just a specific one -- so it was
essentially equivalent to patenting the (unpatentable)
algorithm itself rather than its implementation with a
specific apparatus.

That said, I should also point out that the Bilski case is
likely to be appealed to the Supreme Court -- which seems to
reverse decisions made by the Court of Appeals for the Federal
Circuit fairly frequently, so this rule may be temporary.

It's still very interesting, since it does seem to be a return
to the original principles.

[ ... ]

Trade secrets are almost the opposite of patents: reveal
your code, or not take proper and adequate steps to prevent
it from being known, and you forfeit the right of trade
secret. You cannot have a patent and a trade secret for the
same thing (and I'm pretty sure that still holds in the US
as well).

I don't think there's any specific law to that effect, but I
can't quite imagine how anybody could claim both at once --
though I can certainly believe that a single program,
especially an "enterprise" type of thing, could embody both
trade secrets and patents.

Agreed. I doubt that there's a specific law to the effect:
trade secret law describes trade secrets, without mentionning
patents, and vice versa (I suspect, anyway). And of course, any
one program can certainly embody patents and trade secrets. And
probably fall under copyright protection as well.

The idea of a trademark protection is consumer protection --
in particular, it protects a consumer from buying something
thinking that it's something else. The typical example would
be thinking you're buying a Rolex, but upon close examination
finding that what you bought was a "Polex" instead.

This means that a trademark must be something the consumer
can/will see (or hear, or whatever) during the process of
deciding what product to buy. It's also why trademark holders
are required to be diligent about protecting their trademark.
If a name that started out with a trademark falls into common
use (e.g. people referring to any photocopier as a "Xerox")
the courts can (and will) decide that there's no real
likelihood that (for example) an IBM copier being sold as a
"Xerox" will lead the consumer to believe he's buy a product
built by the Xerox company rather than just buying a
photocopier.

In other words, unless it's immediately visible at the point of
sale or in advertising literature, it can't be trademarked. So
the shape of a Coke bottle, fine, but the structure and naming
conventions in a C++ library, no. (But doesn't that still leave
the Apple look and feel "trademark-able"? It's usual to have
seen a short demo before buying a system, and if that demo looks
like an Apple...)

 

[James Kanze]

[...]

Can I memmove tr1 arrays around in memory?

You can't do that with C style arrays, in C++. And why would
you want to?

I'm close to the hardware, you are not. Get off my case. I do stuff
with memory, thats pretty much all I do. You start telling me I can't
do that, I'll call you hitler.

l

 

[Martin Eisenberg]

In other words, unless it's immediately visible at the point of
sale or in advertising literature, it can't be trademarked. So
the shape of a Coke bottle, fine, but the structure and naming
conventions in a C++ library, no. (But doesn't that still leave
the Apple look and feel "trademark-able"? It's usual to have
seen a short demo before buying a system, and if that demo looks
like an Apple...)

I suppose that falls under industrial design rules.


Martin

 

[Noah Roberts]

That is too far away from the machine to be at a traditional C/C++
level if you ask me. It puts too much of a black box between me and
the hardware [...]

It is not really any further from the machine; you can view a tuple as
a structured layout of memory. Vice verca, a 'struct' is just an
associative tuple indexed by names (fields). What I showed is that
templates has the power to model structs as well; just to answer your
question.

Although I agree with you that this is no further from the "machine" I
don't think you're correct about being able to view tuples as structured
layout of memory in the same sense that you can with a struct...at least
not while in a debugger. The internal structure of a tuple is actually
a rather complex, recursive definition of structures. This is why we
decided they where not perhaps good to use in many places. It may or
may not end up being the same thing when compiled in release mode, but
in debug they're usually very, very different.

In this case I think you confuse "overused" with "used for complex
stuff". I don't think you'll find widespread use of associative
tuples. That said, I fully agree with you that keeping things simple
is a good rule of thumb. Again, judicious is good.

It seems clear to me that the people against these constructs do not
understand their purpose. A while back I explained, on this list, how
it is possible to develop a general interface for SQL querying using
tuple definitions in association with mpl::for_each. Through the tuple
interface you can code your compiler to write stuff that is quite common
in structure but would otherwise have to be done by hand or through some
sort of preprocessor magic.

Although the code inside of these constructs is more templated and thus
scary to some people, the use of the code is very different. When you
can write any SQL query in C++ like so:

tie(id, name) = query<int, std::string>(select_command);

When you can do that no matter what structure you want or type then
you've come up with a very easy to use, general interface for querying a
database. This is a good thing.

I also posted not too many days ago how one could implement compile-time
reflection in C++ using template metaprogramming. Much of what I did
could have been done in some manner using the tuple types.

It is these generic, high-level constructs that are what make templates
so powerful. You're actually writing code that is a level of
abstraction above what most people are used to developing in; where you
don't even know the type you're working on, only the algorithm. This is
perhaps why people find it so difficult. However, it actually turns out
to be quite easy once you get the hang of it. You don't use it all over
the place obviously but in some places where you can leverage the power
of TMP, template structures like tuple and type vectors come in very handy.

 

[Jerry Coffin]

[ ... ]

Yes. What is the difference between an algorithm (explicitly
excluded from patent protection) and a process (explicitly
patentable)? Is quicksort an algorithm, or a process for
sorting an array? And presumably, one can speak of algorithms
when talking about specific workflows.

The current US rule is that if it covers all possible (or reasonable)
implementations, it's an algorithm and can't be patented. If it's
restricted to a more specific implementation and there are other
reasonable implementations of the same basic idea that wouldn't fall
within your patent, then there's a better chance that it can be
patented.

[ ... ]

It's still very interesting, since it does seem to be a return
to the original principles.

Largely, yes. It's also interesting in being one of the few cases I've
seen in which the Court of Appeals for the Federal Circuit has taken a
rather restrictive view of what can be patented. Up until this, it's
largely been a matter of the CAFC ruling that almost anything can be
patented, and the Supreme Court reversing them to restrict the domain.
Having decided to restrict the domain themselves may reduce the chances
of reversal by the Supreme Court.

[ ... ]

Agreed. I doubt that there's a specific law to the effect:
trade secret law describes trade secrets, without mentionning
patents, and vice versa (I suspect, anyway). And of course, any
one program can certainly embody patents and trade secrets. And
probably fall under copyright protection as well.

Right. One thing I should add is that in the US trade secrets fall under
state law while patents fall under federal law -- so there's essentially
no coordination between the two at all.

[ ... ]

In other words, unless it's immediately visible at the point of
sale or in advertising literature, it can't be trademarked. So
the shape of a Coke bottle, fine, but the structure and naming
conventions in a C++ library, no. (But doesn't that still leave
the Apple look and feel "trademark-able"? It's usual to have
seen a short demo before buying a system, and if that demo looks
like an Apple...)

I suppose it's possible, but it sounds like a bit of a stretch to me.
Doing a quick look at Trademark law (of the US), when you apply for a
trademark in the US, you need to submit "a clear drawing of the mark".
The patent and trademark office's manual of trademark examining
procedure emphasizes that this means exactly ONE drawing. I think it'd
be pretty hard to demonstrate a look and feel in a single drawing.

Perhaps a design patent would be a better possibility. A design patent
allows you to include as many drawings as you like, along with written
descriptions as you see fit, including one or more claims, just like a
normal (utility) patent. On the other hand, a typical design patent
contains only a single drawing and a single claim, which is typically
something like: "The decorative design of an athletic shoe as shown and
described."

 

[Jerry Coffin]

Can you recommend any?

Not really -- it all depends on the compiler you're using. The original
post sounded like g++ was the compiler being used -- and I don't know of
a debugger I'd consider very good that works with it (regardless of
whether templates are involved or not). The debugger in Visual Studio
works pretty reasonably on templated code.

 

[James Kanze]

[ ... ]

Yes. What is the difference between an algorithm (explicitly
excluded from patent protection) and a process (explicitly
patentable)? Is quicksort an algorithm, or a process for
sorting an array? And presumably, one can speak of algorithms
when talking about specific workflows.

The current US rule is that if it covers all possible (or reasonable)
implementations, it's an algorithm and can't be patented. If it's
restricted to a more specific implementation and there are other
reasonable implementations of the same basic idea that wouldn't fall
within your patent, then there's a better chance that it can be
patented.

[ ... ]

It's still very interesting, since it does seem to be a return
to the original principles.

Largely, yes. It's also interesting in being one of the few cases I've
seen in which the Court of Appeals for the Federal Circuit has taken a
rather restrictive view of what can be patented. Up until this, it's
largely been a matter of the CAFC ruling that almost anything can be
patented, and the Supreme Court reversing them to restrict the domain.
Having decided to restrict the domain themselves may reduce the chances
of reversal by the Supreme Court.

[ ... ]

Agreed. I doubt that there's a specific law to the effect:
trade secret law describes trade secrets, without mentionning
patents, and vice versa (I suspect, anyway). And of course, any
one program can certainly embody patents and trade secrets. And
probably fall under copyright protection as well.

Right. One thing I should add is that in the US trade secrets fall under
state law while patents fall under federal law -- so there's essentially
no coordination between the two at all.

[ ... ]

In other words, unless it's immediately visible at the point of
sale or in advertising literature, it can't be trademarked. So
the shape of a Coke bottle, fine, but the structure and naming
conventions in a C++ library, no. (But doesn't that still leave
the Apple look and feel "trademark-able"? It's usual to have
seen a short demo before buying a system, and if that demo looks
like an Apple...)

I suppose it's possible, but it sounds like a bit of a stretch to me.
Doing a quick look at Trademark law (of the US), when you apply for a
trademark in the US, you need to submit "a clear drawing of the mark".
The patent and trademark office's manual of trademark examining
procedure emphasizes that this means exactly ONE drawing. I think it'd
be pretty hard to demonstrate a look and feel in a single drawing.

Perhaps a design patent would be a better possibility. A design patent
allows you to include as many drawings as you like, along with written
descriptions as you see fit, including one or more claims, just like a
normal (utility) patent. On the other hand, a typical design patent
contains only a single drawing and a single claim, which is typically
something like: "The decorative design of an athletic shoe as shown and
described."

--
Later,
Jerry.

The universe is a figment of its own imagination.

 

[James Kanze]

[ ... ]

Yes. What is the difference between an algorithm
(explicitly excluded from patent protection) and a process
(explicitly patentable)? Is quicksort an algorithm, or a
process for sorting an array? And presumably, one can speak
of algorithms when talking about specific workflows.

The current US rule is that if it covers all possible (or
reasonable) implementations, it's an algorithm and can't be
patented. If it's restricted to a more specific implementation
and there are other reasonable implementations of the same
basic idea that wouldn't fall within your patent, then there's
a better chance that it can be patented.

So quicksort would be patentable, since there are other
reasonable implementations of sorting. In many ways, I think it
should be. It certainly meets the requirements of novelty and
not being evident to a normal skilled practitionner. But I've
always seen it classified as an algorithm, and not a process.
(But maybe not in the sense that patent law uses these terms.)

[ ... ]

Agreed. I doubt that there's a specific law to the effect:
trade secret law describes trade secrets, without
mentionning patents, and vice versa (I suspect, anyway).
And of course, any one program can certainly embody patents
and trade secrets. And probably fall under copyright
protection as well.

Right. One thing I should add is that in the US trade secrets
fall under state law while patents fall under federal law --
so there's essentially no coordination between the two at all.

Which means that trade secret law varies from state to state?
(Maybe if you want to sell trade secrets, you have to go to
Nevada, like for a divorce.)

[ ... ]

In other words, unless it's immediately visible at the point
of sale or in advertising literature, it can't be
trademarked. So the shape of a Coke bottle, fine, but the
structure and naming conventions in a C++ library, no. (But
doesn't that still leave the Apple look and feel
"trademark-able"? It's usual to have seen a short demo
before buying a system, and if that demo looks like an
Apple...)

I suppose it's possible, but it sounds like a bit of a stretch
to me. Doing a quick look at Trademark law (of the US), when
you apply for a trademark in the US, you need to submit "a
clear drawing of the mark". The patent and trademark office's
manual of trademark examining procedure emphasizes that this
means exactly ONE drawing. I think it'd be pretty hard to
demonstrate a look and feel in a single drawing.

OK. Somehow I'd thought that trademarks were more general. I
presume you're only talking about the part of trademark law
which might conceivably be applied here. A name can certainly
be trademarked, without a drawing.

Perhaps a design patent would be a better possibility. A
design patent allows you to include as many drawings as you
like, along with written descriptions as you see fit,
including one or more claims, just like a normal (utility)
patent. On the other hand, a typical design patent contains
only a single drawing and a single claim, which is typically
something like: "The decorative design of an athletic shoe as
shown and described."

Hmmm. I didn't know about design patents. In other words, you
can patent other things than just processes and machines.

 

[thomas.mertes]

It seems clear to me that the people against these constructs do not
understand their purpose. A while back I explained, on this list, how
it is possible to develop a general interface for SQL querying using
tuple definitions in association with mpl::for_each. Through the tuple
interface you can code your compiler to write stuff that is quite common
in structure but would otherwise have to be done by hand or through some
sort of preprocessor magic.

Although the code inside of these constructs is more templated and thus
scary to some people, the use of the code is very different. When you
can write any SQL query in C++ like so:

tie(id, name) = query<int, std::string>(select_command);

What is 'select_command'?
Is it something that can be checked at compile time or is it some
string that the database checks at runtime?

I am interested to integrate the DB interface in the language in a
way it is done with LINQ. Instead of just transfering the select
requests as strings from the program to the DB, there should be some
better method. The 'select' should be part of the language (or
library) where the compiler can check some things. It would be no
problem if new statements, operators or other syntactic constructs
would be introduced, since I plan to create the DB interface for
Seed7, where all this things are possible.

Is your approach usable for a different language?
Templates would also be no problem, because Seed7 allows functions
to be executed at compile time, which is used to implement a
template/generics mechanism (some people prefer to see it as
abstract data type mechanism).

That was also my initial entry to this discussion:
I see templates as a very basic concept. Just because many languages
just have built in predefined templates like arrays, structs and
pointers does not make it a bad concept. There were times when
languages differentiated between predefined and user defined
functions and some languages even did not support user defined
functions. Now the predefined functions of most languages are
defined in a way such that the user could also define these
functions (predefined functions do not use any compiler built in
magic). Instead of the compiler built in magic for arrays, structs
and pointer the same generic approach should be taken.

My approach is: Provide basic concepts and define the predefined
constructs based on this concepts. That way arrays, structs and
pointers can be provided (with the help of some other features such
as operator and statement definitions). There is no problem to
manage the data in the way a C/C++ developer expects. Although the
Seed7 structs are implemented as templates, the C code generated by
the Seed7 to C compiler produces code which is corresponding to
a C struct (that means the elements are in a contiguous area of
memory). The user of a Seed7 array can use the notations he is used
to (from languages which support it with compiler built in magic).

At the end you can get best of both worlds:
Very generic basic concepts such as templates which implement arrays
and
contiguous memory layout and machine code with good performance.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.