I have my own SmartPointer class.
There are cases where SmartPtr contain a class that inherite from a Base class, and I would like to convert SmartPtr<ClassX> into SmartPtr<BaseClassOfClassX>;
I am trying to overload the SmartPtr Conversion operator to do this.
It work fine for the Class themself, such as:
template<class newType>
operator SmartPtr<newType>() const
{
return SmartPtr<newType>((SmartPtr<newType>*)this);
}
but not for pointer to the Class, I have tried the following, and it never gets call and get the following error:
template<class newType>
operator SmartPtr<newType>*() const
{
return static_cast<SmartPtr<newType>*>(this);
}
Simple code to get the error:
SmartPtr<ClassX> test(pClassX);
SmartPtr<BaseClassOfClassX>* ob = &test;
ERROR:
cannot convert from 'SmartPtr<T> *' to 'SmartPtr<T> *'
Does anyone see what is wrong with my second conversion overload?
Thanks
From the C++ standard: "An operator function shall either be a non-static member function or be a non-member function and have at least one
parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration."
As the type of &test is not a class nor anything implicitly convertible to a class, you cannot overload the typecasts on the pointer directly. Depending on why you need pointers to your smart pointers, maybe you really want to employ references which is much more common.
Related
enum TokenType{
Eof,
Ws,
Unknow,
//lookahead 1 char
If,Else,
Id,
Int,
//lookahead 2 chars
Eq,Ne,Lt,Le,Gt,Ge,
//lookahead k chars
Real,
Sci
};
class Token{
private:
TokenType token;
string text;
public:
Token(TokenType token,string text):token(token),text(text){};
static Token eof(Eof,"Eof");
};
In this code I want to create a Token Object eof, but when I compile it it tells me that the Eof is not a Type. Why?
When I use TokenType token=TokenType::Eof it works. But when I passed the Eof into the constructor as a parameter, an error occurred. How could I solve it? Is it related to the scope. I try to use TokenType::Eof as the parameter also fail.
The problem is unrelated to the enumeration, the problem is that the compiler thinks you're declaring a function. For inline initialization use either curly braces {} or assignment-like syntax.
However, you can't define instances of a class inside the class itself, because the class isn't actually fully defined yet. It will also leas to a kind of infinite recursion (Token contains a Token object, which contains a Token object, which contains a Token object, ... and so on in infinity).
You can, on the other hand, define pointers to class inside itself, or references, because that doesn't require a fully defined class, only knowledge that the class exists.
So as a workaround perhaps use reference, that you initialize to a variable defined outside the class:
class Token
{
// ...
private:
static Token& eof; // Declare the reference variable
};
And in a source file:
namespace
{
// Define the actual "real" instance of the eof object
Token eof{ Eof, "Eof" };
}
// Define the reference and initialize it
Token& Token::eof = eof;
Look closely. The error messages tells you where exactly your error lies, including a line number. The compiler sees a function prototype, with Eof being the type of the first argument.
Because Eof is not a type, but just one possible value of a type.
It's really not clear what your design intent here is, but you need to make a clear mental difference between the type you've created, TokenType and its different values.
I have the following classes & interfaces:
export interface IBody {
body : ListBody;
}
export class Element {
// ...
}
export class Paragraph extends Element implements IBody {
// ...
}
export class Character extends Element {
// ...
}
I have code where I will get an array of Element derived objects (there are more than just Paragraph & Character). In the case of those that implement IBody, I need to take action on the elements in the body.
What is the best way to see if it implements IBody? Is it "if (element.body !== undefined)"?
And then how do I access it? "var bodyElement = <IBody> element;" gives me an error.
C:/src/jenova/Dev/Merge/AutoTagWeb/client/layout/document/elements/factory.ts(34,27): error TS2012: Cannot convert 'Element' to 'IBody':
Type 'Element' is missing property 'body' from type 'IBody'.
Type 'IBody' is missing property 'type' from type 'Element'.
thanks - dave
An interface in TypeScript is a compile-time only construct, with no run-time representation. You might find section 7 of the TypeScript specification interesting to read as it has the complete details.
So, you can't "test" for an interface specifically. Done correctly and completely, you generally shouldn't need to test for it as the compiler should have caught the cases where an object didn't implement the necessary interface. If you were to try using a type assertion:
// // where e has been typed as any, not an Element
var body = <IBody> e;
The compiler will allow it without warning as you've asserted that the type is an IBody. If however, e were an Element in scope, the compiler as you've shown will check the signature of the Element and confirm that it has the properties/methods declared by IBody. It's important to note that it's checking the signature -- it doesn't matter that it may not implement IBody as long as the signature matches up.
Assuming that Element has a signature that matches IBody, it will work. If it does not, you'll get the compiler error you're receiving. But, again, if it's declared as any, the assertion will pass and at run-time, unless the type has the methods defined on IBody, the script will fail.
As your Element is the base class, you cannot check for IBody. You could declare an argument as any:
function someFeature(e: any) {
}
And then assert that the IBody is present:
function someFeature(e: any) {
var body :IBody = <IBody> e;
// do something
}
However, if you do need a run-time check, you'd need to look for the function on the prototype or as a property before using it. While that could be misleading in some cases, the interface in TypeScript also may not have caught the mismatch either. Here's an example of how you could check for the existence of a specific function.
It might look like this:
function someFeature(e: any) {
var body = <IBody> e;
if (typeof (body.someFunctionOnBodyInterface) === "undefined") {
// not safe to use the function
throw new Error("Yikes!");
}
body.someFunctionOnBodyInterface();
}
I have two methods like so:
Foo[] GetFoos(Type t) { //do some stuff and return an array of things of type T }
T[] GetFoos<T>()
where T : Foo
{
return GetFoos(typeof(T)) as T[];
}
However, this always seems to return null. Am I doing things wrong or is this just a shortfall of C#?
Nb:
I know I could solve this problem with:
GetFoos(typeof(T)).Cast<T>().ToArray();
However, I would prefer to do this wothout any allocations (working in an environment very sensitive to garbage collections).
Nb++:
Bonus points if you suggest an alternative non allocating solution
Edit:
This raises an interesting question. The MSDN docs here: http://msdn.microsoft.com/en-us/library/aa664572%28v=vs.71%29.aspx say that the cast will succeed if there is an implicit or explicit cast. In this case there is an explicit cast, and so the cast should succeed. Are the MSDN docs wrong?
No, C# casting isn't useless - you simply can't cast a Foo[] to a T[] where T is a more derived type, as the Foo[] could contain other elements different to T. Why don't you adjust your GetFoos method to GetFoos<T>()? A method only taking a Type object can easily be converted into a generic method, where you could create the array directly via new T[].
If this is not possible: Do you need the abilities an array offers (ie. indexing and things like Count)? If not, you can work with an IEnumerable<T> without having much of a problem. If not: you won't get around going the Cast<T>.ToArray() way.
Edit:
There is no possible cast from Foo[] to T[], the description in your link is the other way round - you could cast a T[] to a Foo[] as all T are Foo, but not all Foo are T.
If you can arrange for GetFoos to create the return array using new T[], then you win. If you used new Foo[], then the array's type is fixed at that, regardless of the types of the objects it actually holds.
I haven't tried this, but it should work:
T[] array = Array.ConvertAll<Foo, T>(input,
delegate(Foo obj)
{
return (T)obj;
});
You can find more at http://msdn.microsoft.com/en-us/library/exc45z53(v=VS.85).aspx
I think this converts in-place, so it won't be doing any re-allocations.
From what I understand from your situation, using System.Array in place of a more specific array can help you. Remember, Array is the base class for all strongly typed arrays so an Array reference can essentially store any array. You should make your (generic?) dictionary map Type -> Array so you may store any strongly typed array also while not having to worry about needing to convert one array to another, now it's just type casting.
i.e.,
Dictionary<Type, Array> myDict = ...;
Array GetFoos(Type t)
{
// do checks, blah blah blah
return myDict[t];
}
// and a generic helper
T[] GetFoos<T>() where T: Foo
{
return (T[])GetFoos(typeof(T));
}
// then accesses all need casts to the specific type
Foo[] f = (Foo[])GetFoos(typeof(Foo));
DerivedFoo[] df = (DerivedFoo[])GetFoos(typeof(DerivedFoo));
// or with the generic helper
AnotherDerivedFoo[] adf = GetFoos<AnotherDerivedFoo>();
// etc...
p.s., The MSDN link that you provide shows how arrays are covariant. That is, you may store an array of a more derived type in a reference to an array of a base type. What you're trying to achieve here is contravariance (i.e., using an array of a base type in place of an array of a more derived type) which is the other way around and what arrays can't do without doing a conversion.
I am trying to do something like this. However the WithMetadata method wont let me.
Is this a problem in Autofac and should TScanningActivatorData in the WithMetadata overloads be changed to TActivatorData, or am i approaching this the wrong way?
builder.RegisterType(myType).As<IMyType().AsSelf().WithMetadata("somekey", delegate(Type t)
{
//dosomething
return t;
});
This gives me the error on the WithMetadata method: The type 'Autofac.Builder.ConcreteReflectionActivatorData' cannot be used as type parameter 'TScanningActivatorData' in the generic type or method 'Autofac.RegistrationExtensions.WithMetadata<TLimit,TScanningActivatorData,TRegistrationStyle>(Autofac.Builder.IRegistrationBuilder<TLimit,TScanningActivatorData,TRegistrationStyle>, string, System.Func<System.Type,object>)'. There is no implicit reference conversion from 'Autofac.Builder.ConcreteReflectionActivatorData' to 'Autofac.Features.Scanning.ScanningActivatorData'.
There's a more suitable overload for what you're trying to achieve. The t parameter passed in to the delegate is the same as myType - so the equivalent code is:
var someValue = DoSomething(myType);
builder.RegisterType(myType)
.As<IMyType>()
.AsSelf()
.WithMetadata("somekey", someValue);
The overload you've been looking at is for use with scanning registrations, e.g. when using RegisterAssemblyTypes() rather than RegisterType().
Hope this helps.
Nick
I'm trying to return a double from another object then store that into a new double but i'm getting the error incompatible types in initialization. What am I missing here?
double gradePoints = 0.0;
double other = [aCourse getGradePoints];
gradePoints = gradePoints + other;
This is in my other object
- (double) getGradePoints{
return 12.0;
}
Most likely you have forgotten to add the getGradePoints method to an interface declaration: This will result in the method being implicitly declared as -(id)getGradePoints; resulting in the warning you are seeing.
Is the reference to aCourse typed or is it an id? If I remember correctly, if the class of aCourse isn't known to the compiler, it assumes that the result of all method calls is type id.
The getter/setter kvo standard defines getters in the form of getPropertyName. If you have a property called gradePoints the compiler will interpret getGradePoints as the getter for that property and if the property is not defined as a double, it will complain.
Even defining a local variable like this:
double gradePoints = 0.0;
double other = [aCourse getGradePoints];
... may confuse the compiler because it may try to process getGradePoints as the getter for gradePoints.
Objective-C relies on naming conventions to find specific types of methods because it can't assume at compile time what methods an object in a particular circumstance will have.
In general you should avoid using method names that begin with "get" and "set" because the compiler wants to treat them as getter and setter methods for properties. The potential for compiler confusion is high.
I try to use prefixes like "fetch", "grab", "obtain" etc instead of "get" just to be safe.