Warp wrote:
>   Yeah, but that's only possible in languages with weak typing (I think
> that's the term?) 

"Dynamic typing" is the term you're looking for - expressions have 
types, but not variables.
"Static typing" being the alternative, where variables have types.

"Weak typing" is when type operations aren't enforced, like in C. 
"Strong typing" is when type operations are enforced, like Java.

You can have strong typing that's also dynamic typing, like Smalltalk or 
Lisp or Erlang, or static typing that's weak like in C, or static typing 
that's strong like (say) Haskell (as I understand it), or dynamic typing 
that's weak (like Forth or assembler).

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Orchid XP v8 wrote:
>>   Java supports generics.
> ....OK, I just learned something.

Are they actually supported as new types? Or is it just syntactic 
shorthand? I wouldn't think you could really have generics if you didn't 
change the .class file format, which I think Sun's trying to avoid?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Orchid XP v8 wrote:
> So... it's Turing-complete?

Yep.  I saw a turing machine emulator written as templates, with a 
series of error messages from the compiler tracing the path through the 
state changes.

In any case, generics are a subset of templates. It's entirely possible 
to think that generics are a good idea and that templates are a bad way 
to implement them. For example, you have to parse and compile the 
templates each time from source, and you get a new blob of code for each 
type you instantiate a template with. Both of these are a bad idea when 
you're trying to make a system where you can distribute object code 
without source for generics, or you want to instantiate a generic at 
runtime with some other class you just loaded.

Now, "crippled" is what I'd call the baroque C++ syntax. I mean, really, 
folks, can't we accept that languages that aren't C don't need to avoid 
C special characters in new syntax? :-) What's with this "::" for 
namespaces in Tcl and <<>> for generics in Java? Ugly, guys, uUUUuugly!

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:

> Orchid XP v8 wrote:
>>>   Java supports generics.
>> ....OK, I just learned something.
> 
> Are they actually supported as new types? Or is it just syntactic
> shorthand? I wouldn't think you could really have generics if you didn't
> change the .class file format, which I think Sun's trying to avoid?
> 

http://java.sun.com/docs/books/tutorial/java/generics/erasure.html
http://java.sun.com/docs/books/tutorial/extra/generics/legacy.html
http://java.sun.com/docs/books/tutorial/extra/generics/convert.html

Basically, it looks like anything related to generics is removed from the
compiled code.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> For example, you have to parse and compile the 
> templates each time from source

  A compiler which supports export templates could conceivably have
precompiled templates for certain (although obviously not all) types,
such as for example for all basic types and STL classes. Thus it could
avoid having to compile them each time.

> and you get a new blob of code for each 
> type you instantiate a template with.

  If you are using the same code with two different types you are obviously
