Tag Info

Hot answers tagged

26

C++ casts are more restrictive (so express your intent better and make code review easier, etc.). They're also much easier to search for, if you ever need to.


19

First, understand that those lines are not equivalent. int* anInt = (int*)aFloat; // is equivalent to int* anInt = reinterpret_cast<int*>(aFloat); What is happening here is that the programmer is asking the compiler to do whatever it can to make the cast. The difference is important because using static_cast will only ask for a base type that is ...


15

In a weakly-typed language, type-casting exists to remove ambiguity in typed operations, when otherwise the compiler/interpreter would use order or other rules to make an assumption of which operation to use. Normally I would say PHP follows this pattern, but of the cases I've checked, PHP has behaved counter-intuitively in each. Here are those cases, ...


11

The problem is the line byte q1 = keyboard.nextByte() * 10;. There are no arithmetic operations on byte or short. The value of keyboard.nextByte() is casted up to an int prior to multiplication with 10, which is also an int. The result of the multiplication is an int, which can not be stored into q1 if it's defined as a byte. Possible solutions would be to ...


11

Option C: a "C++-style" cast, because it is indistinguishable from a construction: int anInt = int(aFloat); or even: int anInt(aFloat); That aside, other than these trivial cases with primitives, which are well understood, I prefer to use x_cast<>s over C-style casts. There are three reasons why: They more narrowly define the operation the ...


9

Casting in C is unique, quite unlike other languages. It is also never intelligent. Casting in C converts values from one type to another using carefully defined rules. If you really need to know, read the standard. Otherwise the main points are: Conversion between integer types preserve the value, if possible. If the destination has more bits this is ...


8

With other languages the situation is not so clear, but python happens to be specified in such a way that you can depend on it always casting to 1 and 0. Python's designers are some of the best with regard to the principle of least astonishment. The issue is that python is relatively rare as a first language, and programmers transfer practices from other ...


8

Languages that have implicit conversion to string usually have it for all types, not just numbers. Implicit conversions are usually bad if you want strong typing, type errors that could have been discovered in compile time(in case of compiled static-typed languages) or as exceptions in runtime(in case of interpreted or dynamic-typed languages) may turn into ...


7

If writing code in C use a C cast. If writing in C++ use a C++ cast. Whilst most casting breaks proper type-safety, the C++ ones are more restrictive, and therefore you are slightly less type-unsafe than you would be with a C cast. I can tolerate someone using (T*)NULL though to force an overload...


7

The reason that you can't pass cons as an argument to foldl1 without casting is that the type of cons simply does not match that of foldl1's function argument and your cast is in fact illegal - but, sadly, unchecked, so you don't get an exception right away (you will get one eventually though). You've defined foldl1 to take a function that takes two ...


7

Let's assume features start with 0 points, rather than with -100 points (due to costs associated with implementation, design, etc.). This feature strikes me as confusing. I've already declared that a is an A. If I want to know the compile-time type of a, I only have to look in one place, at the declaration. While I acknowledge that the implementation is ...


7

The title of your question asks "is it a good idea" but the body asks "what is the correct way to do this?" I will address the concern in the title. At its core, a boolean is simply a single bit. However, it represents truth, not a number: while a bit may represent zero or one, it represents true and false when that bit is a boolean. What does "true" mean ...


7

If you have a method that needs to know whether the specific class is of type Human in order to do something, then you are breaking some SOLID principles, particularly : Open/closed principle - if, in the future, you need to add a new animal type that can speak (for example, a parrot), or do something specific for that type, your existing code will have to ...


6

I would call it cardinality (and indeed I have used it in that sense). It is strictly the cardinality of the set of all values a variable can take. Edit: for example, a 16-bit integer can take exactly 65536 values. The cardinality of the set of all values that the integer can take is 655536. Once you start to consider variables that have a range of valid ...


5

This is to some extent a matter of style, but I really believe your single-line option is much, much less readable, and is not a common approach. The first classic if is very easy to read and check. There's no complex nesting, just a plain, "boring", chain of conditions that is well understood in all languages that have an if/else if/else construct. The ...


5

