Overuse of Templates

[Ted]

I'm putting the posts that follow here (hopefully they will follow here!) because
they were rejected in comp.lang.c++.moderated. It behooves anyone reading
them to first read the the thread of the same subject in clc++m to get the more
of the context.

Ted

[Ted]

"kanze" <ka***@gabi-soft.fr> wrote in message news:11**********************@z34g2000cwc.googlegr oups.com...

Ted wrote:

"kanze" <ka***@gabi-soft.fr> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

> Sebastian Redl wrote:
>> On Sun, 19 Mar 2006, Ted wrote: >> > Bad analogy. If you think using the STL blindly is OK,
>> > just say so. I personally think that is wrought with
>> > peril. >> So you honestly don't use any library where you can't
>> understand the implementation? Doesn't that feel
>> inefficient to you? > Why limit it to the libraries? If you take that point of
> view, you shouldn't use any language for which you've not
> written a compiler.

Or at least avoid the "features" of a language that make a
compiler system difficult to implement.
You mean the ++ part of C++.

You mean EVERY feature that C++ has over C is extremely
difficult to implement?
And of course, you can't use the
optimizer -- good optimization is more difficult than a simple
implementation of templates (without export).

It's a good thing most code doesn't require compiler optimization
any more huh.

Apparently someone(s) left off the spreadsheet column titled
"difficulty of implementing feature" (or perhaps exploited the
column? Things that make you hmmm.).

> But to get back to the original point: in pre-STL days, I
> actually implemented a library of basic classes: ArrayOf,
> DLListOf and AssocArrayOf (plus some others -- RefCntPtr,
> for example). I first did it with <generic.h>, because that
> was all we had in those days. I later redid it with
> templates. > The template solution is at least an order of magnitude
> simpler for the implementor. At significantly simpler for
> the user as well. You can do without, but it's more work.

10 times more work?

Probably more. Significantly complicated things, like my hash
map, were relatively trivial with templates, but a real pain
with macros.

Sounds like a design issue (you wanted some kind of ultra-sophisticated
container that required C++ template features?). If implementing containers
is difficult for you without C++ features, then I'd seriously reconsider your
container design.

If you can't prove "10 times more work", than I'd suggest you don't say
that anymore. Perhaps FOR YOU it's 10 times more work because you
don't know how to do it.

You don't really believe that.

It's not a question of believing. It's concrete experience,
doing non-trivial generic things like hash maps and such.

Then you did it wrong. I had no problem implementing those. While good
container design can be considered an art, it's hardly the most difficult
programming problem to undertake. It's good training ground to learn C++
(and programming in general).

What is true though is that implementing the C++ template
system is orders of magnitude more work than implementing a
preprocessor-based template system.

Yeh, but I don't have to do that part.

Nor could you if you wanted to in the future (lock in).

> If the argument is that some people are overusing templates,
> and writing unreadable code, I can accept that. I even
> agree. But to say that <generic.h>, or something similar,
> is superior to templates... No body who has really used
> both would ever claim that.

Except me. :)

Which is what makes me wonder whether you have really done
anything non-trivial with the macro solution, and tried to use
it in anything larger than a toy application. You experience is
exactly the opposite of everyone else's.

I think others didn't think about it long enough. ("macro solution" is
actually non-appropriate. "preprocessor solution" is more accurate.
Perhaps that's where you failed in your attempt to implement containers
with the preprocessor: you didn't think outside of the macro concept to
the system level).

Ted

[Ted]

"Bob Bell" <be****@pacbell.net> wrote in message news:11**********************@u72g2000cwu.googlegr oups.com...

Ted wrote:

"Bob Bell" <be****@pacbell.net> wrote in message news:
11**********************@v46g2000cwv.googlegroups. com...

Ted wrote:
"Bob Bell" <be****@pacbell.net> wrote in message news:
11**********************@v46g2000cwv.googlegroups. com...
> Seriously, I get what you're after. Templates can be extremely
> complex.
> But they can also be used simply and directly. In this way they
> are no
> different from other features.

Like I said, if I could reproduce that black box that implements
them, I'd
probably use them.

I'm sorry, this makes no sense. You won't use templates because you
don't know how to implement them? If I used your logic, I wouldn't
drive my car. (Oops; sorry to keep going back to that "bad
analogy", it
just seems to fit remarkably well.)
If you think that analogy works well, well nevermind. All it works
well for is
"winning" your argument (in only your mind). Unfortunately, it
lacks substantive
relevance. Your homework assignment: consider how an engineer using
engineering knowledge and tools is not like the majority of drivers of
automobiles.

They are dissimilar in lots of ways. However, they are similar in one
important way, which is the point of the analogy. They are both using a
tool, the implementation details of which are not nearly as important
as the interface. As long as templates behave the way the standard says
they should, why should anyone care how they are implemented?

Instead of attempting to find an analogy that fit the scenario, you went out
and found an analogy that fit your goal.

But if it's a multi-manyear effort, I have to dismiss it
as a less than adequate solution. I'm not saying that C++
templates are
bad, just that the implementation is overkill/bad. Make it better
and I'll use
it.

Why should I "make it better" for you? I don't care if you use
templates or not.
I didn't mean you personally, silly.

Fine; why should anyone "make it better" for you?

It's not just for _me_. It's my suggestion for improvement is all.
Apparently you
already have a system you're comfortable with that works well for you.

Just a teensy lil mechanism or two in the preprocessor though would make it
much nicer.

Ted

[Ted]

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.sunsite.dk...

