casting

问题 To my surprise, I get the following statement: public static IEnumerable<SomeType> AllEnums => Enum.GetValues(typeof(SomeType)); to complain about not being able to convert from System.Array to System.Collection.Generic.IEnumerable . I thought that the latter was inheriting from the former. Apparently I was mistaken. Since I can't LINQ it or .ToList it, I'm not sure how to deal with it properly. I'd prefer avoiding explicit casting and, since it's a bunch of values for an enum , I don't think

问题 In boost::detail::addressof_impl::f() a series of reinterpret_cast s is done to obtain the actual address of the object in case class T has overloaded operator&() : template<class T> struct addressof_impl { static inline T* f( T& v, long ) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char&>(v))); } } What's the purpose of cast to const volatile char& instead of just casting to char& ? 回答1: A cast straight to char& would fail if T has const or volatile

问题 Is there a reason why in c++ std::string is not implicitly converted to bool? For example std::string s = "" if (s) { /* s in not empty */ } as in other languages (e.g. python). I think it is tedious to use the empty method. 回答1: This probably could be added now that C++11 has added the concepts of explicit conversions and contextual conversion. When std::string was designed, neither of these was present though. That made classes that supported conversion to bool fairly difficult to keep safe

问题 What is the difference between the following F# casting operators? I can't seem to understand why and how they are all different. (type) X X :> type X :?> type 回答1: The first isn't a cast in F#, though if you're used to C# it might appear that it works like one. But this is actually invoking a type conversion function (like int ), and the parentheses aren't actually required (and are just likely to make everything more confusing). (int) "4" // the number 4 - this is a conversion, not a cast

问题 I am well aware of the advantage in using static_cast rather than C-style casting for pointer types. If the pointer types are incompatible, then: static_cast will yield a compile-time error at a specific line within the source code C-style casting might lead to a runtime error at a "random" point in the execution of the program But I am unable to find any similar example for non-pointer types. In other words, both casting methods yield the same result for non-pointer types. Is that correct,

问题 I am new to scala and I am finding the need to convert a boolean value to an integer. I know i can use something like if (x) 1 else 0 but I would like to know if there is a preferred method, or something built into the framework (ie toInt() ) 回答1: If you want to mix Boolean and Int operation use an implicit as above but without creating a class: implicit def bool2int(b:Boolean) = if (b) 1 else 0 scala> false:Int res4: Int = 0 scala> true:Int res5: Int = 1 scala> val b=true b: Boolean = true

问题 I was taken aback earlier today when debugging some code to find that something like the following does not throw a compile-time exception: public Test () { HashMap map = (HashMap) getList(); } private List getList(){ return new ArrayList(); } As you can imagine, a ClassCastException is thrown at runtime, but can someone explain why the casting of a List to a HashMap is considered legal at compile time? 回答1: Because conceivably getList() could be returning a subclass of HashMap which also

问题 I am working with an 8-bit AVR chip. There is no data type for a 64-bit double (double just maps to the 32-bit float). However, I will be receiving 64-bit doubles over Serial and need to output 64-bit doubles over Serial. How can I convert the 64-bit double to a 32-bit float and back again without casting? The format for both the 32-bit and 64-bit will follow IEEE 754. Of course, I assume a loss of precision when converting to the 32-bit float. For converting from 64-bit to 32-bit float, I am

问题 This question already has an answer here : Constructor-style casting in function call parameters (1 answer) Closed 5 years ago . I am porting some C++ code to GCC, and apperantly it isn't happy with C++ style casting when sapces are involved, as in unsigned int(-1) , long long(ShortVar) etc... It gives an error: expected primary-expression before 'long' . Is there any way to make peace with GCC without going over each one of those and rewrite in c-style? 回答1: GCC is correctly crying --

问题 all. I can't undestand why the bellow code need a cast to work. Someone can explain it? class Base { }; class Derived : public Base { }; class Class { public: Derived member; }; ... Derived obj; Base *ptrObj = &obj; // ok, no cast needed Derived Class::* ptr = &Class::member; // ok Base Class::* ptr = &Class::member; // wrong, need cast, why? 回答1: Because if Base were allowed (covariant), you could then do this, which is a no-no: Base Class::* ptr = &Class::member; Class obj; obj.*ptr = Base(