PDT's and c++

**Ian Collins** · Jul 22 '08, 05:35 AM

Re: PDT's and c++

Ron Ford wrote:

Hello newsgroup,
>
I don't know much C++ that isn't windows-related, and presumably off-topic,
or C in disguise, so I hope not to misspeak on this short question.
>
I'm given to understand that C++ has had a situation similar to the one
faced currently by the fortran community: coming up on another standard
without having realized a feature of the old one. The muckity mucks are
enclaving to decide on F2008 without any implementor having been able to
come up with a new F2003 feature: parameterized derived types, aka PDT's.
>
Q1) Has the C++ standard rolled back on a feature? If so, what were the
circumstances?
>

I don't think so. The only common missing feature is export templates,
but some compiler do implement it. So there's nothing really to roll back.

My background in syntax is primarily with C and fortran, so I don't have
any knowing experience with PDT's. The guys who do have a background in
object orientation don't have it from fortran, as that would be new, had it
worked.
>
Q2) What do PDT's look like in C++?
>

What do they look like in Fortran?

--
Ian Collins.

**Ron Ford** · Jul 23 '08, 01:05 AM

Re: PDT's and c++

On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:

Ron Ford wrote:

>Hello newsgroup,
>>
>I don't know much C++ that isn't windows-related, and presumably off-topic,
>or C in disguise, so I hope not to misspeak on this short question.
>>
>I'm given to understand that C++ has had a situation similar to the one
>faced currently by the fortran community: coming up on another standard
>without having realized a feature of the old one. The muckity mucks are
>enclaving to decide on F2008 without any implementor having been able to
>come up with a new F2003 feature: parameterized derived types, aka PDT's.
>>
>Q1) Has the C++ standard rolled back on a feature? If so, what were the
>circumstance s?
>>

I don't think so. The only common missing feature is export templates,
but some compiler do implement it. So there's nothing really to roll back.

A common missing feature of contemporary C++ compilers?

>

>My background in syntax is primarily with C and fortran, so I don't have
>any knowing experience with PDT's. The guys who do have a background in
>object orientation don't have it from fortran, as that would be new, had it
>worked.
>>
>Q2) What do PDT's look like in C++?
>>

What do they look like in Fortran?

Nobody knows! Least of all me. I only know what I have experience with.

--
Each party steals so many articles of faith from the other, and the
candidates spend so much time making each other's speeches, that by the
time election day is past there is nothing much to do save turn the sitting
rascals out and let a new gang in.
H. L. Mencken

**Gernot Frisch** · Jul 23 '08, 07:15 AM

Re: PDT's and c++

>I don't think so. The only common missing feature is export templates,
>but some compiler do implement it. So there's nothing really to roll
>back.

>
A common missing feature of contemporary C++ compilers?

It would have been handy at some point and make source files a bit clearer,
but it's no problem at all, since you can put the "export"ed function in an
external file and include that instead.

>>Q2) What do PDT's look like in C++?
>>>

>What do they look like in Fortran?

>
Nobody knows! Least of all me. I only know what I have experience with.

So, why are you asking if it's available in C++?

**Nick Keighley** · Jul 23 '08, 09:55 AM

Re: PDT's and c++

On 23 Jul, 01:57, Ron Ford <r...@nowhere.n etwrote:

On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:
>
>
>
>
>

Ron Ford wrote:

Hello newsgroup,

>

I don't know much C++ that isn't windows-related, and presumably off-topic,
or C in disguise, so I hope not to misspeak on this short question.

>

I'm given to understand that C++ has had a situation similar to the one
faced currently by the fortran community: coming up on another standard
without having realized a feature of the old one. The muckity mucksare
enclaving to decide on F2008 without any implementor having been able to
come up with a new F2003 feature: parameterized derived types, aka PDT's.

>

Q1) Has the C++ standard rolled back on a feature? If so, what were the
circumstances?

>

I don't think so. The only common missing feature is export templates,
but some compiler do implement it. So there's nothing really to rollback.

>
A common missing feature of contemporary C++ compilers?
>
>
>

My background in syntax is primarily with C and fortran, so I don't have
any knowing experience with PDT's. The guys who do have a background in
object orientation don't have it from fortran, as that would be new, had it
worked.

>

Q2) What do PDT's look like in C++?

>

What do they look like in Fortran?

>
Nobody knows! Least of all me. I only know what I have experience with.

so what do they do? If you describe how PDTs behave then someone
might be able to point you at similar C++ feature (or not).

C++ has class templates which might be what you want.

vector<int an "array" of integers
vector<stringan "array" of strings etc.

the parameter can be any type including one you invented.

C++ also supports inheritance

class ControlledEquip ment
{
}

class Radio: public class ControlledEquip ment
{
}

a Radio is a type of ControlledEquip ment and inherits its
attributes (its a bit more complicated than that, if you
care read a book)

