msvc, vc-7_0

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

msvc, vc-7_0

Arkadiy Vertleyb
Hi all,

I can't see a column for one of these compilers even in the full regression
view...  Does anyone still care to support them?  Does anyone care if typeof
supports these compilers?

Regards,
Arkadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[tuple] status

Kevin Heifner
In Feb 2005 there was a discussion of boost::tuple lib being
replaced with a different more std::tr1 conforming version from
boost::fusion.  What is the status of this change?

Thanks,
KevinH
--
Kevin Heifner  heifner @ ociweb.com  http://heifner.blogspot.com
           Object Computing, Inc. (OCI) www.ociweb.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [tuple] status

John Maddock
> In Feb 2005 there was a discussion of boost::tuple lib being
> replaced with a different more std::tr1 conforming version from
> boost::fusion.  What is the status of this change?

No progress as such, as far as I know (at least as far as Boost.Tuple goes),
however the TR1 lib is using the new tuple code behind the scenes.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [tuple] status

Joel de Guzman-2
John Maddock wrote:
>>In Feb 2005 there was a discussion of boost::tuple lib being
>>replaced with a different more std::tr1 conforming version from
>>boost::fusion.  What is the status of this change?
>
>
> No progress as such, as far as I know (at least as far as Boost.Tuple goes),
> however the TR1 lib is using the new tuple code behind the scenes.

That's not exactly true. There's progress! :)

Fusion is in the review queue. Some people say that we should just
go ahead and change the old with the new. However, fusion is too
big a departure from the original tuple library. There are lots
more sequences (e.g. vector/list/set/map), an extensive set of
views), there are algorithms and iterators, etc. I'd rather regard
Fusion as an entire new library of its own. The TR1 compatibility
layer is a mere fraction of its capabilities.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: msvc, vc-7_0

Daniel Wallin
In reply to this post by Arkadiy Vertleyb
Arkadiy Vertleyb wrote:
> Hi all,
>
> I can't see a column for one of these compilers even in the full regression
> view...  Does anyone still care to support them?  

Yes.

> Does anyone care if typeof supports these compilers?

And yes. IIUC typeof uses a bug-feature on those compilers that makes
the implementation trivial, is that correct? In that case, IMO, there's
little reason not to support them.

--
Daniel Wallin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: msvc, vc-7_0

Arkadiy Vertleyb
"Daniel Wallin" <[hidden email]> wrote

> Arkadiy Vertleyb wrote:
> >
> > I can't see a column for one of these compilers even in the full
regression
> > view...  Does anyone still care to support them?
>
> Yes.
>
> > Does anyone care if typeof supports these compilers?
>
> And yes. IIUC typeof uses a bug-feature on those compilers that makes
> the implementation trivial, is that correct? In that case, IMO, there's
> little reason not to support them.

I didn't mean to drop this.  The bugfeature is also applied to vc-7_1, which
makes it relevant even without tools mentioned.  My question was actually
caused by some code in LVALUE_TYPEOF that needs to use ifdefs based on
whether or not partial template specialization is supported, and whether or
not a function can return a reference to array.  I lately run into a problem
with gcc 4.0.2, that doesn't seem to like the workaround we used (returning
pointer to array), so I was looking to somehow reduce the number of ifdefs
to a manageble amount.

Also, if the regression tests no longer run for these tools, how can one
guarantee the support?  Or is this temporary, and these tools are going to
re-appear in the regression tables?

Regards,
Arkadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: msvc, vc-7_0

Aleksey Gurtovoy
Arkadiy Vertleyb writes:
> Also, if the regression tests no longer run for these tools, how can
> one guarantee the support?  Or is this temporary, and these tools
> are going to re-appear in the regression tables?

The latter.

--
Aleksey Gurtovoy
MetaCommunications Engineering
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost