View mode: basic / threaded / horizontal-split · Log in · Help
July 30, 2004
Re: Minor gripe with template programming...
In article <ceeju2$8bp$1@digitaldaemon.com>, Gold Dragon says...
>
>I think that I will apply this to whatever I do from now on but one 
>problem I can think of is what if you have a constant of the same name? 
>Yeah, scope will come in to play but what if you want to use the 
>constant and not the template member? Constants could be written as
>
>#   const int iKTOMB = 1024;

Dear God, please no hungarian notation.

>I do believe some programmers absolutely hate it with a passion that 
>would force the said programmer into a rage destroying whole villages 
>and such. I think they are the minority but with a big voice.

Then consider me in that minority :)  I've found that such things just lend to
confusing variable names that are very brittle as the variable name needs to
change if the underlying type changes.  Really, the type of any variable should
be pretty much self explanatory from the name and/or context without such
conventions.


Sean
July 31, 2004
Re: Minor gripe with template programming...
I tend to use mixed-case-first-letter-upper-case (eg FooBar) for types and
mixed-case-first-letter-lower-case (eg fooBar) for functions. I think the
"D style guide" has the same rules. And I can't think of a good reason why
template parameters should be treated any differently from anything else.
All-caps (eg FOOBAR) means const or preprocessor symbol.

Looking at my STL include headers on my RedHat 9 distro they use things like
template<typename _InputIterator> ...
and
template<typename _Key, typename _Val, ...>
so aside from milliions of _ floating around it is semi-readable.

Matthew wrote:

> Please don't! Having mixed case identifiers would be the worst of all
> possibilities, since they could look like type (or function) names
> 
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message
> news:cedn96$2n8b$1@digitaldaemon.com...
>> sure. sounds reasonable. I'll change my Map types to Key and Value and
>> the List type from T to ...hmmm... Value. Now that you mention it it does
>> seem wierd to have T in List and V in Map.
>>
>> "Berin Loritsch" <bloritsch@d-haven.org> wrote in message
>> news:cedkrk$2lu2$1@digitaldaemon.com...
>> > This is something that has always been a gripe of mine with most
>> > examples of template/generic programming: why do people insist on
>> > using just one character for the type?  Take for example your
>> > typical map:
>> >
>> > Map!(K key, V value)
>> >
>> > or worse:
>> >
>> > Map!(K k, V v)
>> >
>> > To me this is not really understandable.  Sure its generic, but
>> > generic programming does support more than one character for
>> > your type information.
>> >
>> > Do you think it would be reasonable to use a type name that described
>> > the role of the type in the template?  It really goes a long way into
>> > making it more readable.  The Map would be written more like this:
>> >
>> > Map!(KEY k, VALUE v)
>> >
>> > or something like that.  I do like to make it clear that the types
>> > are template types by the all caps or some other mechanism like this:
>> >
>> > Map!(key_t key, value_t value)
>> >
>> > However it feels most comfortable.
>> >
>> > I am just sick of seeing functions, classes, etc. that just use one
>> > letter for a generic type.  This is the greatest disservice that C++
>> > STL has foisted on the poor unsuspecting developer.
>> >
>> > For example, what is this function supposed to do?:
>> >
>> > doSomething(T val, A!(T) acc, Map!(A!(T), T) map);
>> >
>> >
>> > The name used for the type provides semantic clues to help understand
>> > the code.  There should be no reason to write obfuscated code for D's
>> > libraries.  At least, I hope I can influence DTL while it is still
>> > young...
>>
>>
July 31, 2004
Re: Minor gripe with template programming...
Ben Hinkle wrote:
> 
> Looking at my STL include headers on my RedHat 9 distro they use things like
>  template<typename _InputIterator> ...
> and
>  template<typename _Key, typename _Val, ...>
> so aside from milliions of _ floating around it is semi-readable.

And for the STL the leading underscore and initial capital are pretty 
much required.  I've come around to the meaningful template parameter 
idea.  It's really not so bad.


Sean
July 31, 2004
Re: Minor gripe with template programming...
Sean Kelly wrote:
> In article <ceeju2$8bp$1@digitaldaemon.com>, Gold Dragon says...
> 
>>I think that I will apply this to whatever I do from now on but one 
>>problem I can think of is what if you have a constant of the same name? 
>>Yeah, scope will come in to play but what if you want to use the 
>>constant and not the template member? Constants could be written as
>>
>>#   const int iKTOMB = 1024;
> 
> 
> Dear God, please no hungarian notation.
> 
> 
>>I do believe some programmers absolutely hate it with a passion that 
>>would force the said programmer into a rage destroying whole villages 
>>and such. I think they are the minority but with a big voice.
> 
> 
> Then consider me in that minority :)  I've found that such things just lend to
> confusing variable names that are very brittle as the variable name needs to
> change if the underlying type changes.  Really, the type of any variable should
> be pretty much self explanatory from the name and/or context without such
> conventions.
> 
> 
> Sean
> 
> 

