Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #47912 > unrolled thread

"Visual C++ - Microsoft Pushes C++ into the Future"

Back to article view | Back to comp.lang.c++

Contents

  "Visual C++ - Microsoft Pushes C++ into the Future" Lynn McGuire <lynnmcguire5@gmail.com> - 2017-01-10 14:05 -0600
    Re: "Visual C++ - Microsoft Pushes C++ into the Future" Real Troll <real.troll@trolls.com> - 2017-01-10 16:25 -0400
      Re: "Visual C++ - Microsoft Pushes C++ into the Future" Bo Persson <bop@gmb.dk> - 2017-01-10 21:57 +0100
      Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 12:59 -0800
    Re: "Visual C++ - Microsoft Pushes C++ into the Future" David Brown <david.brown@hesbynett.no> - 2017-01-10 22:43 +0100
      Re: "Visual C++ - Microsoft Pushes C++ into the Future" legalize+jeeves@mail.xmission.com (Richard) - 2017-01-10 22:24 +0000
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" David Brown <david.brown@hesbynett.no> - 2017-01-11 00:28 +0100
          Re: "Visual C++ - Microsoft Pushes C++ into the Future" legalize+jeeves@mail.xmission.com (Richard) - 2017-01-11 00:46 +0000
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" David Brown <david.brown@hesbynett.no> - 2017-01-11 09:12 +0100
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-11 18:06 +0000
          Re: "Visual C++ - Microsoft Pushes C++ into the Future" jonkalb <google@kalbweb.com> - 2017-01-11 19:55 -0800
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" Robert Wessel <robertwessel2@yahoo.com> - 2017-01-11 22:21 -0600
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-12 13:30 +0000
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" jonkalb <google@kalbweb.com> - 2017-01-14 00:15 -0800
                Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-16 13:40 +0000
                  Re: "Visual C++ - Microsoft Pushes C++ into the Future" jonkalb <google@kalbweb.com> - 2017-01-16 21:46 -0800
                    Re: "Visual C++ - Microsoft Pushes C++ into the Future" Öö Tiib <ootiib@hot.ee> - 2017-01-17 03:31 -0800
          Re: "Visual C++ - Microsoft Pushes C++ into the Future" red floyd <dont.bother@its.invalid> - 2017-01-12 10:10 -0800
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-12 18:13 +0000
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" red floyd <dont.bother@its.invalid> - 2017-01-12 10:15 -0800
                Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-12 18:22 +0000
      Re: "Visual C++ - Microsoft Pushes C++ into the Future" Ian Collins <ian-news@hotmail.com> - 2017-01-11 17:45 +1300
    Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 10:25 -0800
      Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-12 18:29 +0000
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 10:51 -0800
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 10:55 -0800
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" Ian Collins <ian-news@hotmail.com> - 2017-01-13 08:21 +1300
          Re: "Visual C++ - Microsoft Pushes C++ into the Future" legalize+jeeves@mail.xmission.com (Richard) - 2017-01-12 21:13 +0000
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 20:29 -0800
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" scott@slp53.sl.home (Scott Lurndal) - 2017-01-13 13:25 +0000
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" Cholo Lennon <chololennon@hotmail.com> - 2017-01-13 11:06 -0300
            Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Asger Joergensen" <Junk@Asger-P.dk> - 2017-01-14 02:54 +0000
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" Lynn McGuire <lynnmcguire5@gmail.com> - 2017-01-13 21:11 -0600
                Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Asger Joergensen" <Junk@Asger-P.dk> - 2017-01-14 10:22 +0000
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" legalize+jeeves@mail.xmission.com (Richard) - 2017-01-15 02:53 +0000
              Re: "Visual C++ - Microsoft Pushes C++ into the Future" Cholo Lennon <chololennon@hotmail.com> - 2017-01-17 12:12 -0300
        Re: "Visual C++ - Microsoft Pushes C++ into the Future" Cholo Lennon <chololennon@hotmail.com> - 2017-01-12 16:45 -0300
          Re: "Visual C++ - Microsoft Pushes C++ into the Future" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 11:55 -0800

Page 1 of 2  [1] 2  Next page →

#47912 — "Visual C++ - Microsoft Pushes C++ into the Future"

"Visual C++ - Microsoft Pushes C++ into the Future"
     https://msdn.microsoft.com/en-us/magazine/mt694085.aspx

Lynn

[toc] | [next] | [standalone]

