Hello.
I would like to point out to those that may be interested and don't read
comp.std.c++:
http://russ.hn.org/rref/
The thread is:
http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/64bf775bdf069dad/de55703ebbe063ce#de55703ebbe063ce
--
Pedro Lamarão
" as per DR #106 proposed resolution, and the "r-value
references" proposal as in N1855.
I'd like to also try and implement the new "auto" semantics as in N1894.
These are online for your viewing pleasure here:
http://mndfck.org/~pedro.lamarao/projects/c++0x/
Would any of this be acceptable for 4.2?
--
Pedro Lamarão
Adjusting file timestamps
> SVN update of full tree failed.
Have you tried doing "svn cleanup" as the error message suggests?
--
Pedro Lamarão
y, in the hurry of trying to "help" I
totally missed these lines. :-(
--
Pedro Lamarão
Current trunk (revision 150381) fails to bootstrap with the following
configuration:
[pedro.lama...@larissa trunk-obj]$ ../trunk/configure
--prefix=/opt/gcc-4.5 --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-
Revision 150382 of the cxx0x-lambdas-branch fails to bootstrap with the
following error:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength
iding a separate version of vec.h when C++ is
being used, to avoid infinite #ifdefs.
Is this a good idea?
--
Pedro Lamarão
2009/8/12 Richard Guenther :
> On Wed, Aug 12, 2009 at 2:03 AM, Pedro
> Lamarão wrote:
>> I've recently started my contributions to the gcc-in-cxx project, and
>> eventually decided on the qsort suggestion because it seems the
>> easiest one.
>> I'
2009/8/26 Ralf Wildenhues :
>> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
>> >‘char* basename(const char*)’
>> >/usr/include/string.h:601: error: ambiguates old declaration ‘const
>> >char* basename(const char*)’
>>
>> The problem is that AC_CHECK_DECLS gets confused b
2009/8/29 Magnus Fromreide :
>
> Why the changes to gcc/system.h where you unpoision malloc and realloc?
> Why the changes to libcpp/system.h where you unpoision malloc, realloc,
> calloc and strdup?
Including requires them for some reason.
I haven't really looked into it.
--
P.
2009/8/31 Richard Henderson :
> On 08/29/2009 03:49 PM, Pedro Lamarão wrote:
>>
>> 2009/8/29 Magnus Fromreide:
>>>
>>> Why the changes to gcc/system.h where you unpoision malloc and realloc?
>>> Why the changes to libcpp/system.h where you unpois
2009/8/28 Pedro Lamarão :
> I have not yet made complete size and execution speed measurements, though.
> I've run the test suite and there are some failures; I think many of
> them are not regressions when compared with a pure build with C++.
Comparing trunk -r151160 and
2009/9/1 Michael Matz :
>> [psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++
>> -rwxrwxr-x. 1 psilva psilva 481K Ago 31 12:58 gcc/g++
>> -rwxrwxr-x. 1 psilva psilva 477K Ago 31 12:58 gcc/xgcc
>
> That's not the real compiler, only the compiler driver. Look for files
> named cc1 (the C compiler) and cc1
2009/9/10 Ralf Wildenhues :
> * Pedro Lamarão wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST:
>> 2009/8/26 Ralf Wildenhues:
>> I think this is new in glibc 2.10, for the reasons given by Jason Merrill
>> above.
>> I've discussed this problem with Jerry Quinn b
welcome!
There is a lot of talk on "branches" in that page, but currently I'm
working on a file:// Subversion repository. Soon I'll try (again) to put
that one up in a public place.
I'd like to eventually contribute these to the project; but feel it is
very early, the ne
Mike Stump escreveu:
> On Jun 9, 2006, at 6:31 PM, Pedro Lamarão wrote:
>> Currently I have implemented in g++ the "Static Assertions" and the
>> "Right Angle Brackets" C++0x features in g++. Those are the simplest
>> ones that got into the working draft
&g
Em 21/03/2012 08:58, Peter Dolding escreveu:
If there is a grey area you have broken into modules wrong. Module
based code has no grey. No grey equals less errors of person editing
a file they think is exclusive to some part that turns out to be
shared with another part so causing nasty failur
With GCC 4.7 and the following program:
--
struct byte
{
unsigned char _;
byte () = default;
explicit operator unsigned char () { return _; }
};
struct wyde
{
unsigned short _;
wyde () = default;
constexpr wyde (unsigned short r) : _(r) { }
};
struct foo
{
byte one;
wyde two
On 04/04/2012 08:20 AM, Diego Novillo wrote:
On 4/4/12 5:06 AM, Richard Guenther wrote:
Btw, I think we should only start forcing C++ when 1) there is a
branch/patch out
that shows benefit from using C++. I previously mentioned that I'd
like to see
2) a patch that _properly_ wraps a C++ class f
On 04/05/2012 11:29 AM, Gabriel Dos Reis wrote:
this is drifting, but since we talking about teaching (which is part of my
daytime job)
On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar wrote:
Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that
le with C++. Whenever
the branch is ready, or people want to review, or both, I can submit
patches.
--
Pedro Lamarão ∷ http://www.pedro.lamarao.nom.br/
"Sanity consists in the faculty of adjusting ideas in proper
proportion." - Aleister Crowley
Hello,
currently proposed C++ Coding Conventions imply a very strict
weird-is-forbidden style, which I like.
But if defining new templates should in general be avoided, I'm unsure
what is the best path in converting VEC.
VEC interface optimizes element acessors to copy primitive types and
On 04/14/2012 05:07 PM, Jonathan Wakely wrote:
On 14 April 2012 20:55, Pedro Lamarão wrote:
Since enable_if is not part of C++98, it would be added to GCC itself --
perhaps in namespace gcc.
libstdc++ provides __gnu_cxx::__enable_if in
When vec.h is compiled in stage1 by the host compiler
23 matches
Mail list logo
