By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,031 Members | 1,016 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,031 IT Pros & Developers. It's quick & easy.

generic programming is very powerful. c should support it

P: n/a
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.

Jul 26 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a

steve yee wrote:
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.
I don't get this comment. You want C to become C++ so it could replace
C++? It WOULD BE C++.

What do you like about C that isn't in C++?

Tom

Jul 26 '06 #2

P: n/a
Tom St Denis wrote:
>
What do you like about C that isn't in C++?

Tom
Simplicity.

No automatic constructors, no OO orientation.

C has a lot of advantages.

Jul 26 '06 #3

P: n/a

jacob navia wrote:
Tom St Denis wrote:

What do you like about C that isn't in C++?

Tom

Simplicity.

No automatic constructors, no OO orientation.

C has a lot of advantages.
yes. what i mean is that c can adapt template and namespace from c++,
because it's very useful and does not hurt the simplicity of c. this
will not make c become c++, because there's much more than generic and
namespace in c++'s feature.

Jul 26 '06 #4

P: n/a

steve yee wrote:
jacob navia wrote:
Tom St Denis wrote:
>
What do you like about C that isn't in C++?
>
Tom
>
Simplicity.

No automatic constructors, no OO orientation.

C has a lot of advantages.

yes. what i mean is that c can adapt template and namespace from c++,
because it's very useful and does not hurt the simplicity of c. this
will not make c become c++, because there's much more than generic and
namespace in c++'s feature.
Adding a turing complete sub-language won't hurt the simplicity of C?

Jul 26 '06 #5

P: n/a
steve yee <yi******@gmail.comwrote:
i think c should adapt c++ template standard, as well as namespace. if
How do you propose to make use of templates without introducing the
notion of a class?

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jul 26 '06 #6

P: n/a
On Wed, 26 Jul 2006, steve yee wrote:
>
jacob navia wrote:
>Tom St Denis wrote:
>>>
What do you like about C that isn't in C++?

Tom

Simplicity.

No automatic constructors, no OO orientation.

C has a lot of advantages.

yes. what i mean is that c can adapt template and namespace from c++,
because it's very useful and does not hurt the simplicity of c. this
will not make c become c++, because there's much more than generic and
namespace in c++'s feature.
I don't get it. If you want templates and namespaces, why don't you use a
subset of C++ (namely, C++ without the OO approach) ? It'd be some kind of
subset of C with additional things (such as ... templates and namespaces
for instance).

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais
ce que je veux !"
"The obvious mathematical breakthrough would be development of an easy way
to factor large prime numbers." (Bill Gates, The Road Ahead)
Jul 26 '06 #7

P: n/a

Christopher Benson-Manica wrote:
steve yee <yi******@gmail.comwrote:
i think c should adapt c++ template standard, as well as namespace. if

How do you propose to make use of templates without introducing the
notion of a class?
Templates aren't restricted to classes, though their usefulness
decreases considerably when all you have are function templates. In
theory, you could apply a template to a structure, though that strikes
me as awkward in the absence of member functions. Of course, there are
times when I've yearned for member functions in C. Maybe the OP is
looking for a watered down class concept too. ;-)
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jul 26 '06 #8

P: n/a
steve yee schrieb:
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.
There is no function overloading in C. C++ templates without that would
not be useful.

Why don't you just use C++, since C++ has adopted most of the standard
library of C?

--
Thomas
Jul 26 '06 #9

P: n/a


steve yee wrote On 07/26/06 09:01,:
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.
Make a formal proposal to the Committee. Be sure to
let us know how you get on with them, will you? 'bye, now!

--
Er*********@sun.com

Jul 26 '06 #10

P: n/a
"Julienne Walker" <ha*********@hotmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
>yes. what i mean is that c can adapt template and namespace from c++,
because it's very useful and does not hurt the simplicity of c.

Adding a turing complete sub-language won't hurt the simplicity of C?
hahaha indeed, templates are very very powerful but only if you would add a
pile of other c++ features too. function/operator overloading, member
functions, default arguments etc. You'll basically end up with C++ so why
not just use that then!
Jul 26 '06 #11