#47914

On 10/01/2017 20:05, Lynn McGuire wrote:
> "Visual C++ - Microsoft Pushes C++ into the Future"
>     https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
>
> Lynn


Any ideas when is the next Visual C++ coming out?

I have VC++ since version 10 (10, 12, 13, 15) and I love it!!

[toc] | [prev] | [next] | [standalone]

#47916

On 2017-01-10 21:25, Real Troll wrote:
> On 10/01/2017 20:05, Lynn McGuire wrote:
>> "Visual C++ - Microsoft Pushes C++ into the Future"
>>     https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
>>
>> Lynn
>
>
> Any ideas when is the next Visual C++ coming out?
>

Soon-ish. It's at the Release Candidate level.

https://www.visualstudio.com/vs/visual-studio-2017-rc/


     Bo Persson

[toc] | [prev] | [next] | [standalone]

#47917

On Tuesday, January 10, 2017 at 3:22:14 PM UTC-5, Real Troll wrote:
> On 10/01/2017 20:05, Lynn McGuire wrote:
> > "Visual C++ - Microsoft Pushes C++ into the Future"
> >     https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
> >
> > Lynn
> 
> 
> Any ideas when is the next Visual C++ coming out?
> 
> I have VC++ since version 10 (10, 12, 13, 15) and I love it!!

RC Candidate 2017 is out.  Its IDE is slow and clunky at times.  I've
seen the "Visual Studio is still working.  We're sending feedback to
Microsoft about this UI action" pop up.  And sometimes even simple
UI operations are very oddly timed for giving user feedback.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#47922

On 10/01/17 21:05, Lynn McGuire wrote:
> "Visual C++ - Microsoft Pushes C++ into the Future"
>     https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
>
> Lynn

Modules are a great idea, at least in principle - I haven't followed 
enough of the details to give a technical opinion.  But it would have 
been nice to see more cooperation between MSVC developers and clang 
developers - clang has had an experimental module implementation for 
some time now, and I believe MSVC wanting to go their own way has been a 
big reason for C++17 not having modules.  If the MS idea is technically 
significantly better, that's fair enough - but not if it is just them 
trying to be "first" at something in the C++ world.

Still, it's nice to see MSVC are catching up with C++14.

[toc] | [prev] | [next] | [standalone]

#47925

[Please do not mail me a copy of your followup]

David Brown <david.brown@hesbynett.no> spake the secret code
<o53kep$fq9$1@dont-email.me> thusly:

>Modules are a great idea, at least in principle - I haven't followed 
>enough of the details to give a technical opinion.  But it would have 
>been nice to see more cooperation between MSVC developers and clang 
>developers - 

Gabriel Dos Reis is a long-time gcc contributor and is the main person
behind modules at Microsoft.  I guarantee you that he collaborates
with clang/gcc developers regarding modules.

>[...] clang has had an experimental module implementation for 
>some time now,

If you look more deeply into what's been implemented in clang you find
that it's somewhere between an advanced precompiled header and a
module.  It's less than full-blown modules and it's more than a
precompiled header.

>and I believe MSVC wanting to go their own way has been a 
>big reason for C++17 not having modules.

What Gabriel Dos Reis has proposed is a direct result of experience
using the modules implementation in clang, not something that stabs
out in a completely different direction just for the sake of being
different.

>If the MS idea is technically 
>significantly better, that's fair enough - but not if it is just them 
>trying to be "first" at something in the C++ world.

Sorry, but this is just supposition on your part and doesn't seem to
be based on any of the actual information from either folks on the
clang team who have described their work with modules or from Gabriel
Dos Reis who has described Microsoft's work with modules.

AFAIK, what the clang team did never resulted in a formal proposal to
the standards committe.  Maybe there was some working paper proposal
but a little googling didn't turn it up.  Gabriel Dos Reis (and
collaborators) created a proposal to the standards committe that was
most definitely informed by the experiments dont with clang.  I
suggest you take a look at the proposal.  This is one version, there
may be a newer version: <https://isocpp.org/files/papers/N4047.pdf>.
For earlier discussions of a module system, see the references in the
above paper.

I'm unaware of any attempt, experimental or otherwise, to support modules
in gcc.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#47927

