Gotchas: Difference between revisions
m
→{{header|Wren}}: Changed to Wren S/H
Puppydrum64 (talk | contribs) |
m (→{{header|Wren}}: Changed to Wren S/H) |
||
| (12 intermediate revisions by 6 users not shown) | |||
Line 1:
{{
;Definition
Line 45:
SBC #4 ;eight minus four</syntaxhighlight>
===Adding/Subtracting With Carry===
The 6502 (and even its revisions) have ''no way to add or subtract without involving the carry flag.'' The "carry" is essentially the same as "carrying the one" that we all learned in elementary school arithmetic. <code>ADC</code> adds an extra 1 if the carry flag was set when the <code>ADC</code> was executed. <code>SBC</code> subtracts an extra 1 if the carry was ''clear'' when the <code>SBC</code> was executed (as stated before, on most other CPUs the equivalent of <code>SBC</code> behaves the opposite to the 6502).
Line 189:
Put another way, <code>sizeof</code> is just a <code>#define</code> that doesn't pollute your namespace:
<syntaxhighlight lang="C">int foo()
{
#define size_of_bar 20 //the sizeof operator is the same as doing this essentially.
char bar[size_of_bar];
return size_of_bar;
}</syntaxhighlight>
As a result of this subtle nuance, many new C programmers will write the code below thinking that it will return a value corresponding to the number of elements the array was originally declared with.
<syntaxhighlight lang="C">int gotcha(char bar[])
{
Line 194 ⟶ 204:
}</syntaxhighlight>
<syntaxhighlight lang="C">myArray[40];
int x = gotcha(myArray);</syntaxhighlight>
Line 217 ⟶ 227:
===printf()===
The first function every C programmer learns (besides <code>main</code>), <code>printf</code> can be exploited in a similar fashion as <code>gets()</code>, but only if the programmer is irresponsible. <code>printf</code> can theoretically take any number of arguments; however there is no CPU that can actually support variadic functions in hardware (in the sense that the CPU knows how many arguments are passed into it without cheating,
The
<syntaxhighlight lang="C">int main()
Line 228 ⟶ 238:
printf("%d %d %d %x %x",x,y,z); //on an Intel cpu the first %x reveals %%ebp and the second reveals the return address.)
}</syntaxhighlight>
=={{Header|Insitux}}==
A common "gotcha" in Insitux concerns one of its greatest strengths: ''any'' built-in operations under-loaded by exactly one parameter become closures. Under-loading by accidental omission is a common mistake, sometimes purely typological. Below is an example of accidental under-loading due to misuse of <code>max</code>.
<syntaxhighlight lang="insitux">
(let numbers [1 2 3 4]
maximum (max numbers)) ;should be (... max numbers)
(+ maximum 5)
</syntaxhighlight>
{{out}}
<pre>
3:2 (+ maximum 5)
Type Error: fast+ takes numeric arguments only, not closure.
In entry.ix
</pre>
This leads onto another "gotcha": Insitux substitutes any obvious instances of arithmetic operations used with two parameters with a faster alternative which, internally, does not need to iterate over ''N'' parameters. The reason this is a gotcha is two-fold: it can be a bit confusing to see e.g. <code>fast+</code> when you used <code>+</code>, and it complicates [https://www.rosettacode.org/wiki/Test_a_function#Insitux mocking] arithmetic operations.
<syntaxhighlight lang="insitux">
(mock + (fn a b ((unmocked +) a b 1)))
(+ 2 3)
</syntaxhighlight>
{{out}}
<pre>
5
</pre>
The example above "should" have returned <code>6</code>, but to achieve this we would need to mock <code>fast+</code> instead.
=={{header|J}}==
Line 259 ⟶ 302:
5 7 9</syntaxhighlight>
Here, we are adding
J also has gotchas with its token formation and syntax rules.
Line 316 ⟶ 359:
2*3+1 NB. processed right-to-left
8</syntaxhighlight>
Finally, J is very expressive (in the formal sense), which has the effect that many
meaningless sentences are legal, so you do get less immediate feedback on your
mistakes.
=={{header|Java}}==
<syntaxhighlight lang="java">
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
public final class Gotchas {
public static void main(String[] aArgs) {
// Gotcha 1: An integer argument to a Collection, such as a List, sets the capacity of the Collection,
// but does not fill the Collection with elements.
List<Integer> numbers = new ArrayList<Integer>(100);
// The above list has the capacity to hold 100 elements, but is currently empty.
// Setting the element with index 3 to a value of 42 will create a runtime exception,
// because the list has length 0, and this element does not yet exist.
numbers.set(3, 42);
// The gotcha is only revealed when a runtime exception is thrown.
System.out.println(numbers);
// java.lang.IndexOutOfBoundsException: Index 3 out of bounds for length 0
// Gotcha 2: Copying a Collection in a simple manner works,
// but means that changes to the original Collection are reflected in the copy,
// which is not normally the desired outcome.
Set<String> letters = new HashSet<String>();
letters.add("a"); letters.add("b"); letters.add("c");
// Create a copy of the set.
Set<String> copy = letters;
// The two sets are identical.
System.out.println(letters + " :: " + copy);
// Add an element to the set 'letters'.
letters.add("d");
// The same letter has been added to the set 'copy'.
// Both sets now contain the same 4 letters.
System.out.println(letters + " :: " + copy);
// In a program this can cause mysterious results which can be difficult to debug.
// The correct way to copy a Collection is to use a copy constructor as shown below.
Set<String> correctCopy = new HashSet<String>(letters);
letters.add("e");
// The set 'correctCopy' only contains its original 4 letters.
System.out.println(letters + " :: " + correctCopy);
}
}
</syntaxhighlight>
=={{header|jq}}==
Line 326 ⟶ 424:
One way to avoid falling into the trap in the first place is to spend some time understanding how the invocation `f(1,2)` might NOT be equivalent to `f(1),f(2)`. (Hint: `def(s): reduce s as $x (0; .+1);`)
=={{header|Javascript}}==
===Equality Comparisons===
The normal equality operator (<code>==</code>) is very infamous for its strange results when comparing two variables of different types. Javascript has a complicated set of type coercion rules, which was intended to simplify comparisons between integers and floating point, integers and their string representations (e.g. 2 == '2'), etc. However, this is often frustrating for the programmer when they want to know if two variables are equal and also have the same data type. The strict equality (<code>===</code>) operator will always return false if the variables are of two different types. Many new programmers are taught to always use <code>===</code> to avoid subtle bugs in their programs.
=={{header|Julia}}==
Line 652 ⟶ 754:
I've tried to construct an example below which illustrates these pitfalls.
<syntaxhighlight lang="
construct new(width, height) {
// Create two fields.
| |||