P: n/a
steve yee wrote:
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.
namespaces I agree with. In fact, its one of those obvious
self-contained features from C++ that isn't really OO related and
solves a real problem that exists in C. (Unlike arbitrarily locatable
declarations, which exists in C++ specifically to solve a problem with
constructors.) References are another feature that would be nice to
take from C++ that is similarly self-contained and not really OO
related.

But C++'s templates operate on classes, and really kind of needs to use
them, so I don't know how you could do that without making C really
close to C++. However, I do agree that generic programming is
extremely powerful, and should be supported. The good news is that, to
a large extent, it *IS* supported via the preprocessor.

For example, see:

http://www.pobox.com/~qed/ll.zip

and

http://www.pobox.com/~qed/gstack.zip

These are general stacks and linked lists, in which you can at compile
time simply select the base data type. The macros emit a bunch of
functions which interface to a void * based back end. This allows the
interface to be type-safe, while using the unsafe void * type to unify
the back-end code (to be space efficient.) C++ only has the type-safe,
code replication semantics available to it. On the other hand C++'s
automatic constructor/destructor semantics help a lot -- with the two C
libraries above, it is assumed that you deal with allocation and
deallocation of the elements yourself.

So, they are somewhat complicated to set up in C, but it is certainly
possible. And I recommend doing so whenever it makes sense.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jul 26 '06 #12

P: n/a
we******@gmail.com wrote:
>
But C++'s templates operate on classes, and really kind of needs to use
them, so I don't know how you could do that without making C really
close to C++.
There are function templates as well as class templates.

--
Ian Collins.
Jul 26 '06 #13

P: n/a
In article <11**********************@b28g2000cwb.googlegroups .com>,
<we******@gmail.comwrote:
>namespaces I agree with. In fact, its one of those obvious
self-contained features from C++ that isn't really OO related and
solves a real problem that exists in C. (Unlike arbitrarily locatable
declarations, which exists in C++ specifically to solve a problem with
constructors.)
Although arbitrarily locatable declarations may not solve a semantic
problem in C, as a programmer I like to have them.

It is fairly common to not need variables until relatively far into a
function; it is useful to be able to hold off declaration of the
variables until a convenient logical point. It makes coding simpler
than having to go back to the beginning to add in a variable, and it
leaves the type information close to where the information is required
instead of having to search back for it.

One can simulate them in C by using blocks and declaring the variable
at the beginning of the block, but that pushes the indentation level
further in.
--
All is vanity. -- Ecclesiastes
Jul 26 '06 #14

P: n/a
Walter Roberson wrote:
In article <11**********************@b28g2000cwb.googlegroups .com>,
<we******@gmail.comwrote:

>>namespaces I agree with. In fact, its one of those obvious
self-contained features from C++ that isn't really OO related and
solves a real problem that exists in C. (Unlike arbitrarily locatable
declarations, which exists in C++ specifically to solve a problem with
constructors.)


Although arbitrarily locatable declarations may not solve a semantic
problem in C, as a programmer I like to have them.

It is fairly common to not need variables until relatively far into a
function; it is useful to be able to hold off declaration of the
variables until a convenient logical point. It makes coding simpler
than having to go back to the beginning to add in a variable, and it
leaves the type information close to where the information is required
instead of having to search back for it.

One can simulate them in C by using blocks and declaring the variable
at the beginning of the block, but that pushes the indentation level
further in.
You have them with C99.

--
Ian Collins.
Jul 26 '06 #15

P: n/a
"steve yee" <yi******@gmail.comwrites:
i think c should adapt c++ template standard, as well as namespace. if
so, c can replace c++ in many cases.
First rule of language design: You can't change just one thing.

(Ok, I don't know if that's really considered the "first rule".)

