@Gerardo: That explains, thanks.
@Matt: exactly :) 
About the int vs all sorts of other variable types: loss of data will only occur when the numbers become extremely large, maybe something to look at but not probable. The limit of the loop is the size of some array and if that array would be as large as the max positive value of an int the memory size of the vector would be extremely large (larger than available memory?).
About the regression in speed... ok, maybe. But not sure if this piece of the code is that sensitive. 
But to be honest I do not see a reason why NOT to use std::ptrdiff_t

On Wed, Feb 26, 2014 at 10:57 PM, Matt <matdzb@gmail.com> wrote:
On 2/26/2014 16:56, Luigi Ballabio wrote:
> I see. There should be no problem in patching the code to turn those
> into ints, except that I'm all set to release 1.4 tomorrow, I have a
> few busy weeks ahead and I'd rather be done with the release and not
> go through all the checks again after patching. So I'd release with
> the Size indices and leave it to you to patch it untli a bug-fix
> release sometime in the near future. Would that be a problem?


As someone who has faced this issue before, perhaps I can add a quick
comment. This is a limitation of the current level of OpenMP support in
Visual Studio. The latest supported version is OpenMP 2.0, see:

This limitation has been relaxed in OpenMP 3.0 (not supported by MSVC);
see Appendix F, "Changes from Version 2.5 to Version 3.0":
"Random access iterators, and variables of unsigned integer type, may
now be used as loop iterators in loops associated with a loop construct
(see Section 2.5.1 on page 38)."
// Source: http://www.openmp.org/mp-documents/spec30.pdf

As of today there has been no updates on the OpenMP 3.0 support:

I would NOT recommend using `int` to address this issue -- this may
bring a whole new set of bugs (e.g., loss of data, possible regression
in performance due to size-conversions).

Consider using either `std::ptrdiff_t` or Boost's
- http://en.cppreference.com/w/cpp/types/ptrdiff_t

If potential performance regression is not an issue and the goal is to
avoid data loss at all costs, then even `boost::intmax_t` may be worth
considering: http://www.boost.org/libs/integer



Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
QuantLib-users mailing list