Gotchas: Difference between revisions
m
→{{header|Wren}}: Changed to Wren S/H
Puppydrum64 (talk | contribs) |
m (→{{header|Wren}}: Changed to Wren S/H) |
||
(10 intermediate revisions by 6 users not shown) | |||
Line 1:
{{
;Definition
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 656 ⟶ 754:
I've tried to construct an example below which illustrates these pitfalls.
<syntaxhighlight lang="
construct new(width, height) {
// Create two fields.
|