PDT's and c++

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,

--
Man is always looking for someone to boast to; woman is always looking for
a shoulder to put her head on.
H. L. Mencken

re: PDT's and c++

Ron Ford 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.
What do they look like in Fortran?

--
Ian Collins.

re: PDT's and c++

On Tue, 22 Jul 2008 17:29:28 +1200, Ian Collins posted:
A common missing feature of contemporary C++ compilers?
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

re: PDT's and c++

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.

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

re: PDT's and c++

On 23 Jul, 01:57, Ron Ford <r...@nowhere.netwrote: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 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?


--
Nick Keighley

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

re: PDT's and c++

Gernot Frisch wrote: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.)

re: PDT's and c++

On Jul 24, 1:09 am, Juha Nieminen <nos...@thanks.invalidwrote: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.)
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.
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.

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

re: PDT's and c++

On Wed, 23 Jul 2008 02:54:10 -0700 (PDT), Nick Keighley posted:
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

re: PDT's and c++

On Jul 25, 11:33*am, Ron Ford <r...@nowhere.netwrote:<snip>
but you *still* havn't explained what a PDT is.

I don't understand this

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

--
Nick Keighley

re: PDT's and c++

On Sat, 26 Jul 2008 03:54:39 -0700 (PDT), Nick Keighley posted:
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