You're mixing the weak/strong and dynamic/static type concepts. PHP is weak and dynamic, but your problem is with the dynamic type concept. That means, variables don't have a type, values do. A 'type casting' is an expression that produces a new value of a different type of the original; it doesn't do anything to the variable (if one is involved). The ...


4

Theoretically speaking, the two concepts are vastly different: Type Casting refers to exchanging one type (roughly speaking, an object structure) for another while Type Conversion refers to translating of values (roughly speaking, contents of the object), so that they may be interpreted as belonging to a new type. Theoretically, they never mix. That said, ...


4

I have a few rules about C/C++-style casts: Dis-applying a const must always use a const_cast. For obvious reasons. Sadly, my rule about dis-applying a const causing the keyboard to reach up and break the programmer's finger was not approved. Any of the bit-manipulation-style shenanigans that programmers get up to when getting down to the metal should use ...


4

If you know that everything in the scene is an instance of Sprite, then there should be no problem with typecasting. You can enable RTTI and use dynamic_cast<Sprite *> to be extra certain. If there may be other GraphicsItem elements that are not instances of Sprite, then you could keep a set (perhaps QSet<GraphicsItem *>) which holds pointers to ...


4

If you subscribe to the "types as a set of values" interpretation of type theory, then cardinality is in fact a good name. So, the cardinality of bool would be 2, the cardinality of byte would be 256, and the cardinality of String would be ℵ0.


4

I think one reason why this isn't widespread has to do with the meaning of names within a programming language. The fact that a class A has a field x and a class B also has a field x does not prove that these two fields are in any way comparable - one might be a value in a 2-D coordinate system and the other a dependent variable in a statistical modelling ...


3

I went through this stuff earlier, and finally gave up on it, because even the types of simple functions like fold and map were so complicated that it makes programming with them in Java no fun. But the real pain starts when you need higher kinded types, like that of fmap. fmap :: Functor f => (a -> b) -> f a -> f b That is, if you not only ...


3

You cannot cast since they are different types; the language does not allow you since Java has a very strongly typed system. You can do this however: Integer fiveInteger = Integer.parseInt("5"); String fiveString = String.valueOf(5); In Java you have these types of legal casting: Primitive casting - casting between two primitive types int fiveInt = 5; ...


3

It really depends on which language I'm working with, since you know what they say: In Rome speak Roman. So if I'm programming in C, I try to use the C features to the max, but if I'm programming at C++ I go ahead and use C++ features to the max, even if some people don't like that approach because they say it makes the code "less portable", I say that I ...


3

Different languages define the words "cast" and "convert" differently; I don't think the question is meaningful other than in reference to a particular language. In C, for example, the term "cast" properly refers only to an explicit cast operator, consisting of a type name in parentheses preceding the expression to be converted. A "conversion" converts a ...


3

As the above posts note the C++ (static) cast is a bit safer in practice. It might be smart to look up some more information about the different kinds of casting and their pro's and cons. Just to have more of a background on why. . http://en.wikipedia.org/wiki/Static_cast http://en.wikipedia.org/wiki/Dynamic_cast ...


3

Alarm bells should be going off. But some top of my head initial suggestions (meaning I didn't take the time to come up with the best solution, just a much better one than you've got). 1 - Why is there a separate Message and Payload class, aren't they the same thing? 2 - Include the equality check in the subclasses where they take a payload instance as ...


3

It's not that it's a bad idea, it's just that there's no point in elevating this to the point of language feature, not even syntactic sugar, you can very easily implement this yourself in C#: public static class ExtensionMethods { public static void AsIf<T>(this object target, Action<T> todo) { if (target is T) todo((T)target); ...


3

An implementation of an interface is the realization of that interface. Realization is being implemented within the class. Just return an instance of the class (A or B) which realizes the return-type interface. interface IA{} class A: IA{} class UseIA { public IA DesiredMethod() { return new A(); } }


3

I don't think any language would explicitly support such operation on language level. The major problem is it's complexity. It might look simple in your example, but if you look at something like Automapper, you will notice there is tons of complexity the user of such function would want/need. And the more complex a language feature is, the more use for it ...



Only top voted, non community-wiki answers of a minimum length are eligible