In article <HLCTf.40456$_S7.23510
@newssvr14.news.prodigy.com>, [e-mail] says...

[ ... ]

> The same cannot be said of the preprocessor-based technique.
Why don't you think so? The initial development debugging?
Templates inherently (should be if well designed) are low maintenance
relative to non-template code.

Because the preprocessor does so very little (nothing,
really) to actually _support_ what you're trying to do.

It works quite well though.
Just for one obvious example, ensuring that macro
parameters aren't expanded more than once makes life
difficult, even for relatively trivial cases.
You're not really doing
"macros" when using preprocessor-based templates. It's
different. Preprocessor-based templates expand to C++ things
like classes and inline functions. The typing info is what the
expanded templates provide. The expanded templates are
C++ code for desired types just as if you would have written
a custom class for the given type (in the case of class templates).
It's just text replacement.
Even within the range that's fairly easy to handle
correctly, macros tend to be difficult to read
Only if you are talking about syntax highlighting (and that's
a tool issue rather than a language issue). Otherwise, preprocessor-based
templates are really no worse to read than C++ templates.
-- you
either figure out a single statement for the entire
macro, or you use ugliness like 'do {X}while(0)' to make
it act like one -- and lose the ability to yield a
resulting value in the process.

Templates can be abused to the point that code becomes
unreadable -- but unlike macros, the lack of readability
is avoidable and usually unnecessary.

Preprocessor-based templates and "macros" are distinctly different.

Macro (with potential side effects):

min(a,b) (((a) < (b)) ? (a) : (b))

Preprocessor-based template (no side effects):

#define DecAlgoMin(T) \
inline T& min(T& a, T& b) \
{ return a<b ? a:b; }

Ted

Ted

[Ted]

<ke********@motioneng.com> wrote in message news:11**********************@u72g2000cwu.googlegr oups.com...

I was just hoping for some better
preprocessor support (or maybe compiler support) to help implement templates
better (read, a few exposed key mechanisms).

