[jan-jaap]

I was browsing Issue 11 of IRIS Universe (early 1990) from archive.org

It contains an article on the then-new PowerVision graphics for the PowerSeries, better known as VGX. This article introduces the ImageVision library said to come with PowerVision graphics. It looks like it allows you to offload vector math operations to the graphics pipe rather than running them on the CPU(s):

   

I'm always interested in things to demonstrate the unique capabilities of my old systems, so I dug a little deeper but I can't find a trace of this library. Mind you, I have several versions of the ImageVision library. ImageVision Version 1.0 is for IRIX 4.0 and dated December 1991. The introduction of VGX was in Q1 1990, with IRIX 3.3. Nearly 2 years earlier.

The ImageVision 1.0 CD (part # 812-0040-001, you can find it on jrra.zone) is not a C or Fortran library as described in the article. it's C++ only and deals with images, not vector math. It will install on any graphics hardware, not VGX only. It was ImageVision 2.0 (01/1993) that first introduced "C" bindings.

I can't find any trace of the calls in Table 1 in the GL either.

So, anybody know what happened here?

[Raion]

If it's C++ and from that era does that presumably mean that it would be a cfront type library?

It makes me wonder why SGI was such a huge advocate of C++ when it was still very new and experimental at the time

[jan-jaap]

I think so. At the time SGI had C++ Translator 2.1.1 (812-0001-003, 11/91). Pretty sure that's cfront from here. I think it wasn't until IRIX 5.3 that they started using something built from an EDG frontend. In between we also had the DeltaCC compiler.

See also https://techpubs.jurassic.nl/library/man...ml#id89018

They were all pretty miserable.

[vishnu]

If it's C++ and from that era does that presumably mean that it would be a cfront type library? 

It makes me wonder why SGI was such a huge advocate of C++ when it was still very new and experimental at the time

You could argue that C++ is still a cfront type library! 

Thing about it is, and this was a design intent from the start, programmers can use (or ignore) whatever feature(s) of C++ (the whole "it's a better C" thing), they feel would benefit them (or not benefit them). It's just as useful as a procedural language as it is an object-oriented language. In fact Bjarne himself has always said C++ is not an object oriented language, it's a language with features that support object oriented programming. And really, an object is nothing more (or less) than a user-defined type...

[Raion]

I think so. At the time SGI had C++ Translator 2.1.1 (812-0001-003, 11/91). Pretty sure that's cfront from here. I think it wasn't until IRIX 5.3 that they started using something built from an EDG frontend. In between we also had the DeltaCC compiler.

See also https://techpubs.jurassic.nl/library/man...ml#id89018

They were all pretty miserable.

Yeah I've messed with that era of code, it ain't fun.

[jan-jaap]

You could argue that C++ is still a cfront type library! 

I didn't care so much about the C++ to C translation aspect of it, but at the time I was working on a large code base of scientific simulation software that we supported on Windows, OS/2 (both Watcom compiler), IRIX, HP-UX, Solaris and AIX (usually native compilers, sometimes GCC). All of these compilers had their own moronic deviations from the standards. All of them used different APIs for threading and many other OS primitives. All of them had different implementations of C++ templates or were lacking in various aspects. All were broken in subtle ways that could make them generate incorrect object code from correct source code. Don't get me started on the bugs in early IRIX 6.0 and MIPSpro when targeting a PowerChallenge (it didn't help that very few code was 64 bit clean in those days).

It was a pain is the ass, and often if you fixed something or worked around the limitations of one platform you'd break something on another.

Compilers have come a long way. Adherence to standards has too. And don't forget that many of the tools you take for granted these days like static analyzers, valgrind, CI/CD, version management systems that understand change sets of more than a single file, didn't exist back then or were much much more limited

[vishnu]

All of them had different implementations of C++ templates...

When the FSF decided to add templates to their compiler, they took the entirety of the STL code from SGI and dumped it into their compiler completely untouched. 
 
And of course the STL is just one of the overwhelming number of reasons why C++ "is a better C."