PDT's and c++

[Ron Ford]

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?

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++?

Thanks and cheers,

 

[Ian Collins]

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?

 

[Ron Ford]

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?

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]

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.

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]

A common missing feature of contemporary C++ compilers?





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 ControlledEquipment
{
}

class Radio: public class ControlledEquipment
{
}

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


Do either of those correspond to PDTs?

 

[Juha Nieminen]

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]

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 ClassNamePrivate 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.

 

[Ron Ford]

A common missing feature of contemporary C++ compilers?






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 ControlledEquipment
{
}

class Radio: public class ControlledEquipment
{
}

a Radio is a type of ControlledEquipment 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.

 

[Nick Keighley]

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 ControlledEquipment
{
}

class Radio: public class ControlledEquipment
{
}

a Radio is a type of ControlledEquipment 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.

 

[Ron Ford]

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 ControlledEquipment
{
}

class Radio: public class ControlledEquipment
{
}

a Radio is a type of ControlledEquipment 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.