IM(NS)HO, the C++ preprocessor could certainly use some additions to
make doing things easier. C99's variadic macros are nice. So is C99's
__FUNCTION__. But I agree that having some nicer preprocessor tools
for making templates would also be nice. I had to create my own C++
preprocessor templates when working with .NET. I couldn't use C++/CLI
templates because I needed to export the classes to a C# interface.
(And no, generics wouldn't work.) But, I had I been able to use
C++/CLI templates I would have as I believe they are easier to use (not
implement compiler support for -- just to use in development).

In as much as using a language means going through the process of
software development, I'd like to see some exposed "hooks" into the call
stack and such. I have my own tracing system, but I probably shouldn't
have had to create that and I shouldn't have to rely on a vendor's IDE to
do such either IMO.

I currently have to type the function name into my
Trace macro because I don't have control over the format of the func name,
and originally, my compiler didn't have any __FUNC__ like thing. So,
__FUNC__, yes. But with some control over the format. Similar for __FILE__.

Ted

[Ted]

<ke********@motioneng.com> wrote in message news:11*********************@e56g2000cwe.googlegro ups.com...

At this point, I haven't had to use anyone else's libraries (save for the Win32 API).
Maybe (likely) in the future when the domain knowledge required is too time
consuming and I go into production I will though (or even more likely, hire someone
to implement it my way).

Wow! What type of development do you do? Are you a contract
developer, work as a salaried employee for a company, work in academia,
or just do development as a hobby? I'm impressed that a developer
wouldn't use anyone else's libraries (except for the Win32 API) -- but
would honestly be quite apprehensive about using a product they
developed. (Nothing against you -- I don't know you -- I've just been
burned by libraries that haven't been tested enough in the past.)

I'm building the better mousetrap in my garage. (I used to be employed in the
early 90's as a developer of data reduction and analysis software and to some
extent OLTP corporate ware).

Ted

[Ted]

"Gerhard Menzl" <ge***********@hotmail.com> wrote in message news:44********@news.kapsch.co.at...

Ted wrote:

> Stroustrup has said (not lately probably, but way back when) that
> the preprocessor-macro-based templates work surprisingly well
> actually. I have found that also. I wouldn't use the technique
> either if it was a major PITA.

Stroustrup also wrote: "The first rule about macros is: Don't use them
if you don't have to.
Generalizations are almost always wrong. (Even when an authority uses
them).

So why do you refer to a generalized statement by an authority in the
first place? And without going to the trouble of giving a proper
citation, too?

Because it was relevant. The "statement" is as true today as it was back then.
It's also relevant that the language inventor said it. You're more than welcome
to ponder what the larger ideals of Stroustrup entail if you want to. It's factual
that preprocessor-based templates work surprisingly well. Deal with it and
stop trying to make it political when it is just a fact. (seesh).

(The C++ Programming Language, 3rd ed., p. 160). The rest of the
chapter is used for demonstrating why macros are almost always
unnecessary, and why C++ offers better alternatives, such as
templates.

"better" is in the eyes of the beholder. You don't seem very objective
at all.

I summarized what Stroustrup writes about macros and templates. Why this
should say anything about my objectivity is beyond me.

"You started it". :P

I'm not trying to convince anyone of anything. On the contrary, people
here are trying to convince me that I should be using C++ templates
because they are "better".

So what's your point?

That I'm not selling anything.
If you are happy with macros and implementing
everything down to memcpy() yourself, what is your message?
LOL. You want a generalization.
Look, Ma, no
templates? Did you seriously expect long-standing members of the C++
Standard Committee to throw up their arms and confess: the emperor has
no clothes, we have been fooling ourselves all the time?
Don't get so sensitive.
You are perfectly entitled to ignore at least a century of aggregated
practical experience and say: thanks, I prefer my homegrown. But going
on about it in a public newsgroup brings the word "trolling" to mind.
From now on, I will refrain from anything that smells like feeding.

Try and open your mind at least sometimes.
C++ templates certainly wouldn't be the first designed-by-committe monstrosity
if it were to be assessed as such.

Ted

[Ted]

"Francis Glassborow" <fr*****@robinton.demon.co.uk> wrote in message news:Q0**************@robinton.demon.co.uk...

In article <BL*******************@newssvr14.news.prodigy.com> , Ted
<[e-mail]> writes

And I have a template system that utilizes the preprocessor that works quite
well and avoids complex black-box machinery that costs millions of dollars.
Years ago, I used C++ templates. :P
Except that that cost is amortised over many hundreds of thousands (or
even millions) of programmers. Your mechanism costs every programmer
significant time.

It's really not that much different time-wise than C++ templates. Probably less
because one is limited to "simple templates" rather than complex C++ style
templates.
Actually I can read template code and understand what it is doing at
least an order of magnitude faster than trying some pre-processor
alternative.
People seem to be pretty loose about claims of "orders of magnitude" around
here. The code for preprocessor-based templates looks pretty much like C++
templates. So why you think you'd be able to decipher C++ templates 10
times faster than preprocessor-based ones escapes me.
But the big point is that I can write and test templates
much faster than I can write the equivalent using the pre-processor. I
think that is true for most people round here.
Only a little faster if you have a bit of tool support for preprocessor-based
templates.
Yes some of the fancy meta-programming stuff is bizarre and hard to
understand the first time you see it. And if you have never tried
functional programming quite a few of the more recent uses of templates
will tax your understanding. However time might be better spent
mastering templates than trying to do the same thing without them.

I think time is better spent doing template design rather than learning
"stupid C++ template tricks".

Ted

[Ted]

"Richard Smith" <ri*****@ex-parrot.com> wrote in message news:11**********************@v46g2000cwv.googlegr oups.com...

Ted wrote:

I was just hoping for some better
preprocessor support (or maybe compiler support) to help implement templates
better (read, a few exposed key mechanisms).
You've said this, or similar things, in a number of places in this
thread. What exactly is it this "better preprocessing support" that
you are hoping might be provided? Perhaps this thread might be more
productive if it were to focus *constructively* on what additional
preprocessor functionality might be of use instead of *destructively*
proselytising against templates.

But you don't understand. I'm not proselytising at all (what ever that means).
I just don't use C++ templates. Maybe you and some people are sensitive
about that. To each his/her own.
So come on, let's have some examples of what you are actually trying to
get done -- preferably with some real world examples of why they could
be useful. (And no, examples from your preprocessor
implementation of templates don't count as real world examples.)
They're as real world as C++ templates. Virtually the same. They even look
similar. But you guys are the language lawyers supposed to come up with
this stuff.
Shall I start the ball rolling? I imagine that a block #begindef,
#enddef construct would be useful. This would (a) avoid the need for
putting backslashes at the end of lines,
That might be good. I now use // TEMP_BEG, // TEMP_END and have the
scriptable IDE toggle the backslashes on or off between those markers with
one click. Perhaps the toggling is adequate. Perhaps the way to specify a
multiline macro with markers is an easy preprocessor add. The concession
being made of course is being able to step through template code like
C++ templates allow. I'm willing to make that concession though (and it's not
necessarily "bad" since it will make template designers think more about
their template designs).

I also have scripts associated with 'Template' menu choices that expand templates,
copy/delete/paste them. I'd be OK with just having the templates put in the "right"
place rather than having mechanisms to control where/when templates get
expanded (I think).
and (b) allow a macro
definition to include other preprocessor directives.
Yep, that would be good. The problem to be solved is where to put
expanded template declarations/definitions and how to ensure they get
declared/defined only once. What are the possibilities?. Moreso, how could
it be done most simply? This is the key mechanism I would like to see
added and exposed.
The syntactic
convenience of avoidng backslashes is fairly cosmetic, but the ability
to include a #if & friends, #define, #undef or #include within a
#define might be useful.

Or another example: the preprocessor currently has the ability to
evaluate certain types of constant expressions (e.g. it understands
that 1+2 == 3 is true as it can be put in a #if line). Perhaps a
preprocessor eval() function (akin to defined) might be useful.
I haven't thought about that. I'm really only concerned about implementing
templates with the preprocessor rather than "bringing back macros like
in C".
Whilst I agree *in general* with Stroustrup's comment that the
preprocessor is best avoided, I still feel that there are places where
it can serve a useful purpose, even if that purpose is only to work
around shortcomings in the language.
And I think it's a good way to implement templates. The perfect 80%
solution that is conceptually simple.
For example, the main place where
I use the preprocessor is in generating families of overloaded
forwarding functions using Boost.Preprocessor (or a similar library).
There's no doubt in my mind that a language solution (such as the
proposal for variadic templates) is a better long term solution, but
such a solution is still some years off, and I need a solution *now* --
so I use the preprocessor.

Even if this particular example is solved in C++0x, similar issues will
surely come to light when the full power of C++0x finally gets
realised. If devoting a little effort to improving the preprocessor
makes it better able to paper over any new cracks that emerge in C++0x,
this sounds like effort well invested.

And NOT having some of the constructs/mechanisms seems to be imposing
policy rather than providing mechanism. I like C++ because it doesn't attempt
to protect you from yourself. If you want to do something "unsafe", you can.
You decide whether it's appropriate or not in a given scenario.

Ted

[Ted]

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.sunsite.dk...

In article <1142866585.704854.90760
@i40g2000cwc.googlegroups.com>, ka***@gabi-soft.fr
says...

[ ... ]

Why limit it to the libraries? If you take that point of view,
you shouldn't use any language for which you've not written a
compiler.

Nor processors for which you haven't written Verilog or
VHDL (etc.) Nor transistors for which you don't know the
L/W ratio, the gate oxide thickness, the shape of the
lightly doped drain region, etc., ad infinitum.

If you want to progress much beyond the slide rule,
you're pretty much stuck using things that are basically
black boxes. From there, your own choices are to admit to
it and make use of the freedom it provides, or refuse to
admit to reality, and make your life miserable by trying
to turn C++ into a slide rule.

And then there's the extremists: always one end or the other, blind
to everything in between.

Ted

[Ted]

<ke********@motioneng.com> wrote in message news:11**********************@u72g2000cwu.googlegr oups.com...

"black box" refers to the implementation of the template subsystem or mechanisms
within the compiler and not, say, an individual container template of the
STL.
I understood what you meant. That's why I brought up the example that
I did. I don't need to understand the implementation details behind
fopen, sprintf, new, etc... to feel comfortable using them. They're
black boxes to me (and I can probably safely say to most developers).

You said:

"> You keep refering to the "black box" of templates. They are not black boxes"
I replied:

""black box" refers to the implementation of the template subsystem or mechanisms
within the compiler system and not, say, an individual container template of the
STL."

> any more than other parts of the standard C++ and standard C
> libraries.

See above. I wasn't refering to the STL as the black box (though it could
easily be used there too given the obfuscated code of all the implementations!).

OK, I can see how you may have thought I meant the STL since I said
"standard libraries", but what I meant was "standard C++ and standard C
language featureset." My examples then could perhaps also been more
appropriately described by "classes, virtual functions, exceptions,
multiple-inheritance, function-level static variables, switch/case
statements, etc...". While I understand the details of the common
implementations for most of these, I certainly don't have to. They
could be black boxes to me and I could still develop code.

And that response probably was to me saying that simply using templates
blindly is wrought with peril.
And I, for one anyway, am not trying to convince you C++ templates are
better than pre-processor templates. Each developer has to make
his/her own decision here. At a large level, I'm arguing that
templates are not as overused as you believe they are.
My perception is that the C++ template thing has caused a dark period for
good development books, for one thing. The literature seems to be stuck at
the language level rather than use of it. (Or maybe I just don't find anything
enlightening anymore?).
On a smaller
level, I disagree with some of your supporting arguments and am trying
to point out where I disagree.

Ted

[Phlip]

Ted wrote:

"kanze" wrote:
Ted, your first abuse was over-quoting. Always trim.

Your second mistake was arguing with Kanze. Don't. _Discuss_ things, with
folks closer to your level, before engaging a lifer on that hard-headed
newsgroup.

Or at least avoid the "features" of a language that make a
compiler system difficult to implement.

You mean the ++ part of C++.

You mean EVERY feature that C++ has over C is extremely
difficult to implement?

This is an exaggeration. Kanze didn't mean that, and someone more evenly
tempered would allow Kanze to mean those features which make C++ harder than
C to implement.

Even if the moderation system permits your slur (and it is indeed a slur),
your sentence still adds no value.

And of course, you can't use the
optimizer -- good optimization is more difficult than a simple
implementation of templates (without export).

It's a good thing most code doesn't require compiler optimization
any more huh.

And this attitude is triggering our troll detector.

The sentence adds no value, and detracts from C++'s culture of performance.
You are expected to be professional enough to know that C++ _does_ value
performance. Again, this is not enough to push the sentence over the edge.
The attitude and the detraction does.
Sounds like a design issue (you wanted some kind of ultra-sophisticated
container that required C++ template features?). If implementing
containers
is difficult for you without C++ features, then I'd seriously reconsider
your
container design.
"difficult for you" is a common technical flame. Sorry if you thought it was
original (and, yes, I have been openly flamed on
news:comp.lang.c++.moderated before...)

The moderators also censor redundant threads. Objection: Asked and answered.
If you can't prove "10 times more work", than I'd suggest you don't say
that anymore. Perhaps FOR YOU it's 10 times more work because you
don't know how to do it.
"don't say that anymore" and "you don't know how to do it" are simple
flames. There were ways to say the same thing politely, that lead the
responder.

Further, your attitude is rising thru the post. We admit it's Kanze having
his way with your entry-level rhetoric. One poster to clcm once said he'd
rather box with Mike Tyson than argue C++ with Kanze. Part of learning to
post is learning to admit when someone is, indeed, teaching you something.
Go back and read many posts there, and _never_ reply to a post without
reading the whole thing through first, and then giving yourself time to
think (and sublimate, while thinking about something else).

Many of the corresponders on that newsgroup are authors, and know how to
walk through a topic, step by step. Never just dive in at the top of a post
and start gain-saying each element of their argument. You will lose each
time you do that.
I think others didn't think about it long enough. ("macro solution" is
actually non-appropriate. "preprocessor solution" is more accurate.
Perhaps that's where you failed in your attempt to implement containers
with the preprocessor: you didn't think outside of the macro concept to
the system level).

And by now the moderator has tuned out.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Phlip]

Ted wrote:

But you don't understand. I'm not proselytising at all (what ever that
means).
Then look it up.
I just don't use C++ templates.
Then you are not qualified to debate them.
Maybe you and some people are sensitive
about that. To each his/her own.
That is a flame - presuming someone's emotions.
But you guys are the language lawyers supposed to come up with
this stuff. That might be good. I now use // TEMP_BEG, // TEMP_END and have the
scriptable IDE toggle the backslashes on or off between those markers with
one click. Perhaps the toggling is adequate. Perhaps the way to specify a
multiline macro with markers is an easy preprocessor add. The concession
being made of course is being able to step through template code like
C++ templates allow. I'm willing to make that concession though (and it's
not
necessarily "bad" since it will make template designers think more about
their template designs).
IDE support does not make macros better than templates.

Another problem is your learning curve directly opposes the learning curve
of the C languages throughout their history. In the beginning, C was a kind
of portable assembler, and the only template facility was big beautiful
macros.

Then the language matured, and grew more powerful features than macros and
other preprocessor goodies. And programmers started dealing with old-style
code that had hit macros' many problems. They started teaching "don't abuse
macros".

So every semester these newsgroups field questions from students learning to
abuse macros. All the responders here know the rhetoric to explain when and
how to use better techniques (enumerations, inline methods, templates,
etc.). So when someone starts arguing with this very polished rhetoric in
ways that prove they are not listening or trying to understand what we are
saying, we tune out. This is probably what happened to your thread on clcm,
regardless of each post's flame counts.

Bouncing all your posts after that spike in flames was a way to give you a
cooling off period. Accept it gracefully.
I also have scripts associated with 'Template' menu choices that expand
templates,
copy/delete/paste them. I'd be OK with just having the templates put in
the "right"
place rather than having mechanisms to control where/when templates get
expanded (I think).

You might put such creativity into learning to use and understand the
language's various features better. You are currently playing with your
editor in ways that generate code that will rapidly become brittle and hard
to change over time.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Gianni Mariani]

Ted wrote:

I'm putting the posts that follow here (hopefully they will follow here!) because
they were rejected in comp.lang.c++.moderated. It behooves anyone reading
them to first read the the thread of the same subject in clc++m to get the more
of the context.

This is a bad idea. Why not just post a summary of your issue. Very few
of us want to read the cruft. The two postings I read seem like it's a
pissing contest.

BTW, this sounds like an argument that ends in:
"I can write bad code in any language"

You need to first state the design goals. e.g. PHP is a great language
- if you're scripting a website and targetting an audience that needs a
short and shallow learning curve and performance is not going to be an
issue (ever).

C++ has a number of design goals :
http://en.wikipedia.org/wiki/C%2B%2B#Philosophy (very abbreviated)

There are many ways you can use C++ (it's one of the design goals). I
tend toward design by interfaces (mostly pure abstract classes) and
hidden implementations using generic abstract factories to select
various implementations. This methodology is not appropriate for every
problem. For a matrix library, I would tend to use a template interface
while for a system independant file library, I would use non abstract
class interfaces.

The point is, C++ is a single language with multiple use paradigms (by
design). There are many things you can say are "BAD" uses of C++ and
FAQ for this NG does covder many of them (although I have reservations
about a few of them).

"overuse of templates" depends on context and WILL end up in a
testosterone fight if you don't narrow the discussion.

My reccomendation to the OP is to ignore the noise and try to focus on
the signal.

BTW - I don't post on c.l.c++m because a number of my posts have been
rejected for rather stupid reasons in the past and I'm no longer going
to waste my time trying to help someone if it gets thrown in the bit
bucket. Also, c.l.c is much faster at getting your answer, no waiting
for a moderator. Also, I don't waste my time answering when it has
already been answered unless there is more to the topic. Yep, you get
the occasional flame bait, but in general, they're seldom and I don't
have to bother reading them if I don't want to. c.l.c++m is for the
static functors.

[Ted]

"Phlip" <ph******@yahoo.com> wrote in message news:1X******************@newssvr30.news.prodigy.c om...

Ted wrote:

"kanze" wrote:
Ted, your first abuse was over-quoting. Always trim.

I mostly do. I'm probably better than the majority of people in that regard.
That thread seemed to need more context to remain so as to be clear of
the context so it was easier to just leave the conversation mostly there.
Your second mistake was arguing with Kanze. Don't. _Discuss_ things, with folks closer to your level, before engaging a
lifer on that hard-headed newsgroup.
I don't argue. I always discuss. I never bow though.

Or at least avoid the "features" of a language that make a
compiler system difficult to implement.

You mean the ++ part of C++.

You mean EVERY feature that C++ has over C is extremely
difficult to implement?

This is an exaggeration. Kanze didn't mean that,

Then why did he say it? It's his exaggeration then. I'm not the compiler writer.
If he says that all the C++ idioms are complex to implement, I tend to believe him.
But because the issue is so relevant and important to the topic, I wanted further
confirmation of the statement.
and someone more evenly tempered would allow Kanze to mean those features which make C++ harder than C to implement.
Even if the moderation system permits your slur (and it is indeed a slur), your sentence still adds no value.
That's not what he said. Not what he implied. The implication was clearly that the
features that C++ adds over C are all complex to implement. One reason I avoid
C++ templates is because of the implementation complexity in the compiler. I want
to know what other features are on that same order of complexity so I can decide
if I'll program around those also. So the follow up was very warranted and appropriate.

And of course, you can't use the
optimizer -- good optimization is more difficult than a simple
implementation of templates (without export).

It's a good thing most code doesn't require compiler optimization
any more huh.

And this attitude is triggering our troll detector.

? I haven't used the optimization settings in my compiler for years.
The sentence adds no value,
It gives the other side of the story: that optimization isn't as required now that
memory and CPU performance is what it is today. Letting the statement stand
would be to allow the perception that optimization is key and always required
whereas today it is rarely needed. The statement does indeed add value: it
attempts to dispel a myth that is being attempted to justify "C++ templates".
and detracts from C++'s culture of performance.
That's a pardigmic statement that just wreaks of poor engineering judgment.
You are expected to be professional enough to know that C++ _does_ value performance.
The preceding statement applies.
Again, this is not enough to push the sentence over the edge. The attitude and the detraction does.
I sense someone on a high horse now.

Sounds like a design issue (you wanted some kind of ultra-sophisticated
container that required C++ template features?). If implementing containers
is difficult for you without C++ features, then I'd seriously reconsider your
container design.

"difficult for you" is a common technical flame. Sorry if you thought it was original (and, yes, I have been openly flamed
on news:comp.lang.c++.moderated before...)

He couldn't do it and I could. So apparently it is difficult or impossible for him
to do. No flame. I don't need C++ template features to implement containers.
If he does, so be it (but he won't be doing it for me, that's for sure).
The moderators also censor redundant threads. Objection: Asked and answered.

If you can't prove "10 times more work", than I'd suggest you don't say
that anymore. Perhaps FOR YOU it's 10 times more work because you
don't know how to do it.
"don't say that anymore" and "you don't know how to do it" are simple flames. There were ways to say the same thing
politely, that lead the responder.

Sorry. I'm not buying your spiel. Is it 10 times more work or not? Is it just
10 times more work perhaps for YOU? Let's get to the bottom of this. You
can't go on making preposterous statements and then not backing them up.
Further, your attitude is rising thru the post. We admit it's Kanze having his way with your entry-level rhetoric. One
poster to clcm once said he'd rather box with Mike Tyson than argue C++ with Kanze. Part of learning to post is learning to
admit when someone is, indeed, teaching you something. Go back and read many posts there, and _never_ reply to a post
without reading the whole thing through first, and then giving yourself time to think (and sublimate, while thinking about
something else).
Apparently Kanze needs you to market him? Perhaps if he'd back up his
statements he wouldn't need you at all.
Many of the corresponders on that newsgroup are authors, and know how to walk through a topic, step by step. Never just
dive in at the top of a post and start gain-saying each element of their argument. You will lose each time you do that.

I didn't do that. I have to draw logical conclusion based on what is said. I have
nothing against Kanze. He's shown that he knows a lot about the C++ mechanics
and has answered questions for me in the past. So take your witch hunt elsewhere
please.

Saying "10 times more work" means that you either are exaggerating or that
you don't know how to do it. Which is it? This needs clarification because
it is being used as reason why preprocessor-based templates are deficient
compared to C++ templates. It's misinformation for the uninitiated coming
into the group and reading that. Back it up. Show me "10 times more work".

I think others didn't think about it long enough. ("macro solution" is
actually non-appropriate. "preprocessor solution" is more accurate.
Perhaps that's where you failed in your attempt to implement containers
with the preprocessor: you didn't think outside of the macro concept to
the system level).

And by now the moderator has tuned out.

Get off your high horse.

Ted

[Ted]

"Phlip" <ph******@yahoo.com> wrote in message news:i5******************@newssvr30.news.prodigy.c om...

Ted wrote:

But you don't understand. I'm not proselytising at all (what ever that means).
Then look it up.

That response pretty much gives away your agenda/attitude huh.

I just don't use C++ templates.

Then you are not qualified to debate them.

That would be convenient for you now wouldn't it (since you are on a
witch hunt). I used C++ templates for years before I found a "better"
way.

Maybe you and some people are sensitive
about that. To each his/her own.

That is a flame - presuming someone's emotions.

And if you'd quote the whole context, you might even see the appropriateness.
But of course your goal is crop to fulfill your own agenda (just like censoring
of the posts to begin with).

But you guys are the language lawyers supposed to come up with
this stuff.

That might be good. I now use // TEMP_BEG, // TEMP_END and have the
scriptable IDE toggle the backslashes on or off between those markers with
one click. Perhaps the toggling is adequate. Perhaps the way to specify a
multiline macro with markers is an easy preprocessor add. The concession
being made of course is being able to step through template code like
C++ templates allow. I'm willing to make that concession though (and it's not
necessarily "bad" since it will make template designers think more about
their template designs).

IDE support does not make macros better than templates.

Non-sequitur.
Another problem is your learning curve directly opposes the learning curve of the C languages throughout their history. In
the beginning, C was a kind of portable assembler, and the only template facility was big beautiful macros.

Then the language matured, and grew more powerful features than macros and other preprocessor goodies. And programmers
started dealing with old-style code that had hit macros' many problems. They started teaching "don't abuse macros".
Apparently you cannot distinguish between "macros" and "preprocessor-based"
templates. But maybe you actually can, but it just doesn't quite fit you agenda
to dismiss preprocessor-based templates out of hand. Can I call em or what?
I see right through you. And you're not fooling anyone.
So every semester these newsgroups field questions from students learning to abuse macros. All the responders here know the
rhetoric to explain when and how to use better techniques (enumerations, inline methods, templates, etc.). So when someone
starts arguing with this very polished rhetoric in ways that prove they are not listening or trying to understand what we
are saying, we tune out. This is probably what happened to your thread on clcm, regardless of each post's flame counts.
Beautiful example of 'paradigm'. Thank you.
Bouncing all your posts after that spike in flames was a way to give you a cooling off period. Accept it gracefully.
Attempt to turn the table. I bet you think you're pretty clever huh. Perhaps
since the clc++m participants need time to regroup after not being able to
make any substantive points on the matter? Things that make you say
"hmmm....".