Well, is it better than having nothing to tell what type the variable is 
at all? My teachers have pounded it into my skull with a cast iron to 
name my variables as describtive as possible but I would still like to 
know what type I'm dealing with. The projects that I work with aren't 
that big.

What do you use? I'm all for protocol and paradigm but damn, it does get 
old.
July 31, 2004
Re: Minor gripe with template programming...
Gold Dragon wrote:
> 
> Well, is it better than having nothing to tell what type the variable is 
> at all? My teachers have pounded it into my skull with a cast iron to 
> name my variables as describtive as possible but I would still like to 
> know what type I'm dealing with. The projects that I work with aren't 
> that big.
> 
> What do you use? I'm all for protocol and paradigm but damn, it does get 
> old.

In my experience, type is pretty easily determined by name and context. 
 And that is in the rare cases where globals or other hard to find 
variables are concerned.  If I'm still at a loss and knowing the type is 
really that important it's usually pretty easy to do a file search to 
find the declaration.  The only convention I've used in the past is a 
leading m_ for non-public member variables and sm_ for non-public static 
member variables.  This makes it easy (to me) to determine the scope of 
a variable I might be using, which is mostly what I've found useful as 
naming clashes between local function variables and class-level 
variables can be a confusing source of bugs.  ie.

# class X {
# public:
#   void setX( int x ) { x = x; }
# private:
#   int x;
# }

Simplistic example, but in the above, the assignment would have to be 
"this.x = x;" to work as intended.  Some people prefer to always use the 
"this" specifier for class member stuff, which is another convention 
I've used from time to time.


Sean
August 02, 2004
Re: Minor gripe with template programming...
Gold Dragon schrieb:
> I think that I will apply this to whatever I do from now on but one 
> problem I can think of is what if you have a constant of the same name? 
> Yeah, scope will come in to play but what if you want to use the 
> constant and not the template member? Constants could be written as

Why only constants? This applies to anything. Preprocessor and any 
header inclusion madness are lost, whetever is defined in a template 
library won't get overridden by a user-space constant or global or whatever.

In my taste, there's no sense to make any visible distinction between 
constant and a variable as long as language can sort it out at least 
nearly as reliably.

> That would make unsigned with a ui, uc, etc. structs with st(_) and so 
> on. That would give some readability to the overall code would templates 
> be referenced with a 't', followed by the name? Seems interesting 

In my personal expierience it distracts and eats up all the readability 
that was left. More on that below.

> concept that goes against the paradigm that has govern programming since 
> when people didn't have the liberty to use more than 16-64 characters 
> for variable names (I would know nothing of that time since I was a 
> little baby).

It doesn't go against any paradigm of short names. It follows it, as 
well as a paradigm of most generic and senseless names, also popular at 
all times. If a programmer runs over a spot where he would name 2 things 
similarly, he has 2 choices:
(a) he comes up with an imaginative, usually much longer names, which 
are more descriptive and show the difference in the sense these 
variables make; or
(b) he appends a symbol or 2 to one or both of the names. Sometimes this 
can be an appropriate common case (like member variables etc.), but 
usually he will just notice that the variables which were supposed to 
have the same name (but different sense!) have somewhat different types, 
so he goes ahead and disambiguates them by adding some hungarian 
notation. Hurray, a few keystrokes saved at the cost of clarity! And one 
didn't even have to use the brain cells!

> I do believe some programmers absolutely hate it with a passion that 
> would force the said programmer into a rage destroying whole villages 
> and such. I think they are the minority but with a big voice.

Hungarian notation is not as helpful as generally considered in C++ and 
D, though it did make major sense in C imo, and it goes against some 
non-trivial common sense, as shown above. So you just going ahead and 
dissing the othrers as barbarians isn't nice either. "We are the 
bolshevik, we are more so we must be right, and can trample down the 
others"... pfft!

BTW, you didn't even count the people who are for/against hungarian 
notation, so how can you just say that there are less of those against? 
And why do you think they have such a big voice? Perhaps because that 
are people who make sense to listen to? People writing major libraries, 
people who explore the edge of possible, leading magazine contributors, 
experts?

-eye the photoallergic
August 03, 2004
Re: Minor gripe with template programming...
Gold Dragon wrote:
> I think that I will apply this to whatever I do from now on but one 
> problem I can think of is what if you have a constant of the same name? 
> Yeah, scope will come in to play but what if you want to use the 
> constant and not the template member? Constants could be written as
> 
> #   const int iKTOMB = 1024;
> 

I am not in favor of hungarian notation.  I am only in favor of having
a name represent the type rather than a single character.  When you get
when there is a compile error is some terse and unhelpful message that
says type 'T' fails in some way.  When all you see is 'T' as the type,
it makes it seem quite unweildy.

However you choose to distinguish between a Type and a variable/function
is ok by me.  I don't know about you, but when I look at the source code
for templates, I get lost on exactly what is trying to be accomplished.
THat is because you lose some semantic clues due to the type name being
T instead of something more helpful.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home