On 10/01/17 23:24, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david.brown@hesbynett.no> spake the secret code
> <o53kep$fq9$1@dont-email.me> thusly:
>
>> Modules are a great idea, at least in principle - I haven't followed
>> enough of the details to give a technical opinion.  But it would have
>> been nice to see more cooperation between MSVC developers and clang
>> developers -
>
> Gabriel Dos Reis is a long-time gcc contributor and is the main person
> behind modules at Microsoft.  I guarantee you that he collaborates
> with clang/gcc developers regarding modules.
>
>> [...] clang has had an experimental module implementation for
>> some time now,
>
> If you look more deeply into what's been implemented in clang you find
> that it's somewhere between an advanced precompiled header and a
> module.  It's less than full-blown modules and it's more than a
> precompiled header.
>
>> and I believe MSVC wanting to go their own way has been a
>> big reason for C++17 not having modules.
>
> What Gabriel Dos Reis has proposed is a direct result of experience
> using the modules implementation in clang, not something that stabs
> out in a completely different direction just for the sake of being
> different.
>
>> If the MS idea is technically
>> significantly better, that's fair enough - but not if it is just them
>> trying to be "first" at something in the C++ world.
>
> Sorry, but this is just supposition on your part and doesn't seem to
> be based on any of the actual information from either folks on the
> clang team who have described their work with modules or from Gabriel
> Dos Reis who has described Microsoft's work with modules.
>
> AFAIK, what the clang team did never resulted in a formal proposal to
> the standards committe.  Maybe there was some working paper proposal
> but a little googling didn't turn it up.  Gabriel Dos Reis (and
> collaborators) created a proposal to the standards committe that was
> most definitely informed by the experiments dont with clang.  I
> suggest you take a look at the proposal.  This is one version, there
> may be a newer version: <https://isocpp.org/files/papers/N4047.pdf>.
> For earlier discussions of a module system, see the references in the
> above paper.
>

Thank you for the information.  I am glad to be corrected here - the C++ 
world gets better when everyone is working together.  I guess I am just 
a little disappointed that there are no modules in C++17, and I felt it 
was unhelpful to have two competing (as I saw it) module systems.  But 
it was unfair of me to suggest that this was anything other than 
people's desire to make a good technical solution rather than a fast fix.

> I'm unaware of any attempt, experimental or otherwise, to support modules
> in gcc.
>

I presume they are waiting until a solution is finalised (rather than 
having yet another experimental version).

[toc] | [prev] | [next] | [standalone]

#47929

[Please do not mail me a copy of your followup]

David Brown <david.brown@hesbynett.no> spake the secret code
<o53qju$6lk$1@dont-email.me> thusly:

>Thank you for the information.  I am glad to be corrected here - the C++ 
>world gets better when everyone is working together.

You're welcome, and thanks for the non-hostile attitude that one
normally sees on usenet :).

>I guess I am just 
>a little disappointed that there are no modules in C++17,

Yeah, I wanted it as well, but if no standards committee proposal
resulted from the clang experiments and there was no gcc
implementation, it doesn't surprise me that it was considered too
green for C++17.  They are really cautious about introducing new stuff
into the standard that hasn't been well tested.

>and I felt it 
>was unhelpful to have two competing (as I saw it) module systems.

I consider the standards proposal to be an evolution of the clang
system instead of a competing system.  It is different because it
incorporates the lessons learned from the clang experiments.

>I presume they are waiting until a solution is finalised (rather than 
>having yet another experimental version).

Lots of proposed stuff for C++11, C++14 and C++17 has been implemented
from working paper proposals and the working proposal from Gabriel Dos
Reis et al seems good enough to me to start a working implementation.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#47932

On 11/01/17 01:46, Richard wrote:
> [Please do not mail me a copy of your followup]
> 
> David Brown <david.brown@hesbynett.no> spake the secret code
> <o53qju$6lk$1@dont-email.me> thusly:
> 
>> Thank you for the information.  I am glad to be corrected here - the C++ 
>> world gets better when everyone is working together.
> 
> You're welcome, and thanks for the non-hostile attitude that one
> normally sees on usenet :).
> 
>> I guess I am just 
>> a little disappointed that there are no modules in C++17,
> 
> Yeah, I wanted it as well, but if no standards committee proposal
> resulted from the clang experiments and there was no gcc
> implementation, it doesn't surprise me that it was considered too
> green for C++17.  They are really cautious about introducing new stuff
> into the standard that hasn't been well tested.

Some things get in faster, but I suppose in this case if the module
system under test turns out to have subtle flaws, it could cause /real/
problems for the future.

