headers
eg | 1 Sep 01:38
Picon

Re: [IOStreams] Opinion on test case needed

Frank Birbacher wrote:

> http://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_iostreams/libs/iostreams/test/
> 
> (note: no "trac" in the URL)
> 
> I'm glad to hear somebody who's willing to test this! :D
> 

Thanks for the info.

I was able to compile/run all the tests except the error_test.cpp you 
added on Windows using Visual Studio .Net 2003 (professional).

Unfortunately, it generates an internal compiler error:

-----------------
compile-c-c++ 
..\..\..\bin.v2\libs\iostreams\fix-iostreams\error_test.test\msvc-
7.1\debug\threading-multi\error_test.obj
error_test.cpp
c:\dev\boost_1_34_1\libs\iostreams\fix-iostreams\error_test.cpp(142) : 
fatal err
or C1001: INTERNAL COMPILER ERROR
                 (compiler file 
'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c
', line 148)
----------------

This appears to have hit a bug in the VS.Net 2003 compiler which wasn't
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daryle Walker | 1 Sep 01:51
Picon

Macro/Typedef for the biggest integer for template parameters

We've talked about this problem off and on for years now, and I'm 
wondering if we can finally solve it.  Many compilers supply built-in 
integer types beyond (unsigned) long int, but someone told me that 
there's no guarantee that those super-long types are suitable for use in 
a value-based template parameter.  I'm wondering if we can develop 
typedefs, maybe in "boost/cstdint.hpp", that describe the largest 
suitable signed and unsigned built-in integer types that can be used as 
value-based template parameters.  On basically-standard compilers, this 
would be "unsigned long" and "long".  I'm thinking that we could default 
to boost::[u]intmax_t, and #case it for particular compilers after they 
choke on not being able to use "long long" or "__int64_t" in a template. 
  (We could test in advance to minimize hardship.)

--

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Hartmut Kaiser | 1 Sep 02:36
Picon
Gravatar

Re: [Wave] injecting standard headers directly, without a file

Daryle, 

> [Did I already suggest something like this?...]
> 
> The Wave preprocessing tool can accept locations for a 
> compiler's system header files.  I think the C++ standard 
> allows the standard headers to not be implemented as 
> conventional files.  I'm wondering if we can do that, as an 
> experiment.  In other words, the Wave library could have an 
> option to inject our version of idealized renditions of the 
> standard headers directly into the token stream, without 
> referencing actual header files.  This could catch bugs that 
> assume certain things about actual header files that wouldn't 
> be present in our version.

This sounds - hmmm - interesting.

> Our standard headers could be in the form of a collection of 
> functions, one for each compiler item (function, type, 
> object, template, macro, etc.).  Those functions would be 
> passed in a level of expression (declaration in a secret 
> __boost_std namespace, injection of declaration into the std 
> namespace, full definition in __boost_std namespace [or no 
> namespace for macros]) and a descriptor of the environment 
> (bits per byte, bytes per short/int/long, 2/1-complement or 
> sign-mag, etc.).  An inclusion function for each header would 
> call the inclusion functions for each contained item, but 
> only up to the lowest level required. 

Could elaborate, please? Somewhere midsentence you lost me here. Can you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Seefeld | 1 Sep 03:07
Picon
Favicon

Re: [Wave] injecting standard headers directly, without a file

Daryle Walker wrote:
> [Did I already suggest something like this?...]
> 
> The Wave preprocessing tool can accept locations for a compiler's system 
> header files.  I think the C++ standard allows the standard headers to 
> not be implemented as conventional files.  I'm wondering if we can do 
> that, as an experiment.  In other words, the Wave library could have an 
> option to inject our version of idealized renditions of the standard 
> headers directly into the token stream, without referencing actual 
> header files.  This could catch bugs that assume certain things about 
> actual header files that wouldn't be present in our version.

While that would certainly work in theory, I don't think this is a very
practical trick: you'd have to rewrite a huge amount of code (the standard
library is big !), and the result would really only be useful to catch
the kind of 'bugs' you are talking about. You wouldn't be able to actually
do much with the code (such as compile it), as each compiler does in fact
have its own version of standard (and not so standard) headers.

Regards,
		Stefan

--

-- 

      ...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Robert Kawulak | 1 Sep 04:30
Picon

Re: [constrained-value] additional features

> From: Martin Dowie

> I've managed to download this now (thanks!) and I've played 
> about with added support for floats/doubles.

I don't think it's a good idea to use constrained floats - explanation is
attached at the bottom of this message (it's an excerpt from a message in
another thread about this library). Anyway - use at your own risk! :P

> I'd also quite like the idea of being able to retrieve 
> the range of a constrained value
[...]
> typedef bounded_int<int, 0, 359>::type degrees_in_circle;

Not a problem, it's already been there:

	degrees_in_circle::constraint_type::lower_gen_type::value

I know it's not pretty, but I can't help it - this is the price of modularity.
;-)

BTW, to get runtime value in case of stored bounds:

	bounded<int>::type b;
	// ...
	b.constraint().lower_bound()

This works for compile-time bounds too (i.e., for bounded_int etc.).