I can see that introducing C++-style namespaces might be a reasonable
thing to do, that wouldn't necessarily do too violence to the rest of
the language or to existing code. (I could be missing something,
though; I haven't taken the time to think it through.)

Templates, however, seem more complex, and probably more tied into the
rest of C++ (specifically to the portions of C++ outside the C-like
subset).

Remember that C++ started as "C with classes". What you're proposing
is "C with templates" (except that you want this to become "C" some
day).

If you're serious about this, you'll need to demonstrate existing
practice.

The simplest approach is to write a body of code in C++, but
restricting yourself to the C-like subset of C++ plus templates.
(Programming in the intersection of C and C++ is rarely a good idea,
but it would be useful here.) If you can demonstrate that this has
substantial benefits over plain C, you may have something.

You might consider implementing a C++ filter that will flag anything
outside your dialect. For example, it would reject anything using
classes. This filter combined with a C++ compiler would be a compiler
for your "C with templates" dialect.

Another approach would be to implement a preprocessor, similar to
Stroustrup's cfront, that would translate your dialect into conforming C.

Of course, even if no standard committee ever expresses any interest
in this, there's nothing stopping you from using it yourself, or
making it available to others.

Language changes start with somebody having a good idea, but they
never end there. (Or rather, they usually do end there, and go no
further.) There's a lot of work to do after that; you'll need either
to do it yourself, or to persuade someone else to do it. I can just
about guarantee that the C standard committee isn't going to say, "Oh
good, let's add templates!" without a lot of persuasion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 26 '06 #16

P: n/a
In article <ea**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
>steve yee <yi******@gmail.comwrote:
>i think c should adapt c++ template standard, as well as namespace. if

How do you propose to make use of templates without introducing the
notion of a class?
By writing type-generic code once and using it type-safely for different
types, which works just as well for functions as it does for classes.

If you make the template parameters part of the function's name, you
don't even have to introduce overloading, though that does require the
template parameters at every use of the template instead of having the
template function be an overloaded function named by the template name.

--------
/*Generic template for scalar types*/
template<typename T>
int less<T>(const T *left, const T *right)
{ return *left < *right; }

/*Specialization of less<>() for struct foo*/
int less<struct foo>(const struct foo *left,const struct foo *right)
{ return (left->A < right->A) || (left->B < right->B); }

/*Templated sort function
(with default parameter, but that's not a strictly necessary feature)
*/
template<typename T,int (*pred)(const T *,const T *)=less<T
void bogosort<T,pred>(T *data, size_t length)
{
for(;;)
{
int sorted=1;
int i;

for(i=0;i<length-1;i++)
if(pred<T>(data+i+1,data+i))
sorted=0;
if(sorted)
return;

shuffle<T>(data,length);
}
}

void sort_contents(struct three_arrays *args)
{
/*sort an array of int in increasing order*/
bogosort<int>(args->int_array,args->int_size);

/*sort an array of double in arbitrary order*/
bogosort<double,my_ordering>(args->double_array,args->double_size);

/*Sort an array of struct foo in increasing order*/
bogosort<struct foo>(args->foo_array,args->foo_size);
}
--------

If I'm not mistaken, a C++-style template syntax doesn't even give
a different interpretation to anything that's not a syntax error in C
(though you'd have to choose between introducing new keywords and having
to call it _Template - but we could probably use static for typename).
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
And, if we're prepared to assume that the user is a Unix guy, we can
optimise a little further by simply not writing the program at all.
--Richard Heathfield in comp.lang.c
Jul 28 '06 #17

P: n/a
Dave Vandervies wrote:
In article <ea**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
>>steve yee <yi******@gmail.comwrote:

>>>i think c should adapt c++ template standard, as well as namespace. if

How do you propose to make use of templates without introducing the
notion of a class?


By writing type-generic code once and using it type-safely for different
types, which works just as well for functions as it does for classes.

If you make the template parameters part of the function's name, you
don't even have to introduce overloading, though that does require the
template parameters at every use of the template instead of having the
template function be an overloaded function named by the template name.

--------
/*Generic template for scalar types*/
template<typename T>
int less<T>(const T *left, const T *right)
{ return *left < *right; }
Templates may work fine for functions, but you open the function
overload/name mangling can of worms. You would also end up with all of
the messy name resolution rules from C++.

--
Ian Collins.
Jul 28 '06 #18

P: n/a
Christopher Benson-Manica wrote:
steve yee <yi******@gmail.comwrote:
i think c should adapt c++ template standard, as well as namespace. if

How do you propose to make use of templates without introducing the
notion of a class?

<OT>

I suppose plain 'ol generic functions? In the presence of function
overloading I'd expect something like this

header:
void foo (<Xarg1, <Yarg2);

implementation:
void foo (int arg1, float arg2) { ... }
void foo (int arg1, int arg2) { ... }
void foo (struct mystruct arg1, int arg2) { ... }
Although it'd be a pain to write a function
definition for all the types of arguments that
the generic function "foo" can be called with.
goose,

Jul 28 '06 #19

P: n/a
"goose" <ru**@webmail.co.zawrites:
Christopher Benson-Manica wrote:
>steve yee <yi******@gmail.comwrote:
i think c should adapt c++ template standard, as well as namespace. if

How do you propose to make use of templates without introducing the
notion of a class?

<OT>

I suppose plain 'ol generic functions? In the presence of function
overloading I'd expect something like this

header:
void foo (<Xarg1, <Yarg2);

implementation:
void foo (int arg1, float arg2) { ... }
void foo (int arg1, int arg2) { ... }
void foo (struct mystruct arg1, int arg2) { ... }
Although it'd be a pain to write a function
definition for all the types of arguments that
the generic function "foo" can be called with.
That doesn't look like a template; it looks like function overloading
with an odd syntax. In a C++, you can write a single implementation
and the compiler will expand it for each instance.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 28 '06 #20

P: n/a
In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>Dave Vandervies wrote:
>In article <ea**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
>>>How do you propose to make use of templates without introducing the
notion of a class?


By writing type-generic code once and using it type-safely for different
types, which works just as well for functions as it does for classes.

If you make the template parameters part of the function's name, you
don't even have to introduce overloading, though that does require the
template parameters at every use of the template instead of having the
template function be an overloaded function named by the template name.

--------
/*Generic template for scalar types*/
template<typename T>
int less<T>(const T *left, const T *right)
{ return *left < *right; }
Templates may work fine for functions, but you open the function
overload/name mangling can of worms.
There's no overloading happening here (less<intand less<doubleare
two different functions with two different names; the only difference
from writing less_int and less_double is that the programmer only has
to write the template code once and the compiler handles rewriting it
for every type used), and name mangling can be as simple as replacing
the punctuators with something that the linker will handle gracefully
(say, less$int and less$double, if the linker will treat $ as part of
an identifier).
You would also end up with all of
the messy name resolution rules from C++.
Not having objects or inheritance makes template name resolution rules
a lot simpler; you could probably do it with just these:

