First: really happy with eigen and its new incarnation , excellent work.

The Map stuff does good work for data I/O to non Eigen using code, but sometimes some more facilities might perhaps help keep the interface simple.

I would like to be able to use stl stuff on an Eigen vector - I used data() as a begin() and all was well, but it feels a bit naughty.

It might be nice to load an Eigen container using an stl iterator too - an extension of what happens with operator<< (accessed by a method name) could perhaps take an iterator model as the RHS?

Best of luck with the last bits of 3.0.

yes I agree we could do some effort to be more STL compliant. Please feel free to fill a request on our bugtracker:

http://eigen.tuxfamily.org/bz/

with perhaps one entry per features.

And of course you are very welcome to attach patches even in a proof-and-concept state.

I support that idea. I'd like to have std::adjacent_find() work with Eigen::Vector

Interesting, I didn't know about "data" member-function.

Having defined X as "VectorXd X(N)" (where N is a positive integer indicating size), are the following code snippets equivalent and equally safe, or should I prefer one over another?

Code snippet #0 is provided for reference only, personally I prefer snippet #1 (it's the shortest one and I don't have to repeat myself -- less chance of mistakes), is there any reason I should use, say, snippet #3 instead?

Can I assume allocated-memory-contiguity, just as in C-style arrays and std::vectors?

// 0
for (size_t i = 0; i < N; ++i)
X(i) = SomeFunctionObject();

// 1
generate_n(&X[0], N, SomeFunctionObject);

// 2
generate(&X[0], &X[N], SomeFunctionObject);

// 3
generate_n(X.data(), N, SomeFunctionObject);

// 4
generate(X.data(), X.data() + N, SomeFunctionObject);