Best regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco Costalba | 1 Sep 08:00
Picon

Re: Simple yet interesting object factory

On 8/31/07, Janek Kozicki <janek_listy <at> wp.pl> wrote:
> Marco Costalba said:     (by the date of Fri, 31 Aug 2007 20:07:37 +0200)
>
> > This is a simple yet interesting object factory.
>
> Did you have a look at GSoC extension library? (to be submitted for review)
>
>
No, now I check....

....Ok. I've had a look.

Well i won't say "simple", I can get an up to 6 parameter factory with
much less KB and copy & paste. Also I've seen factory uses typeid,
mine does not uess RTTI.

I didn't run the factory, and the tutorial was not enough to say if
the factory checks for parameter overloading and checks for ambiguous
contructor calls, as example

MyClass(int v);
MyClass(int& v);
MyClass(const int& v);

can all be called by
    new MyClass(7);

But compiler errors out (where ctor is called _not_ where ctors are
defined!) for ambiguous call. Factory should check against registering
this kind of c'tor parameters.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Birbacher | 1 Sep 11:46
Picon
Gravatar

Re: [IOStreams] Opinion on test case needed

Hi!

eg schrieb:
> Unfortunately, it generates an internal compiler error:

Oops.

> This appears to have hit a bug in the VS.Net 2003 compiler which wasn't 
> fixed until VS 2005 SP1.
> For details see:
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101318

Great, thanks for the link. Seems to be a strange bug. The description
says reduce the optimization level as a workaround. But you already used
debug mode.

Just a wild guess: does it work with variant=release optimization=space ?

If that doesn't work maybe I should get hold on a previous Visual Studio
myself to investigate this further. And even if I overcome the ICE there
is still the wrong behaviour which the test should (actually it should
not ;) ) reveal.

Thanks,
Frank

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 3 comments |
headers
Manuel Jung | 1 Sep 12:00
Picon
Favicon
Gravatar

Re: [Boost.MPI] How to use with processes on different machines?

Ah okay, now i have a starting point, thanks a lot.
Greetings
Manuel Jung

> Hi Manuel,
> 
> On Aug 31, 2007, at 9:34 AM, Manuel Jung wrote:
>> I would like to know, how i can use Boost.MPI for IPC between
>> different PCs.
>> It is described in the introduction:
>> "Unlike communication in threaded environments or using a shared-
>> memory
>> library, Boost.MPI processes can be spread across many different
>> machines,
>> possibly with different operating systems and underlying
>> architectures."
>>
>> Is there an example, how its done? I cant find one. Or isn't
>> implemented
>> yet?
> 
> It's implemented, but how it's done depends on the underlying MPI
> implementation and your specific configuration. Boost.MPI builds on
> top of the C MPI interface, for which there are many different
> implementations. Here are some open-source possibilities:
> 
> - Open MPI: http://www.open-mpi.org/
> - MPICH2: http://www-unix.mcs.anl.gov/mpi/mpich2/
> 
> If you already have a cluster that you plan to use, there is probably
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mathias Gaunard | 1 Sep 16:13
Picon

Re: Simple yet interesting object factory

Marco Costalba wrote:

> You can view as HTML page a simple and commented test program here:
> http://digilander.libero.it/mcostalba/simple_factory/main.cpp.html

Your small document doesn't talk about ownership and lifetime management 
of the created object.

As for the forwarding problem, this is solved using rvalue references. 
However, since they're not available in C++03, people use pass-by-value 
instead, and boost::ref when they want to pass by reference.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
David Abrahams | 1 Sep 16:27
Picon
Picon
Favicon
Gravatar

Re: Clang: Open-source C/C++ front end under development


on Fri Aug 31 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:

> Hello fellow Boosters,
>
> The need for an extensible, complete open-source C++ parser has been  
> discussed on Boost over the years. There are myriad projects that  
> parse approximations to C++ suitable for specific tasks (e.g.,  
> documentation generation), but there has never been a  community  
> project meant to handle all of C++ or serve as a common platform for  
> new C++ tools. That is going to change, and I hope Boost will be  
> involved.
>
> Apple has begun development of "Clang", which aims to be a high- 
> quality C/C++ parser and compiler. Clang is designed as a library for  
> C++ tools, from IDE-supported tools like indexing, searching, and  
> refactoring to documentation tools, static checkers, and a full C++  
> front end to the Low Level Virtual Machine (LLVM). LLVM is an  
> advanced, open-source compiler infrastructure supporting all of the  
> back-end functionality needed for a C++ compiler. Like LLVM, Clang is  
> written in a modern C++ style, with a clean separation between the  
> different phases of translation in C++ (lexical analysis, parsing,  
> semantic analysis, lowering, code generation, etc.), all of which  
> make Clang a pleasure to work with.
>
> Clang is still in the early stages of development. At present, it  
> parses and type-checks most of C, with code generation for some  
> simple constructs. C++ support is not available yet, but Apple has  
> dedicated significant resources to making Clang a successful C++  
> parser and compiler.
(Continue reading)

Permalink | Reply | 28 comments |

Gmane