going to get two different pieces of code, no matter how you do it.
Templates just make it easier to avoid code repetition. (In other words,
if you want, for example, a vector of ints and a vector of doubles, you
don't need to write the vector code twice.)

  Templated data containers in C++ usually produce more memory-efficient
code than equivalent data containers using the pointer-to-base-Object
mechanism, which usually wastes a lot of memory. Thus any argument that
templates cause memory bloat is usually false. (Yes, there may be a few
situations where templated code causes more memory usage, but normally
it's the opposite.)

> Now, "crippled" is what I'd call the baroque C++ syntax.

  Syntax doesn't really matter all that much. It's how you use it.

-- 
                                                          - Warp

Post a reply to this message

>> So... it's Turing-complete?
> 
> Yep.

Right. Well, the good thing about Turing-complete languages is that they 
can do everything. The bad part is... they can do everything. SQL is so 
damn efficient precisely *because* there are things it can't do.

Java's generics [if they anything like any other language] are nowhere 
near Turing-complete, which makes them much easier to handle. [And 
harder to misuse.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> For example, you have to parse and compile the 
>> templates each time from source
> 
>   A compiler which supports export templates could conceivably have
> precompiled templates for certain (although obviously not all) types,
> such as for example for all basic types and STL classes. Thus it could
> avoid having to compile them each time.

Yes. If you restrict templates to doing what generics do, you don't have 
to compile them each time. But that's a restriction on templates.

>> and you get a new blob of code for each 
>> type you instantiate a template with.
> 
>   If you are using the same code with two different types you are obviously
> going to get two different pieces of code, no matter how you do it.

Not in every language, no.  Depending on what you do with the types, 
yes. That, for example, *is* one difference between generics and 
templates. Obviously Java "generics" (such as they are) don't have this 
restriction, because by the time you get to object code, all the actual 
type information is gone.

In any case, what *I* meant was that you get a new blob of code compiled 
every time you instantiate a template. Not for each different type, but 
even for the same types in different compilation units. Yes? Or am I 
confused about that?  If I have std:vector<MyType> having functions 
called in one module, then I compile another module with 
std:vector<MyType>, does the linker see that it's the same code and 
function on the same type and only include one copy of the object code 
in the linked result?

> Templates just make it easier to avoid code repetition. (In other words,
> if you want, for example, a vector of ints and a vector of doubles, you
> don't need to write the vector code twice.)

Right. Generics do the same thing. They're just more restricted than 
what templates give you.

>   Templated data containers in C++ usually produce more memory-efficient
> code than equivalent data containers using the pointer-to-base-Object
> mechanism, which usually wastes a lot of memory. 

Unless everything's already a pointer-to-base-Object, as you already 
decry. ;-)

> Thus any argument that
> templates cause memory bloat is usually false. (Yes, there may be a few
> situations where templated code causes more memory usage, but normally
> it's the opposite.)

I think they likely cause code file bloat. If you use the same template 
and instantiate it on 10 different types of pointers, aren't you going 
to get ten different copies of object code?

>> Now, "crippled" is what I'd call the baroque C++ syntax.
>   Syntax doesn't really matter all that much. It's how you use it.

True. It's a pretty minor thing, once you get used to it. I just dislike 
people taking the syntax into languages that don't need it. Right up 
there with people who think a leading zero means octal is a good idea on 
values rather than constants.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> For example, you have to parse and compile the 
> >> templates each time from source
> > 
> >   A compiler which supports export templates could conceivably have
> > precompiled templates for certain (although obviously not all) types,
> > such as for example for all basic types and STL classes. Thus it could
> > avoid having to compile them each time.

> Yes. If you restrict templates to doing what generics do, you don't have 
> to compile them each time. But that's a restriction on templates.

  At least Java generics do not support basic types, so I don't really
understand what you are talking about.

  I suppose that no compiler so far uses this optimization, but I can
perfectly imagine it being absolutely possible: When a template class or
function is instantiated for a certain type, the compiler could compile
it into some type of object file. Next time that template is used with
the same type (be it in the same compilation process, by another compilation
unit, or in a future one) it can simply use that object file instead of
recompiling the template code. The mechanism to do this could be similar
and related to export templates (or if technical reasons mandate it, it
could only work with export templates).

> In any case, what *I* meant was that you get a new blob of code compiled 
> every time you instantiate a template. Not for each different type, but 
> even for the same types in different compilation units. Yes? Or am I 
> confused about that?

  Currently yes, but as I said, it's perfectly conceivable that this
could be optimized by compilers.

>  If I have std:vector<MyType> having functions 
> called in one module, then I compile another module with 
> std:vector<MyType>, does the linker see that it's the same code and 
> function on the same type and only include one copy of the object code 
> in the linked result?

  The linker always merges all template instantiations of a given type
into one (this is required by the C++ standard, AFAIK). In other words,
the final executable will have only one instance of those functions.
That's not the problem.
  (The only "problem" with template code is the increased compilation
time and object file sizes.)

> > Templates just make it easier to avoid code repetition. (In other words,
> > if you want, for example, a vector of ints and a vector of doubles, you
> > don't need to write the vector code twice.)

> Right. Generics do the same thing.

  Except that they don't work with basic types, at least not in Java,
so they only solve part of the problem. :P

> > Thus any argument that
> > templates cause memory bloat is usually false. (Yes, there may be a few
> > situations where templated code causes more memory usage, but normally
> > it's the opposite.)

> I think they likely cause code file bloat.

  The amount of code "bloat" caused by templates is usually much smaller
than the extra amount of RAM required if templates were avoided. Usually
template functions are relatively small, like some hundreds of bytes at
most, while the data containers they are instantiating handle even
megabytes of memory at a time. With C++ templates the optimization is
in the right place: In the memory usage of the data containers, not the
machine code in the functions of that data container.

-- 
                                                          - Warp

Post a reply to this message

On Sat, 10 May 2008 19:44:53 +0200, Darren New <dne### [at] sanrrcom> wrote:
> In any case, what *I* meant was that you get a new blob of code compiled  
> every time you instantiate a template. Not for each different type, but  
> even for the same types in different compilation units. Yes? Or am I  
> confused about that?  If I have std:vector<MyType> having functions  
> called in one module, then I compile another module with  
> std:vector<MyType>, does the linker see that it's the same code and  
> function on the same type and only include one copy of the object code  
> in the linked result?

Some compilers delay code generation of some templates until link time.  
Even in the absence of delayed code generation, the linker merges  
duplicates.



>> Thus any argument that
>> templates cause memory bloat is usually false. (Yes, there may be a few
>> situations where templated code causes more memory usage, but normally
>> it's the opposite.)
>
> I think they likely cause code file bloat. If you use the same template  
> and instantiate it on 10 different types of pointers, aren't you going  
> to get ten different copies of object code?

Some linkers can recognise that the generated code is identical, and merge  
all the copies.


-- 
FE

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> Some linkers can recognise that the generated code is identical, and merge  
> all the copies.

  Not "some". All of them. They have to.

  That's because, AFAIK, as per the C++ standard, you have to be able to,
for example, create a function pointer to a given template function, and
if two pointers initialized in different compilation units point to the
same function, they have to compare equal. Another requisite is that if
there are static variables inside the function, they must all use the same
static variable.

-- 
                                                          - Warp

Post a reply to this message