> 
>> and I felt it 
>> was unhelpful to have two competing (as I saw it) module systems.
> 
> I consider the standards proposal to be an evolution of the clang
> system instead of a competing system.  It is different because it
> incorporates the lessons learned from the clang experiments.

Fair enough.

> 
>> I presume they are waiting until a solution is finalised (rather than 
>> having yet another experimental version).
> 
> Lots of proposed stuff for C++11, C++14 and C++17 has been implemented
> from working paper proposals and the working proposal from Gabriel Dos
> Reis et al seems good enough to me to start a working implementation.
> 

Maybe they just haven't got round to it yet - there is no shortage of
tasks for the gcc developers (or clang developers, or, I expect, MSVC
developers).  But if MSVC implements this, and clang update their
implementation to the same working paper proposal, then I would expect
gcc to follow if the current proposal is considered solid enough.  It's
good not to have too many highly experimental implementations of a
feature, but also good to have more implementations once the feature
nears stability.

[toc] | [prev] | [next] | [standalone]

#47933

legalize+jeeves@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]

>If you look more deeply into what's been implemented in clang you find
>that it's somewhere between an advanced precompiled header and a
>module.  It's less than full-blown modules and it's more than a
>precompiled header.

I really don't see the advantage to this.   I worked for most of
a decade with a language called SPRITE which had modules, and
pre-compiled headers (called a Module Interface Definition).  One
big source file defining all the modules, the public and private
module interfaces, composite types and global variables.

For large projects (this was a mainframe operating system), there
was significant contention to edit the MID (somewhat alleviated by
the patch method used to edit - engineers would submit patches to
the MID Master file, which would be re-generated once a week or
thereabouts).

C++ was perfect at version 2.1, and has been going downhill
ever since.

[toc] | [prev] | [next] | [standalone]

#47947

On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:

> C++ was perfect at version 2.1, and has been going downhill
> ever since.

I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.

[toc] | [prev] | [next] | [standalone]

#47948

On Wed, 11 Jan 2017 19:55:32 -0800 (PST), jonkalb <google@kalbweb.com>
wrote:

>On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:
>
>> C++ was perfect at version 2.1, and has been going downhill
>> ever since.
>
>I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.


Before standardization, C++ usually had version numbers.  C++2.0 was
mostly what was described by the second edition of Stroustrup's "The
C++ Programming Language", or roughly the language as of 1989 (the
book was published in 1991).  What's called 2.1 is, I think, what
corresponds to the 3rd edition of that book (published 1997),
reflecting the language of a year or two prior to that.

All approximately.

[toc] | [prev] | [next] | [standalone]

#47953

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Wed, 11 Jan 2017 19:55:32 -0800 (PST), jonkalb <google@kalbweb.com>
>wrote:
>
>>On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:
>>
>>> C++ was perfect at version 2.1, and has been going downhill
>>> ever since.
>>
>>I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.
>
>
>Before standardization, C++ usually had version numbers.  C++2.0 was
>mostly what was described by the second edition of Stroustrup's "The
>C++ Programming Language", or roughly the language as of 1989 (the
>book was published in 1991).  What's called 2.1 is, I think, what
>corresponds to the 3rd edition of that book (published 1997),
>reflecting the language of a year or two prior to that.

2.1 came out about 1991, IIRC.   We started using C++ in
1989 for an operating system project, and upgraded to
Cfront 2.1 about '91 or thereabouts.

I think the 3rd edition of the book represents C++ 3.0
which was the first release to have templates and exceptions.

(In those days, C++ was compiled to C then compiled with
a vanilla C compiler (we used a port of PCC for the motorola
88100 RISC processor))

[toc] | [prev] | [next] | [standalone]

#48036

On Wednesday, January 11, 2017 at 8:21:38 PM UTC-8, robert...@yahoo.com wrote:
> On Wed, 11 Jan 2017 19:55:32 -0800 (PST), jonkalb <google@kalbweb.com>
> wrote:
> 
> >On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:
> >
> >> C++ was perfect at version 2.1, and has been going downhill
> >> ever since.
> >
> >I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.
> 
> 
> Before standardization, C++ usually had version numbers.

No.

>  C++2.0 was
> mostly what was described by the second edition of Stroustrup's "The
> C++ Programming Language", or roughly the language as of 1989 (the
> book was published in 1991).  What's called 2.1 is, I think, what
> corresponds to the 3rd edition of that book (published 1997),
> reflecting the language of a year or two prior to that.

