Talk:Type conversion

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science  
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Table for programming languages[edit]

c#, Java, Perl, Haspell, javascript, Coffescript, Haxe, livescript, Lua, Ruby, Closure, Scala, etc

- strong/weak, declaration necessary/optional/possible, inference, implicit typing, strict/dynamic,  implicit conversion,...

Perhaps another new article? — Preceding unsigned comment added by 91.113.38.50 (talk) 19:23, 9 February 2014 (UTC)

Off topic[edit]

This article is off topic. Most of it is not "Type conversion" but "tutorial to C/C++ cast operation".

I did some to improve (see history) but I would ask the C/C++ advocates to consider two things:

  1. tutorials belong to wikibooks.
  2. that there are other programming languages where "Type conversion" has a more broader meaning.

and maybe improve the C/C++ chapter.

You are right in that the current article is not good at all. But we need to remember that C++ has quite complex type conversion system, compared with others. The problem is the shortcoming, which is not intentionally done by C/C++ advocates but is mere result of lack of contributions so far. If you think the article goes too deep, take a look at LR parser and the like. -- Taku 04:27, Nov 30, 2004 (UTC)
Did you read my Ada article? C++ is not the only language with a complex type conversion system. And of corse is should be described in wiki. The question I was trying to raise was "wikipedia vs wikibooks". How much of C/C++ cast need to be described in wikipedia "The Free Encyclopedia" and what should better moved to wikibooks "Think Free. Learn Free". --Krischik 09:43, 30 Nov 2004 (UTC)
I support the idea of a merger between "typecasting" and "type conversion". I was searching for dynamic_cast<>. The first link I took brought me to "typecasting". However, I found the explanation on "type conversion". --Kriti 05:24, 24 Aug 2005(UTC)
I agree, typecasting needs to be merged with this article. Both articles need work. -- Doug Bell (talk/contrib) 20:52, 16 January 2006 (UTC)
I am looking for a way to convert a string to integer when you know the string character is a number like 7. --Mrja84 20:14, 11 Oct 2005(ESDT)
Of course, this depends on the language and primitives you want to use. But since you're asking, the answer could be *string - '0'. --TuukkaH 14:45, 12 October 2005 (UTC)
I believe there should be a least 3 separate pages linked from the Type_conversion page, those being pages for static_cast, reinterpret_cast, and dynamic_cast. --IanVaughan 11:44, 9 Nov 2006 (UTC)
I find this quite confusing, I have to say. Type conversion and type casting are very different things. Type casting being making the compiler think that something is a different type, and type conversion actually turning one type into another, in some fashion, say using atoi, in C or Integer.parseInt in Java. K.

What is the aviation reference doing in this article? It needs to be moved to a separate article. -- Doug Bell (talk/contrib) 20:52, 16 January 2006 (UTC)

Ditto. One tiny section on aviation followed by an article on computer science is completely out-of-place. It should be moved to a separate article with a disambiguation page. -- Andrés Santiago Pérez-Bergquist 23:41, 16 February 2006 (UTC)

Overemphasis of Eiffel[edit]

It seems like the sections related to Eiffel are much larger than they should be, given the relative level of popularity of Eiffel. It would be more useful to show type conversion in other languages instead of so much on a fairly obscure language. In my opinion the long discourse of Eiffel's type conversion should go on an Eiffel page, or better yet, a new page. Smithderek2000 (talk) —Preceding undated comment added 00:04, 22 September 2012 (UTC)

Inaccuracies[edit]

The section on implicit type conversion contained false and misleading statements:

  • "For example, in the above comparisons, there would be a loss of information in a conversion from type double to type int if the value of d is larger than i can hold."
    False. The comparisons listed do not involve any conversion from double to int, but the other way around. Actually, any comparison involving a double and an int will have the int promoted to double, not the other way around.
  • Conversely, converting from an integral representation to a floating-point one can also lose precision, as floating-point representations are generally not capable of holding integer values precisely.
    Inaccurate. What is true is that a floating-point representation of n bits can never hold all integer values of n bits precisely, since there's just not enough room for both the exponent and the significand. However, an IEEE 754 double precision type is capable of representing all 32-bit integer values exactly, for example, so this statement is misleading, especially in the given context. 82.95.254.249 18:12, 29 March 2007 (UTC)
    • 32 bit to double can't lose precision but 64 bit to double or 32 bit to float can but i agree that section needs a rewrite. Plugwash 01:19, 31 March 2007 (UTC)
  • "...the fractional components of the floating-point values will be truncated (rounded down)."
    Those aren't the same thing. For negative numbers, rounding down means going to the next lower integer (ie floor), while truncating means removing the fractional part. 76.118.217.245 (talk) 19:28, 3 February 2008 (UTC)

