Re: what weren't structure/union/map made part of F77/90 ?

> Now that I'm home, a slight elaboration on that one. Adding structure et
> al to the standard would be a *BIG* job. That's largely because it would
> have to be integrated with everything else, somehow or another. Even if
> the integration amounted to saying that it didn't work in conjunction
> with something else, that still would have to be said, and someone would
> have to figure out all the places where it needed to be said. Skim the
> standard for how many places something gets said about derived types.
>
> Not only would it be a lot of places, I think some of them would be
> hard. I haven't bothered to think very hard about it, but my off-hand
> guess would be that it would not integrate cleanly at all with several
> other features - no I don't have, nor do I care to come up with details.
>
> As a vendor feature hanging around several compilers for compatibility
> with old code, the vendors in question can get by with just blowing off
> questions that would have to be seriously addressed if it were added to
> the standard. And if it were added to the standard without decent
> integration, intended only to standardize old codes, then that would not
> seem like an argument likely to gather much support.

I wonder if this is some of the problems that I am seeing with the Intel
Visual Fortran compiler. We have ported our code over the years to
about 14 different platforms. I have never had the problems with a
platform / compiler that I am having with the IVF compiler. I had some
of the same problems with the CVF compiler too (that port was never
completed). And yes, our code must be zero loaded and staticly saved
between subroutine calls. IVF supports that, it is just kinda weird a
about it. I really wish that we did not have those dependencies but
they were part of the initial assumptions made back in the 60s and 70s.
Kinda hard to track them all down and eliminate them with limited staff.
Kinda like a modern day snipe hunt.

We have only been using the structure / record / map / union features
for the last 5 years. However, it is now an integral part of our dynamic
data storage and would be difficult to get around without it. Since IVF
supports I*8 and L*8, we could drop the structure / union / map and
go back to our old equivalences but I suspect that would not solve our
problems.

Thanks,
Lynn


.

Relevant Pages

  • Visual C++.NET Standard with the optimizing toolkit compiler?
    ... I recently purchased VisualC++.NET Standard edition(without an optimizing ... compiler) and now read about the optimizing c++ compiler being available ... so i kinda feel disappointed. ...
    (microsoft.public.vstudio.general)
  • Re: Where to start ? Too many options to choose from.
    ... compiler and is really old anyway. ... the latter has supposedly better integration but it also ... with evaluation board I have a Win CE 5.0 Pro license. ... Hence I'd need platform builder. ...
    (microsoft.public.windowsce.app.development)
  • Re: Opinions on procedural language being introduced into SQL Server 2005
    ... integration, so no need to venture into the dark side of managed code << ... that is not the Standard SQL/PSM syntax and I am not sure ... the middle and exception handlers at the bottom. ... The key word is WHENEVER, ...
    (microsoft.public.sqlserver.programming)
  • Re: Access Integration Opportunities
    ... I have "integrated" (i.e. different level or scope of integration) Access ... -oil and gas forcast/engineering software, ... Naturally I was able to answer with the standard ... > Microsoft products such as VB, Excel, Outlook, and Powerpoint, but that ...
    (microsoft.public.access.externaldata)
  • Re: A fast scheme implementation?
    ... about a general purpose library procedure, ... tuned, that performs numerical integration. ... pass it a procedure in Scheme, ... If the compiler squirrels away a serialized ...
    (comp.lang.scheme)