I also have scripts associated with 'Template' menu choices that expand templates,
copy/delete/paste them. I'd be OK with just having the templates put in the "right"
place rather than having mechanisms to control where/when templates get
expanded (I think).

You might put such creativity into learning to use and understand the language's various features better.

As if I don't. I'm replacing them.
You are currently playing with your editor in ways that generate code that will rapidly become brittle and hard to change
over time.

Cute condescension tactics. You've shown your colors well.

Congratulations, you've managed to type a lot of words and add nothing to the
topic of substance.

Ted

[Phlip]

Ted wrote:

That's a pardigmic statement that just wreaks of poor engineering
judgment.
paradigmic, reeks.

Please grow up.
Plonk.<

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Ted]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message news:kM******************************@speakeasy.ne t...

Ted wrote:

I'm putting the posts that follow here (hopefully they will follow here!) because
they were rejected in comp.lang.c++.moderated. It behooves anyone reading
them to first read the the thread of the same subject in clc++m to get the more
of the context.
This is a bad idea. Why not just post a summary of your issue. Very few of us want to read the cruft. The two postings I
read seem like it's a pissing contest.

Not at all. I use my own template implementation and the clc++m guys
can't find any significant point to make me "change my ways" and go
back to the legacy C++ templates. (Hehe, yes, "legacy" was on
purpose. It's a joke! Lighten up already!).
BTW, this sounds like an argument that ends in:
"I can write bad code in any language"
I find it quite elegant (in as much as the system components will allow).
You perhaps should think about it (as I think that you most likely have
not) before dismissing it out of hand. I obviously left C++ templates
behind for reasons. But I don't wanna look like I'm trying to sell the
idea to others (I'm not). At most, I started the thread to direct attention
to what I think is too much attention on the generic technique, and
probably at the expense of mind power on software design.
The point is, C++ is a single language with multiple use paradigms (by design).
And from my perspective, too much activity surronding "generic
programming".
"overuse of templates" depends on context and WILL end up in a testosterone fight if you don't narrow the discussion.
Well I just meant it in general. Probably in regards to the literature. It's
just one aspect. Personally, I think it should be used very judiciously
(as the other advanced features: don't use them until it hurts not to).
My reccomendation to the OP is to ignore the noise and try to focus on the signal.
Sometimes it's difficult to distinguish one from the other.
BTW - I don't post on c.l.c++m because a number of my posts have been rejected for rather stupid reasons in the past and
I'm no longer going to waste my time trying to help someone if it gets thrown in the bit bucket.
I sense some sensitivity there also. I wouldn't mind if they put posts "out-of-band"
when solidly questionable, but to drop them completely and at such a low threshold
makes me question the motives. I ask the hard questions and I'm not going to
apologize for that. It could be that many are just "in the box" and that certain
circles have become in-bred/weak or it could be more than that. Who knows. I'm not
going to worry about it.
Also, c.l.c is much faster at getting your answer, no waiting for a moderator. Also, I don't waste my time answering when
it has already been answered unless there is more to the topic. Yep, you get the occasional flame bait, but in general,
they're seldom and I don't have to bother reading them if I don't want to. c.l.c++m is for the static functors.

Ted

[Ted]

"Phlip" <ph******@yahoo.com> wrote in message news:SF**************@newssvr24.news.prodigy.net.. .

Ted wrote:

That's a pardigmic statement that just wreaks of poor engineering judgment.

paradigmic, reeks.

Please grow up.

Plonk.<

Good riddance.

Ted

[Ian Collins]

Ted wrote:

"Phlip" <ph******@yahoo.com> wrote in message news:1X******************@newssvr30.news.prodigy.c om...

Your second mistake was arguing with Kanze. Don't. _Discuss_ things, with folks closer to your level, before engaging a
lifer on that hard-headed newsgroup.

I don't argue. I always discuss. I never bow though.

Even when you are wrong?
That's not what he said. Not what he implied. The implication was clearly that the
features that C++ adds over C are all complex to implement. One reason I avoid
C++ templates is because of the implementation complexity in the compiler. I want
to know what other features are on that same order of complexity so I can decide
if I'll program around those also. So the follow up was very warranted and appropriate.
So you write your own compiler? If not, why are you concerned? Do you
stick with vinyl because CD replay is complex? ? I haven't used the optimization settings in my compiler for years.

The sentence adds no value,

It gives the other side of the story: that optimization isn't as required now that
memory and CPU performance is what it is today. Letting the statement stand
would be to allow the perception that optimization is key and always required
whereas today it is rarely needed. The statement does indeed add value: it
attempts to dispel a myth that is being attempted to justify "C++ templates".
Ever written code for an embedded device with cost constraints?

I can't see your point, would you rather write the same code any times
for different types?

and detracts from C++'s culture of performance.

That's a pardigmic statement that just wreaks of poor engineering judgment.

How? Compiler are designed to generate its best code with optimisation
on. Would you engineer a washing machine with several motors when one
can do the job?

Engineering without optimisation is very poor engineering. Or do you
like your code to resemble a Rowland Emett [1] machine?

[1] http://www.mech.mcmaster.ca/~nyet/emett/

--
Ian Collins.

[belvis]

Ted wrote:

One reason I avoid
C++ templates is because of the implementation complexity in the compiler.
I still don't get this. How does it matter to your effectiveness as a
programmer whether a feature in the compiler was difficult for someone
else to implement?

And of course, you can't use the
optimizer -- good optimization is more difficult than a simple
implementation of templates (without export).

It's a good thing most code doesn't require compiler optimization
any more huh.

And this attitude is triggering our troll detector.

? I haven't used the optimization settings in my compiler for years.

And because you don't need them, no one else does? Just like templates,
I guess.

Sounds like a design issue (you wanted some kind of ultra-sophisticated
container that required C++ template features?). If implementing containers
is difficult for you without C++ features, then I'd seriously reconsider your
container design.

"difficult for you" is a common technical flame. Sorry if you thought it was original (and, yes, I have been openly flamed
on news:comp.lang.c++.moderated before...)

He couldn't do it and I could.

In his very first post to your thread on c.l.c++.m he said he had used
the preprocessor to generate generic code. Do you think he was lying?

If you can't prove "10 times more work", than I'd suggest you don't say
that anymore. Perhaps FOR YOU it's 10 times more work because you
don't know how to do it.

"don't say that anymore" and "you don't know how to do it" are simple flames. There were ways to say the same thing
politely, that lead the responder.

Sorry. I'm not buying your spiel. Is it 10 times more work or not?

I don't know; what if it's only 9 times more work? Would that make you
right? How about 8 times?

Instead of getting hung up on trivialities like whether it's 10 times
more work or not, you should pay attention to the meat of the point,
which is: Preprocessor-generated generic code is more work than using
templates.
Saying "10 times more work" means that you either are exaggerating or that
you don't know how to do it.
You left out "or that you do know how to do it and chose to use a
casual idiom to express its difficulty."
Which is it? This needs clarification because
Because Ted would rather pick on conversational idioms than address the
technical content.
it is being used as reason why preprocessor-based templates are deficient
compared to C++ templates. It's misinformation for the uninitiated coming
into the group and reading that.

How can you seriously consider a common colloquialism like "10 times"
(meaning "a lot more", not a literal numerical factor) to be _more_
misinformative than advising that a major component of C++ should be
avoided in favor of an inferior manual replacement?

Bob

[Gianni Mariani]

Ted wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message news:kM******************************@speakeasy.ne t...

... Why not just post a summary of your issue. ...

.... Not at all. ...

Please summarize your issue. I have no idea what your problem is.

[Ted]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message news:4Z******************************@speakeasy.ne t...

Ted wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message news:kM******************************@speakeasy.ne t...

... Why not just post a summary of your issue. ...

...

Not at all. ...

Please summarize your issue. I have no idea what your problem is.

No problem. They censored the posts and I put them here. Anyone can
now read the thread and draw their own conclusions. I'm not going to
post big-picture-related stuff in clc++m anymore because they can't
deal with it. If they just want to be "tech support", fine, no skin off my
nose.

Ted

[Ted]

<be****@pacbell.net> wrote in message news:11**********************@i40g2000cwc.googlegr oups.com...

[omitted]

Your defensive logic doesn't deserve response.

Ted

[Ted]

"Ian Collins" <ia******@hotmail.com> wrote in message news:11***************@drone2-svc-skyt.qsi.net.nz...

Ted wrote:

"Phlip" <ph******@yahoo.com> wrote in message news:1X******************@newssvr30.news.prodigy.c om...

So you write your own compiler? If not, why are you concerned? Do you
stick with vinyl because CD replay is complex?
I avoid some C++ features that are unnecessarily complex (and I'll probably be
avoiding more of them in the future).

? I haven't used the optimization settings in my compiler for years.

The sentence adds no value,

It gives the other side of the story: that optimization isn't as required now that
memory and CPU performance is what it is today. Letting the statement stand
would be to allow the perception that optimization is key and always required
whereas today it is rarely needed. The statement does indeed add value: it
attempts to dispel a myth that is being attempted to justify "C++ templates".

Ever written code for an embedded device with cost constraints?

Ever seen a product that was designed to be so general or so full of "features"
that it was a PITA to use in any application?
I can't see your point, would you rather write the same code any times
for different types?

Go back and read the whole thread. (I use preprocessor-based templates).

Ted

[Ian Collins]

Ted wrote:

"Ian Collins" <ia******@hotmail.com> wrote in message news:11***************@drone2-svc-skyt.qsi.net.nz...

Ted wrote:

"Phlip" <ph******@yahoo.com> wrote in message news:1X******************@newssvr30.news.prodigy.c om...

So you write your own compiler? If not, why are you concerned? Do you
stick with vinyl because CD replay is complex?

I avoid some C++ features that are unnecessarily complex (and I'll probably be
avoiding more of them in the future).

Complex to whom?? I haven't used the optimization settings in my compiler for years.

The sentence adds no value,

It gives the other side of the story: that optimization isn't as required now that
memory and CPU performance is what it is today. Letting the statement stand
would be to allow the perception that optimization is key and always required
whereas today it is rarely needed. The statement does indeed add value: it
attempts to dispel a myth that is being attempted to justify "C++ templates".

Ever written code for an embedded device with cost constraints?

Ever seen a product that was designed to be so general or so full of "features"
that it was a PITA to use in any application?

I'll take that as a no.

I can't see your point, would you rather write the same code any times
for different types?

Go back and read the whole thread. (I use preprocessor-based templates).

I did, not that it made much sense. Mainly piss and wind, completely
lacking in real world examples.

All in all one of the most successful trolls I've seen in these parts
for a long while. Ever tried stand-up comedy?

--
Ian Collins.