RE: [boost] FC++ Formal review - some initial results/impressions

From: Boost (boost_at_[hidden])
Date: 2004-02-17 12:47:18

| What is your evaluation of the design?

It seems useful (if a reflection of underlying limitations in the C++
language) and doesn't fight too much with STL concepts. There is some
overlap with STL and other Boost libraries like lambda, but the gains
are worth any duplication.

| What is your evaluation of the implementation?

Seems to work OK.

| What is your evaluation of the documentation?

Good selection of helpful examples (but could be commented better).
Better than one might expect considering the difficulty of the concepts.
A whole book could easily be produced :-)

|  What is your evaluation of the potential usefulness of the library?

Extends the scope of C++ significantly -
but I am unsure quite how many people will use it at first. (Like the
STL, it requires some change of mindset).

|  Did you try to use the library?

Yes, briefly with a few of the many sample programs.

| With what compiler?

MSVC .net aka 7.1 (mainly with std for loop scope, warnings level 4
(strict)

|   Did you have any problems?

 Some warnings, mostly spurious but potentially annoying, and probably
easily removable.

|  How much effort did you put into your evaluation?

An couple of hours digesting the pdf paper and an hour or so trying test
programs.

|  Are you knowledgeable about the problem domain?

 Enough to see its potential - but probably not its pitfalls?

|  Overall:  I vote for acceptance into the Boost library.

Paul A Bristow

Some observations, mostly minor:

1  I have tried a few sample .cpp files

and the ones I have tried all compile and run as expected, although most
with some warnings (see below). 
This makes me optimisitic that all will compile with MSVC 7.1, but I
hope someone with more time will confirm this.

Although there are many useful and informative tests
(some using the essential Boost test suite)
I feel it would also be useful to have a single test suite (or a few)
which are suitable for routine regression testing.

It would be nice to reduce warning noise
(provided it is not too much trouble).

Although MS users rarely use 'strict' for 'production' code because
Windows requires non-strictness, I believe strongly that it will
increase portability to try to get code that is accepted by all
compilers in strict mode.  A Pre-emptive strike?

For example, compiling  Example.cpp

Msvc 7.1 (warnings level 4, no language extensions aka strict) produces
some warning 'noise' at:

  const T operator*() const { return l.head(); }

"qualifier applied to function type has no meaning; ignored

A qualifier, such as const, is applied to a function type defined by
typedef.

Example

// C4180.cpp
// compile with: /W1 /LD
typedef int *FuncType(void);

// the const qualifier cannot be applied to the
// function type FuncType
const FuncType f;   // C4180"

i:\FCpp\list.hpp(510) : warning C4180: qualifier applied to function
type has no meaning; ignored
        i:\FCpp\list.hpp(527) : see reference to class template
instantiation 'boost::fcpp::impl::list_iterator<T>' being compiled
i:\FCpp\list.hpp(1042) : warning C4180: qualifier applied to function
type has no meaning; ignored
        i:\FCpp\list.hpp(1059) : see reference to class template
instantiation 'boost::fcpp::impl::strict_list_iterator<T>' being
compiled

However, this is a level 1 warning, so Microsoft obviously believe it is
wrong C++.

And also 

i:\FCpp\curry.hpp(131) : warning C4512:
'boost::fcpp::impl::binder1of2<Binary,Arg1>' : assignment operator could
not be generated
        with
        [
            Binary=boost::fcpp::impl::XPlus,
            Arg1=std::string
        ]
        i:\FCpp\full.hpp(82) : see reference to class template
instantiation 'boost::fcpp::impl::binder1of2<Binary,Arg1>' being
compiled
        with
        [
            Binary=boost::fcpp::impl::XPlus,
            Arg1=std::string
        ]
        FC++example.cpp(34) : see reference to class template
instantiation 'boost::fcpp::full1<F>' being compiled
        with
        [
 
F=boost::fcpp::impl::binder1of2<boost::fcpp::impl::XPlus,std::string>
        ]
i:\FCpp\full.hpp(102) : warning C4512: 'boost::fcpp::full1<F>' :
assignment operator could not be generated
        with
        [
 
F=boost::fcpp::impl::binder1of2<boost::fcpp::impl::XPlus,std::string>
        ]

(Which perhaps might be supressed by inheriting from
Boost::noncopyable??? - I am NOT an expert on this!)

Cute_compose)syntax required language extensions because not linked with
the separately compiled Boost test library.

Some examples might be more quickly understood by the 'functionally
challenged' with the output as a comment, for example:

// Test automatic currying.
  cout << f(3)(5) << endl; // 3 + 5 = 8

Another nitpick is that the files don't follow the Boost guideline:

o  A comment line describing the contents of the file.

I really like this style:

#include <iostream>
using std::cout; using std::endl;

Which shows immediately what is being used from each include file.

In some cases replacing:

  using namespace boost::fcpp;

With 

  using boost::fcpp::list_with;  using boost::fcpp::list;  using
boost::fcpp::tail;
  using boost::fcpp::take;  using boost::fcpp::compose;  using
boost::fcpp::enum_from;

might also be more helpful.

Is there a Boost convention for the order of include files?
I always but the std library includes first, but I note that these
examples include FCpp modules first, before std, for example
compose2.cpp

#include "prelude.hpp"
#include <iostream>

I think I also found a file which didn't end with a 'return' and so
failed to compile in 'strict' mode (but I can't remember which).

Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone]  [phone]
mailto: pbristow_at_[hidden]

Sent: 13 February 2004 19:14
To: boost_at_[hidden]
Subject: [boost] FC++ Formal review is now in progress (2/13-2/23)

The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is
now in progress, runiing from Friday February 13th at 12 noon, PST and
and run to Monday, February 23rd, 12 noon PST.