syntactic-sugar

I was reading the C++0x faq and came across the section detailing initializer lists. The examples were mostly variations of: vector<int> vi = { 1, 2, 3 }; vector<int> vj({1, 2, 3}); // etc. However, also listed was the form: vector<int> vk{2}; This form appears elsewhere in the faq, and I am curious as to whether it is semantically different from the initial two forms, or just syntactic sugar for vk({x, y, z}) . One is uniform initialization , and the other is initializer lists . They are two different things, although as you can see, they can produce similar syntax. vector<int> vk{2}; is a

Is there a difference in the order of v1 and v2 in a BETWEEN query on SQL Server? SELECT * FROM table WHERE col BETWEEN v1 AND v2 currently I don’t get any results if v1 is bigger than v2. Is this only syntactic sugar for col >= v1 AND col <= v2 or does it really take all values between the two? on my current observations I guess it’s the first case. Tom Ritter SQL Server 2008: select 1 where 5 between 1 and 7 1 result select 1 where 5 between 7 and 1 0 results Based on these results, and the Postgre Docs I would hypothesize that the ANSI Standard is as follows (although I can't find that doc)

Note: I've seen this question asked sometimes before ( a , b , c ), but neither of these was in C#, nor helpful. Assume I'm using the ? : ternary operator like this (to do nothing when false is the case): r==5? r=0 : <nothing> ; I'm getting an error. Putting something there will obviously solve the problem. How can I still keep the other side empty without making some random empty function? You can't. The whole point of the conditional ?: operator is that it evaluates an expression . You can't even just use: Foo() ? Bar() : Baz(); ... because that isn't a statement. You have to do something

I was looking into efficient ways to read files in Perl and came across this very interesting one liner: my $text = do { local (@ARGV, $/) = $file; <> }; My question is: How exactly does this work? Normally when slurping a file you set $/ = undef , but I don't see how this does that. This little piece of code is proving to be very difficult to wrap my head around. What would be a simplified breakdown and explanation for this? Now that I know how it works, lets get real fancy! Not that this code has any real use; it's just fun to figure out and cool to look at. Here is a one-liner to slurp

Let's take a look at the following code: int arr[n]; // s.t. i<n arr[i] = 12; // s.t. i<n *(arr + i) = 12; Is arr[i] is a syntatic sugar for *(arr+ i) ? user2736738 Yes you can say that- array subscript access is identical to pointer access with * dereference. From 6.5.2.1p2 C11 standard N1570 A postfix expression followed by an expression in square brackets [] is a subscripted designation of an element of an array object. The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))) . Because of the conversion rules that apply to the binary + operator, if E1 is an

I was messing around with a small custom data object that needs to be hashable, comparable, and fast, when I ran into an odd-looking set of timing results. Some of the comparisons (and the hashing method) for this object simply delegate to an attribute, so I was using something like: def __hash__(self): return self.foo.__hash__() However upon testing, I discovered that hash(self.foo) is noticeably faster. Curious, I tested __eq__ , __ne__ , and the other magic comparisons, only to discover that all of them ran faster if I used the sugary forms ( == , != , < , etc.). Why is this? I assumed the

Haskell's record syntax is considered by many to be a wart on an otherwise elegant language, on account of its ugly syntax and namespace pollution. On the other hand it's often more useful than the position based alternative. Instead of a declaration like this: data Foo = Foo { fooID :: Int, fooName :: String } deriving (Show) It seems to me that something along these lines would be more attractive: data Foo = Foo id :: Int name :: String deriving (Show) I'm sure there must be a good reason I'm missing, but why was the C-like record syntax adopted over a cleaner layout-based approach? Secondly