Tag Archives: F#

Benefits of functional programming

A couple of linked articles with a strong story on the benefits of choosing F# over C# for reducing the bug count and reducing the size of the codebase.

Simon Tyler Cousins compares two similar projects with F# clearly superior to C# in every category for those projects.

Don Syme opines that a key benefit of F# is that nulls are all but eliminated in the code and references the manifesto for Not Only O-O:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Functions and Types over classes
Purity over mutability
Composition over inheritance
Higher-order functions over method dispatch
Options over nulls

That is, while there is value in the items on the right (except for nulls), we value the items on the left more.

Leave a comment

Filed under Programming

Equality and Comparisons in F#

This blog post from Don Syme is really useful when considering options for customising equality and comparisons in F#. Having said that, with F# 2.0, it looks like you don’t need to put attributes on your type, it’s enough to follow Don’s overrides of GetHashCode, Equals and CompareTo.

Leave a comment

Filed under Programming

Bjarne Stroustrup’s Tour of C++

I’m reading through Bjarne Stroustrup’s Tour of C++, which Addison-Wesley have graciously allowed him to post ahead of its inclusion in the fourth edition of The C++ Programming Language.

stroustrup

It starts with The Basics. It was refreshing to see new features of C++11 introduced alongside the most rudimentary aspects of the language – rather than being viewed as a whole new language that teams might choose to adopt/ignore. I’m sure if you start learning C++ today, features such as enum class, auto, constexpr will seem natural, begging the question “What did you do without them?”.

I thought this code snippet was especially cute:

for (auto x : {10,21,32,43,54,65})
    std::cout << x << '\n';

I’m used to writing code in F# like this,

[| 10; 21; 32; 43; 54; 65 |] 
  |> Array.iter (fun i -> printf "%d\n" i)

but it’s great to see such concise code in C++ at well.

The second part concerns abstractions. This includes summaries of copy and move semantics. This note on move semantics is helpful because many explanations focus on how to move data into a new instance of a class rather than the state in which to leave the old object:

After a move, an object should be in a state that allows a destructor to be run. Typi- cally, we should also allow assignment to a moved-from object

Preventing copy and move:

Using the default copy or move for a class in a hierarchy is typically a disaster: Given only a pointer to a base, we simply don’t know what members the derived class has (§3.3.3), so we can’t know how to copy them. So, the best thing to do is usually to delete the default copy and move operations; that is, to eliminate to default definitions of those two operations

where C++11 provides the delete annotation to tell the compiler not to write a default copy/move operation, but you could follow today’s practice and declare it private and omit the implementation until your compiler catches up.

If you need to copy an object in a class hierarchy, write some kind of clone function. [Note that] a move operation is not implicitly generated for a class where the user has explicitly declared a destructor. Furthermore, the generation of copy operations are deprecated in this case. This can be a good reason to explicitly define a destructor even where the compiler would have implicitly provided one.

There are also useful examples of where to use type aliasing, for example this one that uses the assumption that STL containers provide a value_type alias (or typedef):

template<typename C>
using Element_type = typename C::value_type; 

template<typename Container> void algo(Container& c)
{
  Vector<Element_type<Container>> vec;
  // ... 
}

You can also use aliasing to define new templates by binding arguments on existing templates:

template<typename Value>
using String_map = Map<string,Value>;

String_map<int>m; //alias for Map<string,int>

Part three is about algorithms and containers.

The example for how to write operator>>(), read from, is particularly verbose – I’m sure it would have been better to show a regex solution alongside. Worth a look anyway for this mechanism for indicating a streaming failure (typically I would throw an exception):

is.setf(ios_base::failbit);

Similarly, I hadn’t realised before that range-checked random access to a std::vector was possible via the at(size_t i) method:

T& operator[](int i) { return vector::at(i); } // range-checked

The final part is about concurrency and utilities.

One of the main utilities now available in C++11 is std::shared_ptr (which was sorely lacking from the previous standard).  However, Stroustrup hints that in many cases it’s sufficient to create an object on the stack with a local variable:

Unfortunately, overuse of new (and of pointers and references) seems to be an increasing problem.

When you do need to manage heap objects, std::unique_ptr is very lightweight with no space or time overhead compared to a built-in pointer.  You can pass or return unique_ptr’s in or out of functions, because the implementation uses move semantics (whereas std::shared_ptr is copied).

One concurrency topic that always causes problems is how to define a convention between locks so that deadlock cannot occur due to acquiring the locks in the wrong order.  There’s a neat example of how to avoid that:

// Initialise lock guards with their mutexes, but don't lock yet
std::lock_guard<std::mutex> lock1(mutex1, defer_lock);
std::lock_guard<std::mutex> lock2(mutex2, defer_lock);
std::lock_guard<std::mutex> lock3(mutex3, defer_lock);
// other preparation
std::lock( lock1, lock2, lock3 );
// Implicitly release all mutexes when locks go out of scope.

Stroustrup also introduces the concepts of futures and promises:

The important point about future and promise is that they enable a transfer of a value between two tasks without explicit use of a lock; “the system” implements the transfer efficiently.

The absence of locks is key and is also mentioned when introducing std::packaged_task and std::async.  This section might be better written in reverse, with the simpler async concept introduced first and locks/mutexes in context as the advanced technique.

Under <utilities>, a boon is likely to be std::tuple, a heterogenous sequence of elements (I’ve added the use of std::tie to show how to unpack the values):

auto myTuple = std::make_tuple(std::string("Hello"), 10, 1.23);
std::string a;
int b;
double c;
std::tie( a, b, c ) = myTuple;

I wouldn’t use std::tuple in an externally visible interface, but it’s useful to avoid defining types for passing multiple return values.

I like this example of using the new standard <random> library to simulate a die:

using my_engine = default_random_engine; // type of engine
using my_distribution = uniform_int_distribution<>; 
my_engine re {}; // the default engine
my_distribution one_to_six {1,6}; 
auto dice = bind(one_to_six,re); // make a generator
int x = dice(); // roll the dice: x becomes a value in [1:6]

 

Leave a comment

Filed under C++

How to write managed C++ using templates

Occasionally, I write some managed C++ code as a glue-layer between C++ and F#. Today was such an occasion, and I found myself writing the same piece of code in several places with different types. Obviously, my reaction was to refactor to share the common code – given that the behaviour was common and independent of the underlying type, a template class seemed appropriate – but can you use templates with managed C++?

It turns out that you can – here’s the code, the aim of which was to take some COM object from native code and wrap it as an option of some expected strong type. If you haven’t seen managed C++ before, the syntax looks pretty ghastly – it may help to mentally substitute & for ^. If you aren’t familiar with F# option, it’s like boost::optional;.

template<typename T>
FSharpOption<T^>^ getOptional( IUnknown* raw )
{
  FSharpOption<T^>^ optionalValue = 
    optionalValue = FSharpOption<T^>::None

  if ( raw != nullptr )
  {
    T^ cooked = (T^)Marshal::GetObjectForIUnknown(IntPtr( raw ));
    if (cooked != nullptr)
      optionalValue = FSharpOption<T^>::Some(cooked);
  }
  return optionalValue;
}

Here’s how you would call the template function to get back the managed C++ equivalent of the F# type MyType option:

FSharpOption<MyType^>^ myValue = getOptional<MyType>( _rawValue );

Leave a comment

Filed under C++