You are referring to CFront version numbers, not language version numbers.

But at least I understand now what you meant.

[toc] | [prev] | [next] | [standalone]

#48087

jonkalb <google@kalbweb.com> writes:

>
>You are referring to CFront version numbers, not language version numbers.

The two were, of course, one and the same at the time.

[toc] | [prev] | [next] | [standalone]

#48110

On Monday, January 16, 2017 at 5:40:52 AM UTC-8, Scott Lurndal wrote:
> jonkalb <google@kalbweb.com> writes:
> 
> >
> >You are referring to CFront version numbers, not language version numbers.
> 
> The two were, of course, one and the same at the time.

No.

Even if there is only one compiler for a language there is still a difference between the compiler and the language.

In the case of C++ and CFront, by the time CFront 2.1 was released, there were C++ compilers available from Glockenspiel (Nov. '86), GNU (Dec. '87), Oregon Software (Jan. '88), and Zortech (Jun. '88). The Glockenspiel compiler was a CFront port, but had its own release numbers.

Jon

[toc] | [prev] | [next] | [standalone]

#48115

On Tuesday, 17 January 2017 07:46:10 UTC+2, jonkalb  wrote:
> On Monday, January 16, 2017 at 5:40:52 AM UTC-8, Scott Lurndal wrote:
> > jonkalb <google@kalbweb.com> writes:
> > 
> > >
> > >You are referring to CFront version numbers, not language version numbers.
> > 
> > The two were, of course, one and the same at the time.
> 
> No.
> 
> Even if there is only one compiler for a language there is still a difference between
> the compiler and the language.
> 
> In the case of C++ and CFront, by the time CFront 2.1 was released, there were
> C++ compilers available from Glockenspiel (Nov. '86), GNU (Dec. '87), Oregon
> Software (Jan. '88), and Zortech (Jun. '88). The Glockenspiel compiler was a
> CFront port, but had its own release numbers.

You write twice that version numbers of C++ reference implementation were
*incorrect* to use as version numbers of C++ specification. However
you fail second time to type what you consider as *correct*. What version
of C++ specification did CFront 2.1 implement? How you tell it? Why?
Since with just CFront version number as contender on stage it stays the
winner and any argumentation is waste of words. ;-)  

[toc] | [prev] | [next] | [standalone]

#47973

On 1/11/2017 10:06 AM, Scott Lurndal wrote:

> I really don't see the advantage to this.   I worked for most of
> a decade with a language called SPRITE which had modules, and
> pre-compiled headers (called a Module Interface Definition).  One
> big source file defining all the modules, the public and private
> module interfaces, composite types and global variables.

Dude, you were at Burroughs (later Unisys)?  I interviewed there
back in '84!!!

[toc] | [prev] | [next] | [standalone]

#47974

red floyd <dont.bother@its.invalid> writes:
>On 1/11/2017 10:06 AM, Scott Lurndal wrote:
>
>> I really don't see the advantage to this.   I worked for most of
>> a decade with a language called SPRITE which had modules, and
>> pre-compiled headers (called a Module Interface Definition).  One
>> big source file defining all the modules, the public and private
>> module interfaces, composite types and global variables.
>
>Dude, you were at Burroughs (later Unisys)?  I interviewed there
>back in '84!!!

Indeed.  In the Pasadena MCP group working on Omega (what became MCP/VS 2.0);
started in '83.

[toc] | [prev] | [next] | [standalone]

#47975

On 1/12/2017 10:13 AM, Scott Lurndal wrote:
> red floyd <dont.bother@its.invalid> writes:
>> On 1/11/2017 10:06 AM, Scott Lurndal wrote:
>>
>>> I really don't see the advantage to this.   I worked for most of
>>> a decade with a language called SPRITE which had modules, and
>>> pre-compiled headers (called a Module Interface Definition).  One
>>> big source file defining all the modules, the public and private
>>> module interfaces, composite types and global variables.
>>
>> Dude, you were at Burroughs (later Unisys)?  I interviewed there
>> back in '84!!!
>
> Indeed.  In the Pasadena MCP group working on Omega (what became MCP/VS 2.0);
> started in '83.
>

No kidding?  That's where I interviewed!   As a side note, IIRC, SPRITE
looked a heck of a lot like Modula-2.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web