Another inaccuracy: the claim is made that the C code is legal as shown. In fact, the behaviour of the code is undefined (because indeterminate values are evaluated), making the conclusions spurious. —Preceding unsigned comment added by 81.154.245.15 (talk) 15:10, 15 October 2008 (UTC)

There's an inaccuracy in this part: "long int to int causes dropping of excess higher order bits." That's only true if long int is a different size than int. In DOS environments, int is typically 16-bit and long int 32, and in some 64-bit environments int is 32 and long is 64. In those cases, the statement holds. However, in many 32-bit environments and some 64-bit environments, int is the same as long int at 32 bits or 64 bits (respectively), making that statement unreliable. Is there a better way of saying that, that we could include in the text? Renegrade (talk) 03:49, 21 October 2011 (UTC)

Merge from static_cast[edit]

Old merge proposal that hasn't been formally discussed. No opinion. Pairadox 04:33, 28 August 2007 (UTC)

Should be merged to an article on C++ casting operators (or C++ operators), if there is and should be such an article. If I find one I'll update that merge tag. — The Storm Surfer 22:58, 29 August 2007 (UTC)
static_cast was an individual article, then without discussion and reasons given was changed to redirect to this article. I reverted the static_cast article back to its content before redirection. --Abdull (talk) 21:39, 1 October 2010 (UTC)

Merge from ato*[edit]

I think that the information from the atoi and atof articles should be included. Any thoughts? --208.138.31.76 (talk) 15:38, 23 January 2008 (UTC)

I agree, IMHO we should go even further and make an article like Functions converting from ASCII in standard ANSI C library (with a better name of course) and merge atoi, atof, strtod, etc... Miko3k (talk) 00:45, 22 May 2008 (UTC)
I disagree with the inclusion because this article is theoric. But creating an article merging atoi, atof, strtod, etc... is a good idea —Preceding unsigned comment added by 82.231.158.89 (talk) 16:59, 4 June 2008 (UTC)
I disagree, atoi and other related functions belong to one particular programming language and this is a general article. 195.226.8.98 (talk) 11:43, 3 September 2008 (UTC)
I also disagree, to me, atoi and related _functions_ are not even type conversion. (Type here being the concept of type as used by compilers). They are simply utility functions that take a string as an input and return an integer (e.g. atoi). There is absolutely no relation between the input passed in and the output generated, other than we hope that they in some way refer to the same value, but that depends on how we interpret that value (what I mean is that there is some form of implicit 'format convention' necessary, as to how numbers can be represented as text. —Preceding unsigned comment added by 123.27.219.212 (talk) 12:39, 23 February 2010 (UTC)

Conversion vs Casting[edit]

In languages like Pascal (programming language) conversion and casting are distinctly different concepts. This article takes a rather C-centric view.

Conversion refers to either implicitly or explicitly changing a value from one data type to another, e.g. a 16-bit integer to a 32-bit integer. The storage requirements may change as a result of the conversion. A loss of precision or truncation may also occur.

Casting refers to explicitly changing the interpretation of the bit pattern representing a value from one type to another. For example 32 contiguous bits may be treated as an array of 32 booleans, a two character Unicode string, an unsigned 32-bit integer or an IEEE single precision floating point value. The storage requirements are never changed by a cast. Casting requires an intimate knowledge of the byte order of the system and an awareness of any alignment requirements. RegulatorRectifier (talk) 17:58, 4 December 2008 (UTC)

In ABAP, conversion and casting are also different, and have the same rules as above, with one more possibility that is the possibility to cast only a part of a value, let's say cast the 8 first bits of a 32 bits value to an ASCII character. Boundaries are always checked at runtime and an exception is triggered if they are exceeded. So casting should better have its own article (as downcasting has one, but upcasting not!) Sandrarossi (talk) 14:16, 9 August 2009 (UTC)

Visual Basic[edit]

Does anyone know if this article has to do with the properties of 'variant' types in VB and VBA? A variant variable can be any other type of variable at any point of an algorithm, but I don't have the knowledge to assert that is the same as this article. Khullah (talk) 00:07, 29 November 2011 (UTC)