I've been interviewing people for a C# developers position recently which has taken the usual "technical questions, chat, random questions, any questions for us" kind of format which I'm sure most people who've been looking for a job recently will be familiar with.
One of the technical questions we've been asking recently is "Can you describe how you would reverse a string in C#". Note, we're not asking anyone to code a full answer, just describe how they would do it.
This is one of those pretty standard interview questions, much like the FizzBuzz question, which is presented to see if candidates can demonstrate a basic understanding of a programming language and show that they can understand simple requirements. And yet, it seems to throw so many candidates!
The requirements are simple.
Take a string such as "ignoring the voices"
Reverse the characters of the string
Output the result (i.e. "seciov eht gnirongi")
As with most things there are a number of ways to achieve this goal, some more efficient than others, some more geeky than others, but still there are varied number of ways to do it, so I wanted to demonstrate a couple of methods here to show it is possible. To date I've only received a single correct answer, the other answers have been either non-existent (I don't know how) or far from the mark.
Method 1 - The agnostic approach
This method is the agnostic approach as it shows an algorithm rather than a platform specific solution. This is a good solution in an interview as it shows that you understand the problem and can devise algorithms to solve it, although it's worth saying that there may be a solution more relevant to the platform. The solution is simple, work your way in to the middle of the string (character array) from the start and end of the string, swapping the characters as you go. The important thing is to stop when you get half way through the string, otherwise you'll reverse the same characters again and arrive back at the original string. The example is presented as an extension method.
Method 2 - The C# (.NET 4) approach
The .NET framework provides a large number of methods available on all of the standard types, these can help solve this problem in a way which is specific to C# and the .NET platform. The important thing to remember is that strings are just arrays of characters, and so any methods which can be applied to arrays can be applied to strings as character arrays. More recently some methods which were only for arrays have been moved to strings as well, conveniently one of them is the Reverse method. That's not to say that you can just reverse a string directly as the Reverse method returns an IEnumerable object, but the IEnumerable object can return an array and the string constructor can take a character array to initialize a string object with, so we get the following method.
This is a vastly simpler implementation than the first, but is it any better? Well it shows an understanding of the language which is a positive, but not of algorithm implementation, so it's neither better or worse than the first method. The best answer to give would be the first answer followed by the second to show an understanding of algorithms and of the required platform.
Of course from these you can devise variations on the problem, such as reversing the words in a string whilst keeping the characters of each word in the correct direction.
Or even reversing the characters of each word, but keeping the words themselves in the correct order.
So why do some programmers struggle with these kind of questions? Is this indicative of programmers as a whole or is this just a lull? I can only guess at the reason, but non-the-less it feels concerning at the moment.
Ignoring the Voices
Random thoughts and postings about what I'm doing or working on, but trying not to post what the voices are telling me!
Tuesday, 18 December 2012
Wednesday, 24 October 2012
Playing around with Go, prime numbers and ancient Greece
I've been playing around with Google Go (golang if you want to Google it) a lot lately as I've been of sick and needed something to stop me from going nuts. It's been a while since I played with the language properly and so I started off by reading through a new book which has been written by Caleb Doxsey entitled An Introduction to Programming in Go which you can read for free on-line (or download as a PDF) or purchase from Amazon. I read it for free on-line but purchased a Kindle copy of it from Amazon afterwards as it's a really good book and really well priced.
So after going through the book I needed something to practice on, not wanting to throw myself into an active project I decided to head over to Project Euler. A great resource if you want to practice using a language without resorting to made up scenarios or over elaborate "Hello World" applications. There are a number of problems (399 at the time of writing) which are mathematical/programming based in nature. If you're not too good at maths or it's been a while since you were in full time education then you may need to Google a bit to get an idea of the problem but they're not beyond the average person.
The Problem
The one I want to look at here specifically is problem 7 which (at the time of writing) is a problem to find the 10,001st prime number. There are two obvious ways to solve this, the first being a prime number generator. This is a function which keeps on incrementing a count, checks to see if the next number is prime and if it is the number is returned from the function. The second method is to use a sieve, this takes a sequence of numbers and "removes" all of the ones which are not prime numbers, it does this by:
1. Create a sequence of numbers, marking each as a "prime candidate"
2. Starting from 2, check to see if the entry is marked as a prime candidate
a. If the entry is a prime candidate then mark each multiple in the sequence as non-prime
3. Return the collection of prime of numbers still marked as prime candidates as the final set of prime numbers
This is an over-simplified explanation of the process, for a more detailed explanation see the Wikipedia entry on the Sieve of Eratosthenes.
The issue with creating a sieve is that you must specify an upper limit, that is to say "find all prime numbers less than N". The problem however poses the question as "find the first N prime numbers". This means that in order to use a sieve we have to know roughly where the Nth prime will be, or use a high enough limit to generate enough primes to get N. Because of this it would seem that using a generator would be a better option. One thing to keep in mind is that, although there is no time limit to the problems, generally speaking if the solution takes longer than a minute then it may not be the best solution.
The Solution
Before I start
One thing I should probably mention here is that I'm only checking to see if a number is divisible by prime numbers instead of checking for all possible divisors. The theory here is Prime Factorization. So a prime number is a number which is only divisible by 1 and itself, other positive integers (other than 1 which is special) are composite numbers, meaning that they are divisible by integers other than 1 and themselves. Consider the number 20, this can be decomposed as follows:
20 / 2 = 10
10 / 2 = 5
5 / 5 = 1
So the number 20 can be represented as 2 x 2 x 5 (or 2^2 x 5).
Because numbers which are not primes must be evenly divisible by at least one prime number less than itself then this reduces the number of numbers to check for to see if a number is prime.
Solution 1
Because I wanted to play with Go I took the opportunity to create a prime number generator using goroutines (think light-weight threads). This was done by creating a number "emitter" at one end and a "listener" at another end, when a number leaves the emitter it passes through a series of checkers, these check to see if the number is evenly divisible by a given prime number. So the first checker will check to see if the number is evenly divisible by 2, if not then it is passed to the next checker which checks to see if it is evenly divisible by 3. The "listener" watches the output from the last checker, if a number appears here then it is not divisible by any of the currently known primes and so must be a prime number itself. In this event, the listener creates a new checker for the new prime number which listens to the output from the last checker, the listener then listens for output from this new checker, it also puts the new prime number into a channel and waits for it to be read by the client.
Emitter > Check For 2 > Check For 3 > Check For 5 > Listener
In implementation I thought this to be a rather elegant solution, however for production use this turns out to be quite a time consuming exercise. It allowed me however to play with channels and goroutines and so was incredibly useful. Next up I decided to implement a similar generator again, but without goroutines and channels.
Solution 2
This solution is more simple as it simply builds up a list of prime numbers and runs in a single goroutine (the main one). The theory is almost identical though; keep on checking numbers to see if they are evenly divisible by the current list of known prime numbers, if not then it is a prime number and add it to the list. The implementation this time takes a number which is the Nth prime to find, this means that the function will keep on running until it has found that many prime numbers and will return the last one found.
This was straight forward to implement and ran so much faster than the first solution (something along the lines of 38 seconds for solution 1 to 6 seconds for solution 2). But I still felt that it was too slow.
Solution 3 - The Prime Sieve
So I investigated the sieve solution. I gave a brief outline of what is required above but there are a couple of optimizations to be made. The first is that for a given sequence of numbers you only need to look for prime numbers up to the square root of the limit, numbers after this point are either multiples of the prime numbers discovered to that point, or are prime numbers themselves. Say we wanted to find all of the prime numbers up to 16 then we would limit ourselves to only looking up to 4 (the square root of 16):
The second optimization is fairly obvious from the table above, every even number with the exception of 2 is non-prime. This means that we can initially mark every even candidate as non-prime (except 2), then starting from 3 check every odd number (e.g. 3, 5, 7, 9...), this halves the number of candidates which need checking.
In order to get around the "known limit" problem I implemented the solution to sieve out all primes up to 1,000,000 (a suitably large number I thought). There are ways in which you can determine the upper limit, but the math is a bit beyond me right now, this is Prime Number Theorem, feel free to take a look. If this were implemented then we would be checking fewer potential candidates meaning less work again.
(Edit, thanks to compoasso from the comments I implemented a function to get the upper limit so that it is no longer checking from primes up to 1 million)
I didn't hold out much hope for this solution as I am sieving for primes in a large data set to find 1 specific number, so I figured I that I wasn't going to do much better than the ~6 seconds from solution 2. So the result surprised me a little. After putting together the solution and running it with the "time" command on my HP Mini 210 (Intel Atom N450, dual core 1.6Ghz) running Ubuntu Linux I got the correct result in 98 milliseconds!
So, what now?
Well, if you want to check out the full source files you can find them on GitHub along with the above snippets.
I absolutely love playing with Go, it is very much like creating C++ application but with the convenience of something like Python or Ruby. Project Euler is a great playground for experimenting with new languages as well, it also allows you to think about how to create a solution which is appropriate to the language (instead of making a generic solution work across all languages).
Now I just need to remember to keep on posting :-)
So after going through the book I needed something to practice on, not wanting to throw myself into an active project I decided to head over to Project Euler. A great resource if you want to practice using a language without resorting to made up scenarios or over elaborate "Hello World" applications. There are a number of problems (399 at the time of writing) which are mathematical/programming based in nature. If you're not too good at maths or it's been a while since you were in full time education then you may need to Google a bit to get an idea of the problem but they're not beyond the average person.
The Problem
The one I want to look at here specifically is problem 7 which (at the time of writing) is a problem to find the 10,001st prime number. There are two obvious ways to solve this, the first being a prime number generator. This is a function which keeps on incrementing a count, checks to see if the next number is prime and if it is the number is returned from the function. The second method is to use a sieve, this takes a sequence of numbers and "removes" all of the ones which are not prime numbers, it does this by:
1. Create a sequence of numbers, marking each as a "prime candidate"
2. Starting from 2, check to see if the entry is marked as a prime candidate
a. If the entry is a prime candidate then mark each multiple in the sequence as non-prime
3. Return the collection of prime of numbers still marked as prime candidates as the final set of prime numbers
This is an over-simplified explanation of the process, for a more detailed explanation see the Wikipedia entry on the Sieve of Eratosthenes.
The issue with creating a sieve is that you must specify an upper limit, that is to say "find all prime numbers less than N". The problem however poses the question as "find the first N prime numbers". This means that in order to use a sieve we have to know roughly where the Nth prime will be, or use a high enough limit to generate enough primes to get N. Because of this it would seem that using a generator would be a better option. One thing to keep in mind is that, although there is no time limit to the problems, generally speaking if the solution takes longer than a minute then it may not be the best solution.
The Solution
Before I start
One thing I should probably mention here is that I'm only checking to see if a number is divisible by prime numbers instead of checking for all possible divisors. The theory here is Prime Factorization. So a prime number is a number which is only divisible by 1 and itself, other positive integers (other than 1 which is special) are composite numbers, meaning that they are divisible by integers other than 1 and themselves. Consider the number 20, this can be decomposed as follows:
20 / 2 = 10
10 / 2 = 5
5 / 5 = 1
So the number 20 can be represented as 2 x 2 x 5 (or 2^2 x 5).
Because numbers which are not primes must be evenly divisible by at least one prime number less than itself then this reduces the number of numbers to check for to see if a number is prime.
Solution 1
Because I wanted to play with Go I took the opportunity to create a prime number generator using goroutines (think light-weight threads). This was done by creating a number "emitter" at one end and a "listener" at another end, when a number leaves the emitter it passes through a series of checkers, these check to see if the number is evenly divisible by a given prime number. So the first checker will check to see if the number is evenly divisible by 2, if not then it is passed to the next checker which checks to see if it is evenly divisible by 3. The "listener" watches the output from the last checker, if a number appears here then it is not divisible by any of the currently known primes and so must be a prime number itself. In this event, the listener creates a new checker for the new prime number which listens to the output from the last checker, the listener then listens for output from this new checker, it also puts the new prime number into a channel and waits for it to be read by the client.
Emitter > Check For 2 > Check For 3 > Check For 5 > Listener
In implementation I thought this to be a rather elegant solution, however for production use this turns out to be quite a time consuming exercise. It allowed me however to play with channels and goroutines and so was incredibly useful. Next up I decided to implement a similar generator again, but without goroutines and channels.
Solution 2
This solution is more simple as it simply builds up a list of prime numbers and runs in a single goroutine (the main one). The theory is almost identical though; keep on checking numbers to see if they are evenly divisible by the current list of known prime numbers, if not then it is a prime number and add it to the list. The implementation this time takes a number which is the Nth prime to find, this means that the function will keep on running until it has found that many prime numbers and will return the last one found.
This was straight forward to implement and ran so much faster than the first solution (something along the lines of 38 seconds for solution 1 to 6 seconds for solution 2). But I still felt that it was too slow.
Solution 3 - The Prime Sieve
So I investigated the sieve solution. I gave a brief outline of what is required above but there are a couple of optimizations to be made. The first is that for a given sequence of numbers you only need to look for prime numbers up to the square root of the limit, numbers after this point are either multiples of the prime numbers discovered to that point, or are prime numbers themselves. Say we wanted to find all of the prime numbers up to 16 then we would limit ourselves to only looking up to 4 (the square root of 16):
| 1 | N/A |
| 2 | Prime Number |
| 3 | Prime Number |
| 4 | Divisible by 2 |
| Search limit | |
| 5 | Prime Number |
| 6 | Divisible by 3 |
| 7 | Prime Number |
| 8 | Divisible by 2 |
| 9 | Divisible by 3 |
| 10 | Divisible by 2 |
| 11 | Prime Number |
| 12 | Divisible by 2 |
| 13 | Prime Number |
| 14 | Divisible by 2 |
The second optimization is fairly obvious from the table above, every even number with the exception of 2 is non-prime. This means that we can initially mark every even candidate as non-prime (except 2), then starting from 3 check every odd number (e.g. 3, 5, 7, 9...), this halves the number of candidates which need checking.
In order to get around the "known limit" problem I implemented the solution to sieve out all primes up to 1,000,000 (a suitably large number I thought). There are ways in which you can determine the upper limit, but the math is a bit beyond me right now, this is Prime Number Theorem, feel free to take a look. If this were implemented then we would be checking fewer potential candidates meaning less work again.
(Edit, thanks to compoasso from the comments I implemented a function to get the upper limit so that it is no longer checking from primes up to 1 million)
I didn't hold out much hope for this solution as I am sieving for primes in a large data set to find 1 specific number, so I figured I that I wasn't going to do much better than the ~6 seconds from solution 2. So the result surprised me a little. After putting together the solution and running it with the "time" command on my HP Mini 210 (Intel Atom N450, dual core 1.6Ghz) running Ubuntu Linux I got the correct result in 98 milliseconds!
So, what now?
Well, if you want to check out the full source files you can find them on GitHub along with the above snippets.
I absolutely love playing with Go, it is very much like creating C++ application but with the convenience of something like Python or Ruby. Project Euler is a great playground for experimenting with new languages as well, it also allows you to think about how to create a solution which is appropriate to the language (instead of making a generic solution work across all languages).
Now I just need to remember to keep on posting :-)
Labels:
development,
go,
golang,
learning,
maths
Location:
Ilkeston
Tuesday, 18 September 2012
News of my demise has been greatly exagerated
I am still here, honest!
I can't believe it's been almost a year since my last post, things have been manic around here over the last year. I started with the best of intentions after my daughter was born, but with 2 children and a new position at work consuming most of my time, it's left me little time to blog and learn new things.
I am still intending on continuing the C++11 series; it's not so new any more but features are still being added to compilers and people are still finding it so I think it's worth going on with. I'm also considering running a few posts on Google Go which I've been playing with for a while but I want to start doing more with it.
Now I just need to stay focused and get on with it :-)
I can't believe it's been almost a year since my last post, things have been manic around here over the last year. I started with the best of intentions after my daughter was born, but with 2 children and a new position at work consuming most of my time, it's left me little time to blog and learn new things.
I am still intending on continuing the C++11 series; it's not so new any more but features are still being added to compilers and people are still finding it so I think it's worth going on with. I'm also considering running a few posts on Google Go which I've been playing with for a while but I want to start doing more with it.
Now I just need to stay focused and get on with it :-)
Friday, 16 December 2011
C++11: Lambda Expressions
Posts in this series
Getting started with C++11
C++11: Initializer lists and range-for statements
So what is a lambda expression?
A lambda expression is way in which to write a function in-line in your code, the typical use case is where you call a function which expects a pointer to another function in order to tailor it to your own needs. For example, if you had a list of integers (4, 1, 6, 2, 13) and you wanted them sorting, you would typically call a sort method, passing it your list of integers. Now that sort method may accept a pointer to another function in which you can specify how your list is to be sorted, typically this means that you would have one function defining how to sort in an ascending manner, and another defining a descending manner. Lets start with an example as to how you would currently do this.
Full example code
So now, if we wanted to sort this in a descending manner then we would need to write a new method to tell the sort algorithm how to sort the values and pass this to the sort method.
This is a really simple function so why do we have to write a whole method for it? Well using lambda expressions we no longer have to, with the above being written as follows instead.
Full example code|
So what did we do here? Well lets have a look at the lambda expression.
The opening brackets "[]" is a capture list, more on this later. Next we define the expressions parameter list "(int x, int y)" just as we would if we were defining a normal method.
The next part is the return type "-> bool", this is an optional part of the expression and we could have easily left it out as the compiler can easily determine from the expression body that the return type is a bool; if the return type is not specified and the expression body does not return any value then a return type of void is deduced. It is useful, however, to specify a return type if you want to explicitly instruct the compiler what the type being returned should be.
Finally there is the expression body which is every between the "{}" braces.
Capture lists
Sometimes when we use lambda expressions we may want to use or modify values from the surrounding code. Normally we would just pass these in using a parameter, but with lambda expressions we have to provide a parameter list which the receiving method is expecting, in the case of the sort algorithm method, it is expecting an expression which takes two integers and returns a bool.
To access these surrounding values we can use capture lists. You've already seen a simple use of a capture list in the previous example where we wrote "[]", this tells the compiler that we are not capturing any values for use in the lambda expression. In this next example we are going to capture an integer variable called "stepCount" which will be incremented each time our lambda expression is used by the sort algorithm, this will tell us how many times the expression was used to completely sort our list.
Full example code
The capture list this time is written as "[&]", this instructs the compiler to capture any local variables used in the lambda expression and pass-by-reference. This allows us to have the sort method update a local variable in our calling code. Another option for the capture list is "[=]" which tells the compiler to pass-by-value. If we were to use this in our code however we would get a compiler error as any values passed by value are read-only.
There are other options available for capture lists, these are as follows:
One thing to be careful of here however is that if you return a lambda expression from a method (we'll see how in a second) and you are using a local variable in that method and capturing by reference then you are going to run into problems as the moment you return the expression the local variable you captured as gone out of scope. Other than that hopefully you can see just how useful these are by now.
Accepting lambda expressions in my own code
One of the great new features in C++11 is the std::function type (and std::bind which I'll cover in a later post) which is a great way for us to start passing around lambda expressions as parameters or return types; in fact it allows us to use lambda expressions and functions. The structure of the type is std::function<return_type (parameter list)>, so if we wanted to write a method that accepted a lambda expression we could write the following.
The "f" parameter is a function which takes a single double parameter and which returns a double value, this is then used in the method body as part of the accumulation process. The method can then be used as follows.
Full example code
Here we're calling the "Sum" method twice, the first time with a lambda expression which simply returns the value passed into it so that we sum all of the values. The second call passes a reference to the "Complex" method, which may not be that complex but illustrates the point about being able to pass standard methods as well as lambda expressions.
Lambda expressions provide an easy and convenient method of providing short functions to other other functions which require thema. Even if you're not sure if you want to use lambda expressions, making sure that your methods use the std::function type means that you can carry on writing helper functions if you want to but that you or others have the option of using lambda expressions if they want to.
For the next post I should be looking at smart pointers, these give us the benefits of pointers in C++ but also provide better memory management, which can only be a good thing
References
CProgramming.com - Lambda Expressions in C++ - the definitive guide
Bjarne Stroustrup - C++11 FAQ
All code provided in this article is provided under a BSD license. If you spot an error then please do let me know so that we can make this better for anyone else reading it.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Getting started with C++11
C++11: Initializer lists and range-for statements
So what is a lambda expression?
A lambda expression is way in which to write a function in-line in your code, the typical use case is where you call a function which expects a pointer to another function in order to tailor it to your own needs. For example, if you had a list of integers (4, 1, 6, 2, 13) and you wanted them sorting, you would typically call a sort method, passing it your list of integers. Now that sort method may accept a pointer to another function in which you can specify how your list is to be sorted, typically this means that you would have one function defining how to sort in an ascending manner, and another defining a descending manner. Lets start with an example as to how you would currently do this.
- bool SortAscending(const int x, const int y)
- {
- return x < y;
- }
- ...
- vector<int> myList = { 4, 1, 6, 2, 13 };
- sort(myList.begin(), myList.end(), SortAscending); // 1, 2, 4, 6, 13
So now, if we wanted to sort this in a descending manner then we would need to write a new method to tell the sort algorithm how to sort the values and pass this to the sort method.
This is a really simple function so why do we have to write a whole method for it? Well using lambda expressions we no longer have to, with the above being written as follows instead.
- vector<int> myList = { 4, 1, 6, 2, 13 };
- sort(myList.begin(), myList.end(), [](int x, int y) -> bool { return x < y; }); // 1, 2, 4, 6, 13
So what did we do here? Well lets have a look at the lambda expression.
- [](int x, int y) -> bool { return x < y; }
The next part is the return type "-> bool", this is an optional part of the expression and we could have easily left it out as the compiler can easily determine from the expression body that the return type is a bool; if the return type is not specified and the expression body does not return any value then a return type of void is deduced. It is useful, however, to specify a return type if you want to explicitly instruct the compiler what the type being returned should be.
Finally there is the expression body which is every between the "{}" braces.
Capture lists
Sometimes when we use lambda expressions we may want to use or modify values from the surrounding code. Normally we would just pass these in using a parameter, but with lambda expressions we have to provide a parameter list which the receiving method is expecting, in the case of the sort algorithm method, it is expecting an expression which takes two integers and returns a bool.
To access these surrounding values we can use capture lists. You've already seen a simple use of a capture list in the previous example where we wrote "[]", this tells the compiler that we are not capturing any values for use in the lambda expression. In this next example we are going to capture an integer variable called "stepCount" which will be incremented each time our lambda expression is used by the sort algorithm, this will tell us how many times the expression was used to completely sort our list.
- int stepCount = 0;
- sort(myList.begin(), myList.end(), [&](int x, int y) -> bool { ++stepCount; return x < y; }); // stepCount is 9
The capture list this time is written as "[&]", this instructs the compiler to capture any local variables used in the lambda expression and pass-by-reference. This allows us to have the sort method update a local variable in our calling code. Another option for the capture list is "[=]" which tells the compiler to pass-by-value. If we were to use this in our code however we would get a compiler error as any values passed by value are read-only.
There are other options available for capture lists, these are as follows:
| [] | Capture nothing |
| [&] | Capture variables by reference |
| [=] | Capture variables by value (make a copy) |
| [=,&foo] | Capture foo by reference, all other variable by value |
| [foo] | Only capture foo and do so by value |
| [this] | Capture the this pointer of the enclosing class |
One thing to be careful of here however is that if you return a lambda expression from a method (we'll see how in a second) and you are using a local variable in that method and capturing by reference then you are going to run into problems as the moment you return the expression the local variable you captured as gone out of scope. Other than that hopefully you can see just how useful these are by now.
Accepting lambda expressions in my own code
One of the great new features in C++11 is the std::function type (and std::bind which I'll cover in a later post) which is a great way for us to start passing around lambda expressions as parameters or return types; in fact it allows us to use lambda expressions and functions. The structure of the type is std::function<return_type (parameter list)>, so if we wanted to write a method that accepted a lambda expression we could write the following.
- double Sum(const vector<double>& values, function<double (double x)> f)
- {
- double result = 0.0;
- for (auto d : values)
- {
- result += f(d);
- }
- return result;
- }
- double Complex(double x)
- {
- double result = sin(x * 3.14159265);
- result -= floor(result);
- return result;
- }
- int main(int argc, char** argv)
- {
- vector
myValues = { 1.3, 2.1, 7.4, 9.6 }; - double result1 = Sum(myValues, [](double x) { return x; }); // 20.4
- double result2 = Sum(myValues, Complex); // 0.597887
- }
Here we're calling the "Sum" method twice, the first time with a lambda expression which simply returns the value passed into it so that we sum all of the values. The second call passes a reference to the "Complex" method, which may not be that complex but illustrates the point about being able to pass standard methods as well as lambda expressions.
Lambda expressions provide an easy and convenient method of providing short functions to other other functions which require thema. Even if you're not sure if you want to use lambda expressions, making sure that your methods use the std::function type means that you can carry on writing helper functions if you want to but that you or others have the option of using lambda expressions if they want to.
For the next post I should be looking at smart pointers, these give us the benefits of pointers in C++ but also provide better memory management, which can only be a good thing
References
CProgramming.com - Lambda Expressions in C++ - the definitive guide
Bjarne Stroustrup - C++11 FAQ
All code provided in this article is provided under a BSD license. If you spot an error then please do let me know so that we can make this better for anyone else reading it.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Sunday, 4 December 2011
A bit quiet for a couple of weeks
So I thought I'd best mention that I'm likely to be quiet for a couple of weeks as my little girl has finally decided to make an appearance into the world, she was born on the 26th November 2011 weighing 2209g (about 5lbs). We named her Elora Christine, both she and my wife are doing well :)
| Baby Elora |
Monday, 21 November 2011
The var keyword, or what I meant to say
Whilst I'm waiting for something to compile (and for baby number 2 to turn up) I thought I'd post about my thoughts on the "var" keyword in C#.
In previous posts you might have seen that I was somewhat enthusiastic about the "auto" keyword in C++, so it might be natural to assume that I'd feel the same about the "var" keyword in C#. This is rather unfortunately not the case, allow me to expand a little as to why my feelings about the same functionality in two different languages are not strictly exactly the same.
I'll do it tomorrow, honest!
I'm sort of afraid a little that I'm going to start upsetting people here, so I shall start by saying this. I am generalizing here and not stereotyping, not everyone is the same and you may indeed be an exception to the rule, but this is generally what I find to be true.
C++ programmers tend to be less lazy than their C# counterparts. What do I mean by this? Well, normally when I'm looking at code written by a C++ programmer (in any language) it tends to be easier to read and maintain. It's because C++ can be painful enough without having to add extra complexity or obfuscation. Code written by C# programmers tends to be a little lazier, things need tidying up here, stuff is left lying around over there and it generally has that "I'll do it tomorrow" kind of feel to it.
Now don't get me wrong, there is a lot of very nicely written C# code out there, but I tend to find that the people who have written it come from a C/C++ background or have a lot of experience with those or similar languages.
So why should this matter? Well, when I think of C++ programmers using the "auto" keyword I tend to think of code coming out looking like this:
Which is easy to follow, I know when I look in the "SomeOtherFunction" code that I just need to find the "MyFunction" method to see what the type will be (or use the functionality of the IDE), and importantly I know what the code is trying to do without looking this information up. When I think of C# developers using the "var" keyword then I tend to think of code coming out looking like this (and I have seen this):
Which, okay, is readable and I can make out what is happening but I no longer have clue about the intent of the code; is "a" meant to be a short, an int or a long, maybe it should have been a double? We could have put some modifiers in there, but that's still not as easy to read. I just know that if a C++ programmer had written it that we'd have some types in there and the intent would become obvious. And this isn't just me worrying about something that probably wont happen, I've seen numerous people write code in this way.
What I meant was...
The thing is that the intent of the code is about as important as the code itself. If I say that a variable is a 64bit integer then it means that I'm expecting some pretty big values in there, similarly if I proclaimed it to be a 16bit integer then I'm expecting very small values. This kind of information can be invaluable to a maintainer, who might not be some unknown person looking at the code 5 years after you've written it, it might be you after you've spent 2 weeks on a different project and can't quite remember why you wrote something a specific way.
So is "var" a good thing? Well I would say it is, but like most things it should be used responsibly and never at the cost of losing the intent of the what you are trying to write. If you're not sure about it, then talk to someone about it, or write the code the way you want and give it to someone who hasn't seen it and ask them if they know what it's trying to do. If they pull a face then change it, if they know what the intent of the code is without asking too many (what you would consider) obvious questions then it's good to go.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
In previous posts you might have seen that I was somewhat enthusiastic about the "auto" keyword in C++, so it might be natural to assume that I'd feel the same about the "var" keyword in C#. This is rather unfortunately not the case, allow me to expand a little as to why my feelings about the same functionality in two different languages are not strictly exactly the same.
I'll do it tomorrow, honest!
I'm sort of afraid a little that I'm going to start upsetting people here, so I shall start by saying this. I am generalizing here and not stereotyping, not everyone is the same and you may indeed be an exception to the rule, but this is generally what I find to be true.
C++ programmers tend to be less lazy than their C# counterparts. What do I mean by this? Well, normally when I'm looking at code written by a C++ programmer (in any language) it tends to be easier to read and maintain. It's because C++ can be painful enough without having to add extra complexity or obfuscation. Code written by C# programmers tends to be a little lazier, things need tidying up here, stuff is left lying around over there and it generally has that "I'll do it tomorrow" kind of feel to it.
Now don't get me wrong, there is a lot of very nicely written C# code out there, but I tend to find that the people who have written it come from a C/C++ background or have a lot of experience with those or similar languages.
So why should this matter? Well, when I think of C++ programmers using the "auto" keyword I tend to think of code coming out looking like this:
- map<int, vector<string>> MyFunction() { ... }
- void SomeOtherFunction()
- {
- auto result = MyFunction();
- }
Which is easy to follow, I know when I look in the "SomeOtherFunction" code that I just need to find the "MyFunction" method to see what the type will be (or use the functionality of the IDE), and importantly I know what the code is trying to do without looking this information up. When I think of C# developers using the "var" keyword then I tend to think of code coming out looking like this (and I have seen this):
- void MyFunction()
- {
- var a = 1;
- var b = 2;
- var c = "Something";
- ...
- var x = a + b;
- }
Which, okay, is readable and I can make out what is happening but I no longer have clue about the intent of the code; is "a" meant to be a short, an int or a long, maybe it should have been a double? We could have put some modifiers in there, but that's still not as easy to read. I just know that if a C++ programmer had written it that we'd have some types in there and the intent would become obvious. And this isn't just me worrying about something that probably wont happen, I've seen numerous people write code in this way.
What I meant was...
The thing is that the intent of the code is about as important as the code itself. If I say that a variable is a 64bit integer then it means that I'm expecting some pretty big values in there, similarly if I proclaimed it to be a 16bit integer then I'm expecting very small values. This kind of information can be invaluable to a maintainer, who might not be some unknown person looking at the code 5 years after you've written it, it might be you after you've spent 2 weeks on a different project and can't quite remember why you wrote something a specific way.
So is "var" a good thing? Well I would say it is, but like most things it should be used responsibly and never at the cost of losing the intent of the what you are trying to write. If you're not sure about it, then talk to someone about it, or write the code the way you want and give it to someone who hasn't seen it and ask them if they know what it's trying to do. If they pull a face then change it, if they know what the intent of the code is without asking too many (what you would consider) obvious questions then it's good to go.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Monday, 14 November 2011
Living in a "dynamic" C# world
Taking a brief break from the C++11 posts (I'm working on the next one, I promise), I thought I'd quickly cover a small problem I came up against in C# and how something I'd previously dismissed really helped me out. If you want to try out any of the code below I'd strongly recommend looking at LinqPad which is a great tool for trying out sample code, expressions and for querying your databases using Linq.
I can't remember the number of times I've looked at the new "dynamic" keyword and thought of it as ugly, and I will admit that maybe I've not been it's greatest advocate. Recently however I went on a training course during which we spent some time calling IronPython scripts from C#, so I could see a use for dynamic, but not so much outside of this use-case.
Today however I encountered a problem and the dynamic keyword came to my rescue. The problem was this; I'm loading in data from an XML document (and no, XML is not my problem), this document has a number of sections which identify how to check something from another document, so it might have an entry which says "You're expecting a value in a field called 'x' of type 'y' and I want to check it like this...". So as an example, say I'm picking up a value which is a double precision value, and I want to check it against another value of the same type but using a tolerance. So if 's' is my source value, 'x' is my expected value and 't' is my delta then I would want to check it using the following:
Great, but here's the problem, when I'm writing the code the function first needs to check the type and convert it from a string value to the correct type, which I only know about because the type is held in another variable. Again, not too tricky as I can just write the following (where "type" is a Type variable holding the type I need to use):
The compiler has no problem with this and lets me carry on my merry way, but when I add the following line the compiler starts to shout and tells me I'm an idiot for even attempting to apply an operand of "-" to a type of "object" and "object"!
The thing is, I know that my converted values are doubles but I need to tell the compiler that I know what I'm doing here and it can compile this. Well this is where "dynamic" comes to save the day, it allows me to bypass compile-time type checking and instead have this checked at run-time. So changing the code to the following:
I get the expected result of "True" when I run the code.
I know there are probably other ways of doing this, and the example code I've presented doesn't exactly portray the complexity I was attempting to deal with, but I do think it's quite a nice little solution. Hopefully after reading this you might also re-consider looking at the "dynamic" keyword, you never know when you might have a genuine use for it.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
I can't remember the number of times I've looked at the new "dynamic" keyword and thought of it as ugly, and I will admit that maybe I've not been it's greatest advocate. Recently however I went on a training course during which we spent some time calling IronPython scripts from C#, so I could see a use for dynamic, but not so much outside of this use-case.
Today however I encountered a problem and the dynamic keyword came to my rescue. The problem was this; I'm loading in data from an XML document (and no, XML is not my problem), this document has a number of sections which identify how to check something from another document, so it might have an entry which says "You're expecting a value in a field called 'x' of type 'y' and I want to check it like this...". So as an example, say I'm picking up a value which is a double precision value, and I want to check it against another value of the same type but using a tolerance. So if 's' is my source value, 'x' is my expected value and 't' is my delta then I would want to check it using the following:
// |s - x| < t var s = 1.0005; var x = 1.0004; var t = 1.0001; return Math.Abs(s - x) < t;
Great, but here's the problem, when I'm writing the code the function first needs to check the type and convert it from a string value to the correct type, which I only know about because the type is held in another variable. Again, not too tricky as I can just write the following (where "type" is a Type variable holding the type I need to use):
var convertedValue = Convert.ChangeType(s, type);
The compiler has no problem with this and lets me carry on my merry way, but when I add the following line the compiler starts to shout and tells me I'm an idiot for even attempting to apply an operand of "-" to a type of "object" and "object"!
var sourceValue = "1.0005"; var expectedValue = "1.0004"; var tolerance = 1.0001; var type = typeof(double); var convertedSource = Convert.ChangeType(sourceValue, type); var convertedExpected = Convert.ChangeType(expectedValue, type); var result = Math.Abs(convertedSource - convertedExpected) < tolerance; Console.WriteLine(result);
The thing is, I know that my converted values are doubles but I need to tell the compiler that I know what I'm doing here and it can compile this. Well this is where "dynamic" comes to save the day, it allows me to bypass compile-time type checking and instead have this checked at run-time. So changing the code to the following:
var sourceValue = "1.0005"; var expectedValue = "1.0004"; var tolerance = 1.0001; var type = typeof(double); dynamic convertedSource = Convert.ChangeType(sourceValue, type); dynamic convertedExpected = Convert.ChangeType(expectedValue, type); var result = Math.Abs(convertedSource - convertedExpected) < tolerance; Console.WriteLine(result);
I get the expected result of "True" when I run the code.
I know there are probably other ways of doing this, and the example code I've presented doesn't exactly portray the complexity I was attempting to deal with, but I do think it's quite a nice little solution. Hopefully after reading this you might also re-consider looking at the "dynamic" keyword, you never know when you might have a genuine use for it.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Subscribe to:
Posts (Atom)