If there is a fully specialized template for these parameters, use it.
(Having more than one fully specialized template for the same parameters
would be easily checkable and should probably be a constraint violation)
If there is no fully specialized template, and exactly one partially
specialized one, that matches these parameters
(ex. bogosort<double,predor bogosort<T,my_compare_function>), use
that partially specialized one.
If there are more than one partially specialized templates that match
these parameters, the behavior is undefined. (A smart compiler could
detect the condition and complain; a less clever compiler could make
an arbitrary choice about which one to use.)
If there are no fully or partially specialized templates that match the
parameters but there is a fully generic one, use it. (Parameters are
either type names or constant expressions of a specific type, so
there's no ambiguity about whether it matches.)
Attempting to use a template with no matching definition is a constraint
violation.

I don't know the C++ rules, but I'd expect most of the messiness comes
from interactions with overloading and inheritance.

There's nothing in templates that requires objects and inheritance or
overloading, and leaving those out makes specifying the templates a lot
easier (because it reduces the amount of non-obvious interaction rules
that need to be gotten right)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Hide the distillery behind the desk, run a beige tube to your wireless keyb.
Flip up the capslock key to insert the drinking straw.
--Chris Hacking in the scary devil monastery
Jul 28 '06 #21

P: n/a
Dave Vandervies wrote:
In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>>
Templates may work fine for functions, but you open the function
overload/name mangling can of worms.


There's no overloading happening here (less<intand less<doubleare
two different functions with two different names; the only difference
from writing less_int and less_double is that the programmer only has
to write the template code once and the compiler handles rewriting it
for every type used), and name mangling can be as simple as replacing
the punctuators with something that the linker will handle gracefully
(say, less$int and less$double, if the linker will treat $ as part of
an identifier).
But there is, you have already introduced name mangling required to
resolve overloads of the template less. If you are going to introduce
generics, would you have to introduce some form of name mangling, which
would have to be standardised.

Once you start down the generics road, you'd end up having to support
concrete overloads of less.
>
> You would also end up with all of
the messy name resolution rules from C++.