Do either of those correspond to PDTs?

--
Nick Keighley

A little inaccuracy sometimes saves tons of explanation.
-- H.H. Munro, "Saki"

**Juha Nieminen** · Jul 23 '08, 11:15 PM

Re: PDT's and c++

Gernot Frisch wrote:

>>I don't think so. The only common missing feature is export templates,
>>but some compiler do implement it. So there's nothing really to roll
>>back.

>>
>A common missing feature of contemporary C++ compilers?

>
It would have been handy at some point and make source files a bit
clearer, but it's no problem at all, since you can put the "export"ed
function in an external file and include that instead.

That's not the whole story. Export templates, like regular functions
and classes, have their own private compilation unit, and it's possible
to put compilation-unit-specific data and code there (inside a nameless
namespace).

Without export templates you can't have private data for a template
function, and with template classes you are limited to static data and
functions inside the private section of the class (which may become
extremely bloated if the amount of data and code is large, and which
will cause the data and code to be needlessly replicated for each
different template parameter type increasing code size, not to talk
about how cumbersome it is).

Yes, you could put a nameless namespace in that source file where you
have your templates, but then you will be needlessly replicating the
data for each compilation unit where that source is included (the linker
won't merge them into one), not to talk about the possible name
collisions it might produce with other code in the file which includes
that template source code file. (Using a named namespace may reduce the
danger of name collisions, but it doesn't solve the problem of
replicated data.)

**James Kanze** · Jul 24 '08, 07:25 AM

Re: PDT's and c++

On Jul 24, 1:09 am, Juha Nieminen <nos...@thanks. invalidwrote:

Gernot Frisch wrote:

>I don't think so. The only common missing feature is
>export templates, but some compiler do implement it. So
>there's nothing really to roll back.

A common missing feature of contemporary C++ compilers?

It would have been handy at some point and make source files
a bit clearer, but it's no problem at all, since you can put
the "export"ed function in an external file and include that
instead.

That's not the whole story. Export templates, like regular
functions and classes, have their own private compilation
unit, and it's possible to put compilation-unit-specific data
and code there (inside a nameless namespace).

Also, of course, the granularity of most make systems is the
file. If you modify anything in the header file, all sources
which include the header need to be recompiled. (Formally,
that's also what the standard requires, at least if the
modification involves more than just white space and comments;
otherwise, you have undefined behavior.)

Without export templates you can't have private data for a
template function, and with template classes you are limited
to static data and functions inside the private section of the
class (which may become extremely bloated if the amount of
data and code is large, and which will cause the data and code
to be needlessly replicated for each different template
parameter type increasing code size, not to talk about how
cumbersome it is).

Yes, you could put a nameless namespace in that source file
where you have your templates,

Only if you want undefined behavior. The one definition rule
requires that the token sequence be indentical, *AND* that all
symbols bind to the same entity. The contents of an anonymous
namespace are different entities in different translation units.

but then you will be needlessly replicating the data for each
compilation unit where that source is included (the linker
won't merge them into one), not to talk about the possible
name collisions it might produce with other code in the file
which includes that template source code file. (Using a named
namespace may reduce the danger of name collisions, but it
doesn't solve the problem of replicated data.)

I generally manage this by using a ClassNamePrivat e namespace.
It works fairly well, but it still doesn't protect against
everything (e.g. macros), and it still doesn't solve the problem
that the slightest change requires recompiling all clients.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

**Ron Ford** · Jul 25 '08, 10:35 AM

Re: PDT's and c++

On Wed, 23 Jul 2008 02:54:10 -0700 (PDT), Nick Keighley posted:

On 23 Jul, 01:57, Ron Ford <r...@nowhere.n etwrote:

>On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:
>>
>>
>>
>>
>>

>>Ron Ford wrote:
>>>Hello newsgroup,

>>

>>>I don't know much C++ that isn't windows-related, and presumably off-topic,
>>>or C in disguise, so I hope not to misspeak on this short question.

>>

>>>I'm given to understand that C++ has had a situation similar to the one
>>>faced currently by the fortran community: coming up on another standard
>>>without having realized a feature of the old one. The muckity mucks are
>>>enclaving to decide on F2008 without any implementor having been able to
>>>come up with a new F2003 feature: parameterized derived types, aka PDT's.

>>

>>>Q1) Has the C++ standard rolled back on a feature? If so, what were the
>>>circumstance s?

>>

>>I don't think so. The only common missing feature is export templates,
>>but some compiler do implement it. So there's nothing really to roll back.

>>
>A common missing feature of contemporary C++ compilers?
>>
>>
>>

>>>My background in syntax is primarily with C and fortran, so I don't have
>>>any knowing experience with PDT's. The guys who do have a background in
>>>object orientation don't have it from fortran, as that would be new, had it
>>>worked.

>>

>>>Q2) What do PDT's look like in C++?

>>

>>What do they look like in Fortran?

>>
>Nobody knows! Least of all me. I only know what I have experience with.

>
so what do they do? If you describe how PDTs behave then someone
might be able to point you at similar C++ feature (or not).
>
C++ has class templates which might be what you want.
>
vector<int an "array" of integers
vector<stringan "array" of strings etc.
>
the parameter can be any type including one you invented.
>
C++ also supports inheritance
>
class ControlledEquip ment
{
}
>
class Radio: public class ControlledEquip ment
{
}
>
a Radio is a type of ControlledEquip ment and inherits its
attributes (it[']s a bit more complicated than that, if you
care [to] read a book)
>
>
Do either of those correspond to PDTs?

Thanks for your response, Nick. I'm given to understand that PDT's have to
do with inheritance.

As for me, I go nowhere, without the object has gone before.

It would seem that c.l.c++ knows as much as I do about object-orientation.
--
Unquestionably, there is progress. The average American now pays out twice
as much in taxes as he formerly got in wages. 1
H. L. Mencken

**Nick Keighley** · Jul 26 '08, 10:55 AM

Re: PDT's and c++

On Jul 25, 11:33 am, Ron Ford <r...@nowhere.n etwrote:

On Wed, 23 Jul 2008 02:54:10 -0700 (PDT),Nick Keighleyposted:

On 23 Jul, 01:57, Ron Ford <r...@nowhere.n etwrote:

On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:
>Ron Ford wrote:

<snip>

>>Q2) What do PDT's look like in C++?

>

>What do they look like in Fortran?

>

Nobody knows! Least of all me. I only know what I have experience with.

>

so what do they do? If you describe how PDTs behave then someone
might be able to point you at similar C++ feature (or not).

>

C++ has class templates which might be what you want.

>

vector<int an "array" of integers
vector<stringan "array" of strings etc.

>

the parameter can be any type including one you invented.

>

C++ also supports inheritance

>

class ControlledEquip ment
{
}

>

class Radio: public class ControlledEquip ment
{
}

>

a Radio is a type of ControlledEquip ment and inherits its
attributes (it[']s a bit more complicated than that, if you
care [to] read a book)

>

Do either of those correspond to PDTs?

>
Thanks for your response, Nick. I'm given to understand that PDT's have to
do with inheritance.

but you *still* havn't explained what a PDT is.

As for me, I go nowhere, without the object has gone before.

I don't understand this

It would seem that c.l.c++ knows as much as I do about object-orientation..

I think clc++ knows a lot about OO. They just don't know Fortran.

--
Nick Keighley

**Ron Ford** · Jul 26 '08, 11:05 PM

Re: PDT's and c++

On Sat, 26 Jul 2008 03:54:39 -0700 (PDT), Nick Keighley posted:

On Jul 25, 11:33 am, Ron Ford <r...@nowhere.n etwrote:

>On Wed, 23 Jul 2008 02:54:10 -0700 (PDT),Nick Keighleyposted:

>>On 23 Jul, 01:57, Ron Ford <r...@nowhere.n etwrote:
>>>On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:
>>>>Ron Ford wrote:

>
<snip>
>

>>>>>Q2) What do PDT's look like in C++?

>>

>>>>What do they look like in Fortran?

>>

>>>Nobody knows! Least of all me. I only know what I have experience with.

>>

>>so what do they do? If you describe how PDTs behave then someone
>>might be able to point you at similar C++ feature (or not).

>>

>>C++ has class templates which might be what you want.

>>

>>vector<int an "array" of integers
>>vector<string an "array" of strings etc.

>>

>>the parameter can be any type including one you invented.

>>

>>C++ also supports inheritance

>>

>>class ControlledEquip ment
>>{
>>}

>>

>>class Radio: public class ControlledEquip ment
>>{
>>}

>>

>>a Radio is a type of ControlledEquip ment and inherits its
>>attributes (it[']s a bit more complicated than that, if you
>>care [to] read a book)

>>

>>Do either of those correspond to PDTs?

>>
>Thanks for your response, Nick. I'm given to understand that PDT's have to
>do with inheritance.

>
but you *still* havn't explained what a PDT is.
>
>

>As for me, I go nowhere, without the object has gone before.

>
I don't understand this
>
>

>It would seem that c.l.c++ knows as much as I do about object-orientation.

>
I think clc++ knows a lot about OO. They just don't know Fortran.

I think that's the point. PDT's must be some crazy-difficult thing that
specifically fortran has to do to get OO. I could find a snippet from
fortran, but what would it run on?

The main thing I wanted to check here was whether C++ had had a feature it
had rolled back on, as I had heard. I'll take that to be a non-event.

--
We must be willing to pay a price for freedom. 4
H. L. Mencken

PDT's and c++

PDT's and c++

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment