nner loop would have another 1 iterations. So we get
> > > 10.000*10.000=100.000.000 = one hunred million iterations. This is ways
> >
> > too
> >
> > > slow and ways too much.
> > > This needs on my 1.2GHz Atlon with 512 MB Ram more then five seconds.
&g
- Personally, I would find a list of *all* keys more desirable (that
> is, list any key that is found in any of the chosen lexicons). I
> took a look at Bibleworks when visiting my brother (he is teaching
> OT) and noticed it has a feature where instead of having a window
> per dictionary,
C++ has a standard algorithm called set_intersection - found in the header
. Given two sorted sequences, it will output the items that are
found in both sequences. This function is very efficient, and with use of
it, I think your problem should become trivial. Documentation for this
algorithm can b
I have MSVC++6; tell me what needs building and I'll try it.
I might also be able to get access to MSVC++7, since we have it at work.
-David.
On Wed, 2002-10-30 at 16:19, Joel Mawhorter wrote:
> Is VC++ 5 known to work with Sword? What sorts of problems are you having? I
> would prefer to test
I'd just like to point out a few things on this:
- Firstly, I think it's a really good idea, and I think I suggested it a
while ago :)
- Some older or less conforming compilers might not know about or like
namespaces
- You also might like to consider creating sub-namespaces, for instance
anything
On Thu, 2002-09-05 at 14:08, Troy A. Griffitts wrote:
> > - An additional constructor for SWConfig should be provided which takes
> > a sequence of configuration files, which are all loaded and combined
> > - A method should be provided which allows loading of a configuration
> > file and merging
Hi everyone,
I'm looking to get involved in Sword development, and Troy has asked me
to look at some changes to the SWConfig module. I have drawn up a brief
specification of proposed changes, and I ask interested parties to
peruse the specification and provide comments and feedback.
Current Beha
oops, please ignore that email, it was sent by mistake..
On Sun, 2002-03-10 at 20:09, David White wrote:
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> using std::string;
>
> struct verse {
>
#include
#include
#include
#include
#include
#include
#include
using std::string;
struct verse {
verse(string b, string c, string v)
: book_name(b), chapter_num(c), verse_num(v) {}
string book_name, chapter_num, verse_num;
};
struct range {
range(const verse& v) : lower(v), uppe
I needed to reverse engineer some C++ code into UML diagrams at my
workplace, so I wrote a Python script, which does a reasonably good job
of it. It doesn't export to any common formats (except images), but that
could be added without too much trouble. If anyone is interested, let me
know.
Blessi
Why is it that containers have to "set" the key they are operating on?
This seems a little awkward to me.
I think it would be a good idea to move towards supporting full-strength
bidirectional or random-access iterators across modules, compliant with
the specifications of the C++ standard, so as
if you're cross
> compiling, right? If I'm compiling for my system using a locally compiled
> version of the compiler (or at least one native to my processor) I should be
> able to leave those options off, I think.
>
> Gregg
>
> - Original Message -
> From:
This is likely because in C++, all C runtime functions (isalpha,
isdigit, strcmp, strncpy and so on and so forth) are meant to be in the
std namespace, rather than in the global namespace. So, you have to use
std::isalpha instead of isalpha (and likewise for all C runtime
functions).
Many C++ com
When I have a little more time, I will look over this in more detail,
but an obvious small change to me is the function
SWModule::filterBuffer. It contains the following code:
FilterList::iterator it;
for (it = filters->begin(); it != filters->end(); it++) {
(*it)-
002-02-11 at 04:07, David White wrote:
> > While I was looking through the searching code for Sword, I noticed a
> > few things which seemed little strange, and I thought I'd make comments
> > on ways in which they could be improved:
> >
> > there is lots of code
.sword/
>
>
> Sword data can be place anywhere on your system. One of these 4
> mechanisms must be used to tell the engine WHERE your data lives. I
> don't think we need more mechanisms to specify WHERE.
>
> Does this make sense?
>
> -Troy.
>
>
>
That is why I would suggest using a configuration script of some kind.
Users should not have to be root to install Sword, and I assume Sword is
intended to work on a wide variety of platforms, which may have very
different directory hierarchy schemes. Thus it is important for Sword to
robustly sup
While I was looking through the searching code for Sword, I noticed a
few things which seemed little strange, and I thought I'd make comments
on ways in which they could be improved:
there is lots of code in destructors that looks like this:
if (entrybuf)
delete [] entryb
On Mon, 2002-02-11 at 14:45, John Stovall wrote:
> But for third world missionary efforts in my opinion the
> emphasis of Sword needs to be turned towards very easy to use
> Linux modules.
I concur. I have a couple of suggestions for making Sword easier to
install and use:
- firstly, the website
On Mon, 2002-02-11 at 02:26, Trevor Jenkins wrote:
>
>
> For those who don't know or have forgotten I proposed an inverted file
> search system. Every word to be indexed and its position recorded. The
> position pointers should be of two forms. For a Bible search program the
> obvious one is pos
eveloping Bible-based applications, and how Sword
can improve to address these issues.
God Bless,
David White.
On Sun, 2002-02-10 at 11:51, Chris Little wrote:
>
> > > Sword removes much of the burden of designing new Bible software.
> > > Most of the underlying issues, su
21 matches
Mail list logo