Not having objects or inheritance makes template name resolution rules
a lot simpler; you could probably do it with just these:

If there is a fully specialized template for these parameters, use it.
(Having more than one fully specialized template for the same parameters
would be easily checkable and should probably be a constraint violation)
If there is no fully specialized template, and exactly one partially
specialized one, that matches these parameters
(ex. bogosort<double,predor bogosort<T,my_compare_function>), use
that partially specialized one.
If there are more than one partially specialized templates that match
these parameters, the behavior is undefined. (A smart compiler could
detect the condition and complain; a less clever compiler could make
an arbitrary choice about which one to use.)
If there are no fully or partially specialized templates that match the
parameters but there is a fully generic one, use it. (Parameters are
either type names or constant expressions of a specific type, so
there's no ambiguity about whether it matches.)
Attempting to use a template with no matching definition is a constraint
violation.
Don't forget normal functions that match.
I don't know the C++ rules, but I'd expect most of the messiness comes
from interactions with overloading and inheritance.
Not in the case of functions templates.
There's nothing in templates that requires objects and inheritance or
overloading, and leaving those out makes specifying the templates a lot
easier (because it reduces the amount of non-obvious interaction rules
that need to be gotten right)
Inheritance is a red herring, we are talking about function templates
here, which would require some form of name disambiguation.

Either way, none of this belongs in C, if you want templates, use C++.

--
Ian Collins.
Jul 28 '06 #22

P: n/a
In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>Dave Vandervies wrote:
>In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>>>
Templates may work fine for functions, but you open the function
overload/name mangling can of worms.

There's no overloading happening here (less<intand less<doubleare
two different functions with two different names; the only difference
from writing less_int and less_double is that the programmer only has
to write the template code once and the compiler handles rewriting it
for every type used), and name mangling can be as simple as replacing
the punctuators with something that the linker will handle gracefully
(say, less$int and less$double, if the linker will treat $ as part of
an identifier).
But there is, you have already introduced name mangling required to
resolve overloads of the template less.
What overloads? Did you actually read what I wrote? less<intand
less<doubleare DIFFERENT FUNCTIONS with DIFFERENT NAMES; what are
we overloading?
If you are going to introduce
generics, would you have to introduce some form of name mangling,
By "some form of name mangling", you of course mean "some way to give
template instantiations consistent and distict names". Which isn't too
difficult; we already have to do that for non-templated functions, and it
already happens differently on different implementations. The difference
is just that instead of translating "less_int" into "less_int" or
"_less_int" or "LESS_I" or "936487bc033df3520d102a0e104cb07f", we're
translating "less<int>" into "less<int>" or "less$int" or "_less__int" or
"LESS$I" or "1783a8022d580e099f8acd28f7a58755".
which
would have to be standardised.
Neither C nor C++ have standardised the conversion between names-as-
they-appear-in-the-source and names-as-they-appear-to-the-linker, and
it hasn't hurt either language, so why would this need to be standardised?

>Once you start down the generics road, you'd end up having to support
concrete overloads of less.
Really? How and why?

>> You would also end up with all of
the messy name resolution rules from C++.

Not having objects or inheritance makes template name resolution rules
a lot simpler; you could probably do it with just these:
[snip]
>Don't forget normal functions that match.
I don't know what language you're talking about, but the C that I'm used
to working with doesn't have normal functions with names that look like
"less<int>" or "bogosort<double,my_function>".

