Re: problem Boost libraries
Yuriy Koblents-Mishke wrote:
On Mar 5, 5:39 am, "James Kanze" <james.ka...@gmail.com> wrote:
[snip]
Nor sufficient. The const syntax ensures bitwise const; what is
needed here is logical const, without any (logical) mutable.
Yes, mutables will create a problem.
I was thinking in the more general sense. You can get the same
effects through e.g. pointers. The point is that 1) even if the
object is not const, you might not modify it, and 2) even if it
is const, accessing it may cause modifications. The keyword
const is neither necessary nor sufficient.
[snip]
I would rather not
put arrays of 65000+ elements in my source code, though.
I do:-). Of course, I don't write them out by hand; I generate
them automatically.
:-(
Even while they are generated automatically, I would prefer to make
them readable to human.
They're as readable as any table of thousands of elements is.
Especially when the tables will be parts of
published, open source code.
Publish the generator.
It looks as Boost Preprocessor lets to
make the tables digestible, but I did not finished with it yet.
I've also been known to use mmap for this sort of stuff, with
the actual data in a separate file. But of course, that
introduces the initialization problems.
With a separate source file (not a mmap one!) I could initialize what
I need statically during compilation outside of (template) function,
in a wrapper (template) class. However, these data files (what used to
be BLOCK DATA in Fortran) do not link into programs automatically, as
functions do, and cannot be #included in more than one compilation
unit. I am trying to avoid them in libraries.
I'm not sure what you mean. I have one or two such cases, and
they link in automatically from the library for me.
[snip]
Other compilers don't offer it. If you ever count on porting
your code to other compilers, it's best not to use it.
I see.
The standard's committee is discussing the issue, but I don't
know off hand what their current thinking is. In favor, of
course, is the fact that the compiler can generate the extra
machine instructions which might be needed, so that it
potentially costs less than if you try to manage it by hand.
Against is the fact that it does introduce some excess costs,
albeit not very high, and these costs will be there whether you
use the facility or not, which violates the "you don't pay for
it if you don't use it" philosophy.
I have an impression that currently C++ does not know at all about
multithreading.
It depends on what you mean by "currently". The official
current version of the C++ standard is C++-2003, and it doesn't
know about threads. The standardization committe is trying to
put out a new version before the end of the decade, however, and
it will almost certainly be thread aware; there is currently
much discussion in the committee as to what the interface(s)
will look like, and such. There will also be a decision one way
or the other with regards as to who is responsible for the
synchronization of the construction of static variables, but I
have no idea what the tendancy is in this regard.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]