King_DuckZ/Loki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

no message

Browse source 
git-svn-id: svn://svn.code.sf.net/p/loki-lib/code/trunk@107 7ec92016-0320-0410-acc4-a06ded1c099a
This commit is contained in:
humesikkins 2003-02-27 15:56:49 +00:00
parent 4bfc42e511
commit 80e63b12a3
1 changed files with 319 additions and 215 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

534
MSVC/1200/Readme.txt
View file

@ -1,6 +1,6 @@
Loki VC 6.0 Port or how to produce C1001 - Internal Compiler Errors Loki VC 6.0 Port or how to produce C1001 - Internal Compiler Errors
------------------------------------------------------------------- -------------------------------------------------------------------
Version: 0.3b Version: 0.5
Introduction/Compatibility: Introduction/Compatibility:
--------------------------- ---------------------------
@ -29,45 +29,64 @@ If you use Singletons with longevity you must add Singleton.cpp to your project/
Fixes: Fixes:
------ ------
Jan 30, 2003: Feb 2003:
------------- ---------
* In TypeTraits.h: Fixed bugs in TypeTraits' scalar and array detection. * created new versions of Functor.h, Visitor.h and MultiMethods.h that
const and volatile detection is now based on techniques from boost's type traits now can handle void return types transparently.
(see http://www.boost.org/libs/type_traits/)
Added Enum- and pointer-to-member-function-detection code. * ported SmartPtr's Ownership-Policy RefCountedMT
Thanks to M. Yamada.
* Added isFunctionPointer to TypeTraits.
* Replaced all pointer-type dummy-parameters needed as a workaround
for VC's 'explicit template argument specification'-bug with Typ2Type-dummy
parameters.
* fixed the problems with BindFirst (Functor.h) that led to
C1001-Internal compiler errors.
* fixed numerous other bugs.
Jan 30, 2003:
-------------
* In TypeTraits.h: Fixed bugs in TypeTraits' scalar and array detection.
const and volatile detection is now based on techniques from boost's type traits
(see http://www.boost.org/libs/type_traits/)
Added Enum- and pointer-to-member-function-detection code.
Thanks to M. Yamada.
Jan 12, 2003: Jan 12, 2003:
------------- -------------
* changed the signature of SmallObject's op new. Now it * changed the signature of SmallObject's op new. Now it
matches the corresponding op delete. matches the corresponding op delete.
Thanks to M.Yamada for the hint and the solution. Thanks to M.Yamada for the hint and the solution.
Dec 08, 2002: Dec 08, 2002:
------------- -------------
* In HierarchyGenerators.h: Sergey Khachatrian reported a bug * In HierarchyGenerators.h: Sergey Khachatrian reported a bug
in GenScatterHierarchy when used with a typelist containing in GenScatterHierarchy when used with a typelist containing
equal types (e.g. GenScatterHierarchy<TYPELIST_2(int, int), UnitWrapper> equal types (e.g. GenScatterHierarchy<TYPELIST_2(int, int), UnitWrapper>
resp. Tuple<TYPELIST_2(int, int)>) resp. Tuple<TYPELIST_2(int, int)>)
Fixing the bug I found another MSVC6-Problem in the Field-function. Fixing the bug I found another MSVC6-Problem in the Field-function.
The workaround for this problems results in an interface change. The workaround for this problems results in an interface change.
please refer to the section "Interface changes" below for further information. please refer to the section "Interface changes" below for further information.
Dec 03, 2002 Dec 03, 2002
------------- -------------
* In MSVC6Helpers.h: The original version failed to qualify some types from the * In MSVC6Helpers.h: The original version failed to qualify some types from the
Private-Namespace. Private-Namespace.
Thanks to Adi Shavit for pointing that out Thanks to Adi Shavit for pointing that out
* In Threads.h: Changed wrong ctor/dtor names in ObjectLevelLockable. * In Threads.h: Changed wrong ctor/dtor names in ObjectLevelLockable.
Thanks to Adi Shavit for pointing that out Thanks to Adi Shavit for pointing that out
Nov 19, 2002: Nov 19, 2002:
------------- -------------
* In SmartPtr.h: Changed template ctors. See Notes. * In SmartPtr.h: Changed template ctors. See Notes.
Notes: Notes:
------ ------
@ -77,96 +96,132 @@ A. partial template specialization.
B. template template parameters. B. template template parameters.
C. explicit template argument specification for member- and nonmeber functions. C. explicit template argument specification for member- and nonmeber functions.
D. covariant return types. D. covariant return types.
E. Template parameters with a default type void E. Template parameters with default type void
F. return statements with an expression of type cv in functions with a return type of cv void. F. return statements with an expression of type cv void in functions with a return type of cv void.
Unfortunately the MSVC 6.0 supports neither of them. Unfortunately the MSVC 6.0 supports neither of them.
A. I used various techniques to simulate partial template specialization. In some cases A. I used various techniques to simulate partial template specialization. In some cases
these techniques allowed me to retain the original interfaces but often that was not these techniques allowed me to retain the original interfaces but often that was not
possible (or better: i did not find a proper solution). In any case it leads possible (or better: i did not find a proper solution). In any case it led
to increasing code complexity :-) to increasing code complexity :-)
B. One way to simulate template template parameters is to replace the template class with B. One way to simulate template template parameters is to replace the template class with
a normal class containing a nested template class. You then move the original functionality a normal class containing a nested template class. You then move the original functionality
to the nested class. to the nested class.
The problem with this approach is MSVC's 'dependent template typedef bug'. MSVC 6.0 does not The problem with this approach is MSVC's 'dependent template typedef bug'.
allow something like this: MSVC 6.0 does not allow something like this:
[code]
template <class APolicy, class T>
struct Foo
{
// error C2903: 'In' : symbol is neither a class template nor a function template
typedef typename APolicy::template In<T> type;
};
[/code]
To make a long story short, I finally decided to use boost::mpl's apply-technique to
simulate template template parameters. This approach works fine with MSVC 6.0. But be warned,
this technique uses not valid C++.
Of course, replacing template template parameters always results in some interface changes.
C. I added dummy-Parameters to (Member-)Functions that depend on explicit template
argument specification. These dummy-Parameters help the compiler in deducing the template
parameters that otherwise need to be explicitly specified.
Example:
[code]
struct Foo
{
template <class T>
T Func();
};
[/code]
becomes
[code]
struct Foo
{
template <class T>
T Func(Type2Type<T>);
};
[/code]
in this port.
Update:
-------
The MSVC 6.0 sometimes does not overload normal functions depending
on explicit argument specification correctly (see: Microsoft KB Article - 240871)
The following code demonstrates the problem:
[code]
template <unsigned i, class T>
void BugDemonstration(T p)
{
printf("BugDemonstration called with i = %d\n", i);
}
int main()
{
GenScatterHierarchy<TYPELIST_3(int, int, int), TestUnitWrapper> Bla;
// will always print: "BugDemonstration called with i = 2";
BugDemonstration<0>(Bla);
BugDemonstration<1>(Bla);
BugDemonstration<2>(Bla);
}
[/code]
As a workaround i added dummy-parameters (of type Int2Type).
D. Virtual functions that use covariant return types (e.g. return a pointer to Derived)
in the original library were changed so that they have exactly the
same return type as the original virtual function (e.g. return a pointer to Base).
E. All template parameters that have a default type of void in the original lib now
have int as default type.
F. To workaround void returns I did the following:
From every original class I moved those functions that potentially
produce void returns to new classes. One for the general case and
one for the void case.
In the class for the general case I implemented the functions in the original way.
In the class for the void case I removed the return statements and therefore the
potential void return.
Depending on the return type, the original class inherits from the
corresponding new class and thus gets the proper implementation of
the previously removed functions.
For example:
[code] [code]
template <class APolicy, class T> template <class R> struct Foo
struct Foo
{ {
// 'error C1001 - Internal Compiler Error' here R Func() { return R(); }
typedef typename APolicy::template In<T> type;
};
[/code]
To make a long story short, I finally decided to use boost::mpl's apply-technique to
simulate template template parameters. This approach works fine with MSVC 6.0. But be warned,
this technique uses not valid C++.
Of course, replacing template template parameters always results in some interface changes.
C. I added dummy-Parameters to (Member-)Functions that depend on explicit template
argument specification. These dummy-Parameters help the compiler in deducing the template
parameters that otherwise need to be explicitly specified.
Example:
[code]
struct Foo
{
template <class T>
T Func();
}; };
[/code] [/code]
becomes becomes:
[code] [code]
struct Foo namespace Private
{ {
template <class T> template <class R> struct FooBase
T Func(T* pDummy1); {
}; R Func() {return R();}
[/code] };
in this port. struct FooVoidBase
{
Update: typedef void R;
------- R Func() {}
The MSVC 6.0 sometimes does not overload normal functions depending };
on explicit argument specification correctly (see: Microsoft KB Article - 240871)
The following code demonstrates the problem:
[code]
template <unsigned i, class T>
void BugDemonstration(T p)
{
printf("BugDemonstration called with i = %d\n", i);
}
int main()
{
GenScatterHierarchy<TYPELIST_3(int, int, int), TestUnitWrapper> Bla;
// will always print: "BugDemonstration called with i = 2";
BugDemonstration<0>(Bla);
BugDemonstration<1>(Bla);
BugDemonstration<2>(Bla);
} }
template <class R>
struct Foo : public Select<IsVoid<R>::value, FooVoidBase, FooBase<R> >::Result
{};
[/code] [/code]
Please note that *all* new base classes are only meant as a hidden
As a workaround i added dummy-parameters. implementation detail.
You should never use any of them directly or indirectly. In particular don't
D. Virtual functions that use covariant return types (e.g. return a pointer to Derived) make use of the possible derived-to-base conversion.
in the original library were changed so that they have exactly the
same return type as the original virtual function (e.g. return a pointer to Base). In the old version of Functor.h I changed a ResultType of type void to
VoidAsType (an udt). This change is transparent to the user of Functor.
E. All template parameters that have a default type of void in the original lib now
have int as default type.
F. In Functor.h I changed a ResultType of type void to VoidAsType (an udt). This change is
transparent to the user of Functor.
Because I could not think of any general and transparent workaround I followed different
strategies. In Visitor.h for example I created new classes (and macros) for the void-case.
In other places (for example: MultiMethod.h) this port simply fails to support void as
return type :-(
Some words to template-ctors resp. template assignment operators: Some words to template-ctors resp. template assignment operators:
The MSVC 6.0 introduces an order-dependency for template ctor The MSVC 6.0 introduces an order-dependency for template ctor
resp. template assignemt operators. resp. template assignemt operators.
@ -177,11 +232,11 @@ So instead of
template <class T> template <class T>
struct Foo struct Foo
{ {
Foo(const Foo&) Foo(const Foo&)
{} {}
template <class U> template <class U>
Foo(const Foo<U>& r) Foo(const Foo<U>& r)
{} {}
}; };
[/code] [/code]
you *need* to write: you *need* to write:
@ -189,12 +244,12 @@ you *need* to write:
template <class T> template <class T>
struct Foo struct Foo
{ {
template <class U> template <class U>
Foo(const Foo<U>& r) Foo(const Foo<U>& r)
{} {}
Foo(const Foo& r) Foo(const Foo& r)
{} {}
}; };
[/code] [/code]
@ -207,12 +262,12 @@ the form of a copy-ctor. If you write something like this (as in the functor-cla
template <class T> template <class T>
struct Foo struct Foo
{ {
template <class Fun> template <class Fun>
Foo(Fun r) Foo(Fun r)
{} {}
Foo(const Foo& r) Foo(const Foo& r)
{} {}
}; };
[/code] [/code]
then the VC will no longer find a copy-ctor. then the VC will no longer find a copy-ctor.
@ -223,122 +278,122 @@ Interface changes:
------------------ ------------------
1. In Threads.h: 1. In Threads.h:
* Thread-Policies changed from class templates to normal classes containing a * Thread-Policies changed from class templates to normal classes containing a
nested class template 'In'. nested class template 'In'.
consequences: consequences:
This change is not very dramatic because it won't break code using this port when This change is not very dramatic because it won't break code using this port when
switching to the original library (only new Thread-Policies must be changed) switching to the original library (only new Thread-Policies must be changed)
2. In Singleton.h: 2. In Singleton.h:
* The Creation- and Lifetime-Policies are no longer class templates. Instead they all use * The Creation- and Lifetime-Policies are no longer class templates. Instead they all use
Member-Templates. Member-Templates.
consequences: consequences:
Again this change will only break new Policies when switching to the Again this change will only break new Policies when switching to the
original library. original library.
3. In Functor.h: 3. In Functor.h:
* No covariant return types. * No covariant return types.
consequences: consequences:
DoClone always returns a FunctorImplBase<R, ThreadingModel>* where R is the functor's return DoClone always returns a FunctorImplBase<R, ThreadingModel>* where R is the functor's return
type and ThreadingModel its current ThreadingModel. type and ThreadingModel its current ThreadingModel.
4. TypeTraits.h 4. TypeTraits.h
* Because VC 6.0 lacks partial template specialization, the TypeTraits-Class * Because VC 6.0 lacks partial template specialization, the TypeTraits-Class
fails to provide the following typedefs: fails to provide the following typedefs:
PointeeType, ReferredType, NonVolatileType and UnqualifiedType. PointeeType, ReferredType, NonVolatileType and UnqualifiedType.
* Since the VC 6 does not differentiate * Since the VC 6 does not differentiate
between void, const void, volatile void and const volatile void the following between void, const void, volatile void and const volatile void the following
assertions will fail: assertions will fail:
assert(TypeTraits<const void>::isConst == 1) assert(TypeTraits<const void>::isConst == 1)
assert(TypeTraits<volatile void>::isVolatile == 1) assert(TypeTraits<volatile void>::isVolatile == 1)
assert(TypeTraits<const volatile void>::isConst == 1) assert(TypeTraits<const volatile void>::isConst == 1)
assert(TypeTraits<const volatile void>::isVolatile == 1) assert(TypeTraits<const volatile void>::isVolatile == 1)
* This port adds isEnum and isMemberFuncPointer * This port adds isEnum, isMemberFunctionPointer and isFunctionPointer.
5. HierarchyGenerator.h 5. HierarchyGenerator.h
* I used Mat Marcus' approach to port GenScatterHierarchy. * I used Mat Marcus' approach to port GenScatterHierarchy.
See http://lists.boost.org/MailArchives/boost/msg20915.php) for the consequences. See http://lists.boost.org/MailArchives/boost/msg20915.php) for the consequences.
* Same for GenLinearHierarchy * Same for GenLinearHierarchy
* Unit is no longer a template template parameter. * Unit is no longer a template template parameter.
consequences: consequences:
For every concrete unit-template there must be a normal class containing For every concrete unit-template there must be a normal class containing
a nested-template class called 'In'. 'In' should only contain a typedef to the a nested-template class called 'In'. 'In' should only contain a typedef to the
concrete Unit. concrete Unit.
Update: Update:
The port's original version of GenScatterHierarchy does not work when used The port's original version of GenScatterHierarchy does not work when used
with typelists containing equal types. with typelists containing equal types.
The problem is due to a VC bug. The VC fails to compile code similar The problem is due to a VC bug. The VC fails to compile code similar
to this, although it is perfectly legal. to this, although it is perfectly legal.
[code] [code]
template <class T> template <class T>
class Wrapper class Wrapper
{}; {};
template <class T> template <class T>
struct B : public Wrapper<T> struct B : public Wrapper<T>
{}; {};
// ERROR: 'A<T>' : direct base 'Wrapper<T>' is inaccessible; already a base of 'B<T>' // ERROR: 'A<T>' : direct base 'Wrapper<T>' is inaccessible; already a base of 'B<T>'
template <class T> template <class T>
class A : public B<T>, public Wrapper<T> class A : public B<T>, public Wrapper<T>
{}; {};
[/code] [/code]
Unfortunately my workaround has a big drawback. Unfortunately my workaround has a big drawback.
GenScatterHierarchy now has to generate a lot more classes. GenScatterHierarchy now has to generate a lot more classes.
Alexandrescu's original implementation generates 3*n classes (n - number of types in the typelist) Alexandrescu's original implementation generates 3*n classes (n - number of types in the typelist)
The old version of my port creates 4 * n + 1 The old version of my port creates 4 * n + 1
The new version will create 5 * n The new version will create 5 * n
The fix also reveals the "Explicitly Specified Template Functions Not Overloaded Correctly"-Bug The fix also reveals the "Explicitly Specified Template Functions Not Overloaded Correctly"-Bug
(Microsoft KB Article - 240871) in the Field-Function taking a nontype int Parameter. (Microsoft KB Article - 240871) in the Field-Function taking a nontype int Parameter.
This leads to an interface change: This leads to an interface change:
Instead of: Field<0>(obj) Instead of: Field<0>(obj)
one now has to write one now has to write
Field(obj, Int2Type<0>()); Field(obj, Int2Type<0>());
I added a macro FIELD. Using this macro one can write I added a macro FIELD. Using this macro one can write
FIELD(obj, 0) FIELD(obj, 0)
6. Factory.h 6. Factory.h
* The Error-Policy for Factory and CloneFactory is no longer a template template parameter. * The Error-Policy for Factory and CloneFactory is no longer a template template parameter.
Use a class with member-templates instead. Use a class with member-templates instead.
consequences: consequences:
This change will only break new Policies when switching to the This change will only break new Policies when switching to the
original library. original library.
7. AbstractFactory.h 7. AbstractFactory.h
* no covariant return types * no covariant return types
* no template template parameters * no template template parameters
For every concrete Factory-Unit there must be a normal class containing For every concrete Factory-Unit there must be a normal class containing
a nested-template class called 'In'. 'In' shall contain a typedef to the a nested-template class called 'In'. 'In' shall contain a typedef to the
concrete Factory-Unit. concrete Factory-Unit.
* Added a dummy-Parameter to AbstractFactory::Create (see C.) * Added a dummy-Parameter to AbstractFactory::Create (see C.)
Calling syntax changed from: Calling syntax changed from:
ConcProduct* p = aFactory.Create<ConcProduct>(); ConcProduct* p = aFactory.Create<ConcProduct>();
to to
ConcProduct* p = aFactory.Create((ConcProduct*)0); ConcProduct* p = aFactory.Create(Type2Type<ConcProduct>());
8. SmartPtr.h 8. SmartPtr.h
@ -350,27 +405,76 @@ Interface changes:
9. Visitor.h 9. Visitor.h
* no template template parameters * no template template parameters
(see 7.for a description of the consequences) (see 7.for a description of the consequences)
* This port fails to correctly support void return types. As a workaround it provides
a set of complete new classes (and macros) for void. Default arguments of type void
were replaced by arguments of type int.
* This port fails to correctly support void return types. As a workaround it provides
a set of complete new classes (and macros) for void. Default arguments of type void
were replaced by arguments of type int.
Update:
-------
In the new version of Visitor.h there are no longer extra classes for void.
Instead the original classes are now able to handle the return type void.
However there are still two sets of macros. One for return type = void
(DEFINE_VISITABLE_VOID, DEFINE_CYCLIC_VISITABLE_VOID) and one for return
type != void (DEFINE_VISITABLE, DEFINE_CYCLIC_VISITABLE)
10. MultiMethods.h 10. MultiMethods.h
* replaced all template template parameters with 'normal' parameters (see 7. * replaced all template template parameters with 'normal' parameters (see 7.
for a description of the consequences) for a description of the consequences)
* This port does not support functions with return type void. * This port does not support functions with return type void.
* dummy parameters were added to functions that otherwise would depend on
explicit template argument specification (14.8.1).
* dummy parameters were added to functions that otherwise would depend on
explicit template argument specification (14.8.1).
Update:
-------
* The port now supports functions with return type void.
Some words to BasicDispatcher:
------------------------------
You can't use a (namespace level) template function as callback-function
for BasicDispatcher. This is because using the VC 6.0 you can't explicity
specify the template-paramters when adding the concrete function instance
to the dispatcher.
Normaly you can write something like this:
[code]
template <class DerivedShape1, class DerivedShape2>
int HatchShapes(Shape&, Shape&) {...}
typedef ::Loki::BasicDispatcher<Shape> Dispatcher;
void Func(Dispatcher& x)
{
x.Add(&HatchShapes<Circle, Rectangle>);
}
[/code]
Using the VC 6.0 this is not possible, because there is no
way to specify the types for DerivedShape1 and DerivedShape2 (at least
I know of no way).
As a workaround use a helper-template class in conjunction with
a static member function:
[code]
template <class DerivedShape1, class DerivedShape2>
struct Hatch_Helper
{
int HatchShapes(Shape&, Shape&) {...}
};
typedef ::Loki::BasicDispatcher<Shape> Dispatcher;
void Func(Dispatcher& x)
{
x.Add(&Hatch_Helper<Circle, Rectangle>::HatchShapes);
}
More info: More info:
---------- ----------
The original Loki library can be found here: http://moderncppdesign.com The original Loki library can be found here: http://moderncppdesign.com
For Rani Sharoni's VC 7.0 port see: http://www.geocities.com/rani_sharoni/LokiPort.html For Rani Sharoni's VC 7.0 port see: http://www.geocities.com/rani_sharoni/LokiPort.html