
Hi ,
I have a problem, I can' use boost multi array as private member,
I have the mistake: "unexpected extents"
I can only return a boost multi array in my function
Thanks
// KOKO.h: interface for the KOKO class.
//
//////////////////////////////////////////////////////////////////////
#if !defined(AFX_KOKO_H__3E4A2230_0446_43C2_BD69_6FF9C2614C02__INCLUDED_)
#define AFX_KOKO_H__3E4A2230_0446_43C2_BD69_6FF9C2614C02__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#include "boost/multi_array.hpp"
#include <cassert>
using namespace std;
using namespace boost;
class KOKO
{
typedef boost::multi_array

On Wed, 5 Apr 2006, Karim Bakir wrote:
[...]
-- François Duranleau LIGUM, Université de Montréal "You only think you understand. But people cannot perfectly understand each other. The self is an ambiguous thing." - Kaji, in _Neon Genesis Evangelion_ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Boost-Aficionados -
I've been trying to incorporate the boost library into my code for
longer than I'd like to admit, and I keep getting stonewalled due to
my lack of fundamental understanding of much of the 'best practices'
and basic types used in boost. In short, I can't quite make it up the
initial learning curve. As a first test-example, I've been trying to
find the shortest path(s) in a simple 2-dimensional mesh, where each
edge has a non-negative weight, which would seem to be a good case
for dijkstra_shortest_paths. While I got that to compile, the
resulting output wasn't the shortest path, nor the longest. After
some trying (and a question on this list) I gave up on that, and
tried bellman_ford_shortest_paths, just to see if that wouldn't go
better. I'm still having problems, and am hoping that one of the
many frequent boost users might be able to help me out with a bit of
simple checking and exampling.
I've included a simple test-program below (that doesn't compile)
showing what I /think/ things should look like. Obviously, since it's
not compiling, I'm horribly wrong. Still, I'm hoping some kind soul
is willing to run through it and give me pointers on not only what's
wrong, but how to fix it (and/or links to documentation that can help).
Thanks for your time,
Greg Link
//----------------------------------------------------------------------
----------
/*
* testcase.cpp
* speedgraph
*
* Created by Greg Link on 4/6/06.
* Copyright 2006 __MyCompanyName__. All rights reserved.
*
*/
#include <iostream>
#include

Greg Link wrote:
//---------------------------------------------------------------------- ----------
/*
* testcase.cpp
* speedgraph
*
* Created by Greg Link on 4/6/06.
* Copyright 2006 __MyCompanyName__. All rights reserved.
*
*/
#include

Boost-List - About a week ago, I wrote to the list, asking for some basic assistance getting the boost Graph library utilized in a short sample program. One of the list members (Dmitry Bufistov) was kind enough to show me the problem areas in my sample program, and now I've got everything working quite nicely. My question, then is this: Would it be a 'good' thing to try to append the 93-line sample program I posted (now working properly) to the documentation regarding the boost Graph library? Given that the current dijkstra_shortest_paths example doesn't show instantiation of a non-constant path, nor does it show accessing said graph, would a more 'user friendly' example help others in the future? In general, my only problems with the boost libraries so far have been documentation related, so I'm eager to see future users have better access to information. What's the consensus regarding such 'user-friendly' examples, and how would I go about getting something added to the documentation if such examples are considered a 'good' thing? - Greg Link

On Apr 10, 2006, at 11:03 AM, Greg Link wrote:
Absolutely!
If you could submit a patch to the documentation, someone (for the BGL, it would be me) will review the patch and put it in Boost CVS for an upcoming release. Users like yourself are the best people to write this kind of documentation, because you know where we made the mistakes in the current documentation. Those of us that have been writing BGL algorithms for years see things very differently. Doug
participants (6)
-
David Abrahams
-
Dmitry Bufistov
-
Doug Gregor
-
François Duranleau
-
Greg Link
-
Karim Bakir