>There's nothing in templates that requires objects and inheritance or
overloading, and leaving those out makes specifying the templates a lot
easier (because it reduces the amount of non-obvious interaction rules
that need to be gotten right)
Inheritance is a red herring, we are talking about function templates
here, which would require some form of name disambiguation.
"less<intis the template `less' with the parameter int, less<double>
is the template `less' with the parameter double" isn't good enough?
What's the ambiguity that you're trying to resolve?

If I'm missing something here, please point it out. If you're just
getting confused because you missed the part where I suggested making
the template parameters part of the function's name instead of using
type inference, then go back and read what I wrote (ALL of it) before
you start arguing with something almost but not entirely unlike what I
actually said.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I suppose that if I still haven't convinced someone of my point, that I will
not be able to. And so, if necessary, I yield the field in frustration.
--AJS in the scary devil monastery
Jul 29 '06 #23

P: n/a
Dave Vandervies wrote:
In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>>
But there is, you have already introduced name mangling required to
resolve overloads of the template less.

What overloads? Did you actually read what I wrote? less<intand
less<doubleare DIFFERENT FUNCTIONS with DIFFERENT NAMES; what are
we overloading?
Maybe I misunderstood your intent, the reason I implied some form of
overloading was that I assumed the functions would be called thus:

n = less( 1, 2 );

and

n = less( 1.0, 2.0 );

Where (as in C++) the compiler matches the correct template. If this is
the case you can also have a concrete function

int less( int, int )

adding to the resolution rules when the compiler encounters

n = less( 1, 2 );
>
> If you are going to introduce
generics, would you have to introduce some form of name mangling,

By "some form of name mangling", you of course mean "some way to give
template instantiations consistent and distict names". Which isn't too
difficult; we already have to do that for non-templated functions, and it
already happens differently on different implementations.
[snip]
>
I do. It isn't difficult, but can get a little messy when there is more
than one template parameter.
>
> which
would have to be standardised.

Neither C nor C++ have standardised the conversion between names-as-
they-appear-in-the-source and names-as-they-appear-to-the-linker, and
it hasn't hurt either language, so why would this need to be standardised?
True, but at least for C, the ABI is generally standardised per
platform, where C++ compilers all do their own thing. If C compilers
went the same way as C++, we'd loose one of C's greatest assets - the
ability to link between modules compiled with different compilers on the
same platform.
>
>>Once you start down the generics road, you'd end up having to support
concrete overloads of less.

Really? How and why?
The usage example above.
>
I don't know what language you're talking about, but the C that I'm used
to working with doesn't have normal functions with names that look like
"less<int>" or "bogosort<double,my_function>".
Are we talking about the declaration, or use of the function. I had
assumed the template type was implied, rather than explicit. This might
be the cause of this confusion.
>

"less<intis the template `less' with the parameter int, less<double>
is the template `less' with the parameter double" isn't good enough?
What's the ambiguity that you're trying to resolve?
Again, my assumption of template type being implied by the compiler.

--
Ian Collins.
Jul 29 '06 #24

P: n/a
In article <4j************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>Dave Vandervies wrote:
>In article <4i************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>Maybe I misunderstood your intent, the reason I implied some form of
overloading was that I assumed the functions would be called thus:

n = less( 1, 2 );

and

n = less( 1.0, 2.0 );

Where (as in C++) the compiler matches the correct template.
Ahh. That would account for the confusion; I had intended the templated
function to be called as
n=less<int>(1,2);
and
n=less<double>(1.5,2);
which leaves
n=less(1,2)
available for a concrete function.

If you have overloading already, letting the compiler do type inference
on template calls doesn't cost much and makes the programmer's life
a little bit easier; but the difference is only a matter of syntactic
sugar, and the low-sugar version is easier to specify cleanly.

>By "some form of name mangling", you of course mean "some way to give
template instantiations consistent and distict names". Which isn't too
difficult; we already have to do that for non-templated functions, and it
already happens differently on different implementations.
[snip]
>>
I do. It isn't difficult, but can get a little messy when there is more
than one template parameter.
Messy, but still fairly straightforward, which is a combination computers
are good at. (Though implementation limits would have to be carefully
thought out. The C++ compiler I use at work likes to warn me that it's
truncating symbols to 255 characters long in the debug information it
saves, and you'd run into the same kinds of problems with name handling
if templates were added to C.)

>> which
would have to be standardised.

Neither C nor C++ have standardised the conversion between names-as-
they-appear-in-the-source and names-as-they-appear-to-the-linker, and
it hasn't hurt either language, so why would this need to be standardised?
True, but at least for C, the ABI is generally standardised per
platform, where C++ compilers all do their own thing. If C compilers
went the same way as C++, we'd loose one of C's greatest assets - the
ability to link between modules compiled with different compilers on the
same platform.
That would make a difference, but not to the specification of the
language extension.
(It would require more coordination between different implementations
on a platform than just the "do/don't put a '_' in front" that most
platforms need to make names match up, though, and the C-with-templates
implementors would have to do a better job of it than the C++ implementors
did to make it work.)

>I don't know what language you're talking about, but the C that I'm used
to working with doesn't have normal functions with names that look like
"less<int>" or "bogosort<double,my_function>".
Are we talking about the declaration, or use of the function. I had
assumed the template type was implied, rather than explicit. This might
be the cause of this confusion.
That appears to be the case.

Unfortunately I don't know yacc and don't have a C parser readily
available; it seems to me that if I had those it would be possible to
build a C-with-templates precompiler that's ready for people to start
trying to break in a spare afternoon. (Getting something that's actually
hard to break would of course take a while longer.) The back-end would
be easy: convert template calls into calls to the instantiated function,
add all of the instantiations needed, and then spit the parse tree back
out as something you can feed to the C compiler. Learning the tools
and building a front-end would be Rather Harder (and take a lot longer)
than modifying an existing front-end, though.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
This seemed to me to be the smart and correct thing to do, which is why it
surprised me so.
--J.D. Baldwin in the scary devil monastery
Jul 29 '06 #25

P: n/a
Dave Vandervies wrote:
>
Unfortunately I don't know yacc and don't have a C parser readily
available; it seems to me that if I had those it would be possible to
build a C-with-templates precompiler that's ready for people to start
trying to break in a spare afternoon. (Getting something that's actually
hard to break would of course take a while longer.) The back-end would
be easy: convert template calls into calls to the instantiated function,
add all of the instantiations needed, and then spit the parse tree back
out as something you can feed to the C compiler. Learning the tools
and building a front-end would be Rather Harder (and take a lot longer)
than modifying an existing front-end, though.
Guess what I've just started a little project to investigate :)

--
Ian Collins.
Jul 29 '06 #26

P: n/a
In article <4j*************@individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>Dave Vandervies wrote:
>>
Unfortunately I don't know yacc and don't have a C parser readily
available; it seems to me that if I had those it would be possible to
build a C-with-templates precompiler that's ready for people to start
trying to break in a spare afternoon. (Getting something that's actually
hard to break would of course take a while longer.) The back-end would
be easy: convert template calls into calls to the instantiated function,
add all of the instantiations needed, and then spit the parse tree back
out as something you can feed to the C compiler. Learning the tools
and building a front-end would be Rather Harder (and take a lot longer)
than modifying an existing front-end, though.
Guess what I've just started a little project to investigate :)
Nifty. I was hoping somebody with the appropriate yacc-fu would be
inspired to do it. I know just enough about how it would be done to
wish I knew how to use the tools to do it.

I would be very interested in hearing how it works (and test-driving
it), and I suspect that the set of other readers of CLC who would as
well is nonempty.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

I perform daring feats of undefined behavior on the flying trapeze.
--Daniel Fox in comp.lang.c
Jul 29 '06 #27

P: n/a
Ian Collins wrote:
Walter Roberson wrote:
>In article <11**********************@b28g2000cwb.googlegroups .com>,
<we******@gmail.comwrote:

>>namespaces I agree with. In fact, its one of those obvious
self-contained features from C++ that isn't really OO related and
solves a real problem that exists in C. (Unlike arbitrarily locatable
declarations, which exists in C++ specifically to solve a problem with
constructors.)

Although arbitrarily locatable declarations may not solve a semantic
problem in C, as a programmer I like to have them.
And so many people (including me) hate them that gcc introduced
-Wdeclaration-after-statement in gcc4 ...
>>
It is fairly common to not need variables until relatively far into a
function; it is useful to be able to hold off declaration of the
variables until a convenient logical point. It makes coding simpler
than having to go back to the beginning to add in a variable, and it
leaves the type information close to where the information is required
instead of having to search back for it.

One can simulate them in C by using blocks and declaring the variable
at the beginning of the block, but that pushes the indentation level
further in.

You have them with C99.

--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mb*******@mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
Aug 10 '06 #28

P: n/a

"Michel Bardiaux" <mi*************@mediaxim.bewrote in message
news:Vc******************************@scarlet.biz. ..
And so many people (including me) hate them that gcc
introduced -Wdeclaration-after-statement in gcc4 ...
many people love them too
Aug 11 '06 #29

This discussion thread is closed

Replies have been disabled for this discussion.