On 4/13/2012 9:15 PM, Chiheng Xu wrote:
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for ch
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...
Probably, if you can refrain from using some "advance" C++
features(namespace, template, etc.
On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably,
On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar wrote:
> On 4/13/2012 9:15 PM, Chiheng Xu wrote:
>
>> So, I can say, most of the GCC source code is in large files.
>>
>> And this also hold for language front-ends.
>
>
> I see nothing inherently desirable about having all small files.
> For example,
On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably,
On 4/14/2012 6:38 AM, Chiheng Xu wrote:
Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the fu
On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:
Indeed, the notion that 'namspace' is "advance" is troublesome.
Similarly I would find any notion that simple uses and definitions
of templates (functions, datatypes) "advanced" a bit specious.
Indeed! In the case of templates there is a real issu
On 4/14/2012 6:02 AM, Chiheng Xu wrote:
If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.
But personally, when I write C++ code, I never use namespace. I
always prefix my class name(and corresponding source file
On 14 April 2012 11:02, Chiheng Xu wrote:
>
> If debugger fully support namespace, that will be nice. I just say,
> in case debugger have trouble with namespace, you can avoid it.
So it's completely unfounded speculation then.
> But personally, when I write C++ code, I never use namespace. I
> a
Hi,
I am currently trying to build
gcc-4.8-20120401.tar.bz2
on my Windows 7 Pro system using CygWin.
I am using the following configuration settings:
configure \
--enable-languages=c++ \
--disable-bootstrap \
--prefix=/cygdrive/p/gcc$VERSION \
--program-suffix=$VERSION \
--with-gxx-include
2012/4/14 Nicolai Josuttis:
> Hi,
>
> I am currently trying to build
> gcc-4.8-20120401.tar.bz2
> on my Windows 7 Pro system using CygWin.
> I am using the following configuration settings:
> configure \
> --enable-languages=c++ \
> --disable-bootstrap \
> --prefix=/cygdrive/p/gcc$VERSION \
>
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 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
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,
On 14 April 2012 21:14, Pedro Lamarão wrote:
> 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::__en
On Sat, 14 Apr 2012, Pedro Lamarão wrote:
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 el
On 4/13/12, Chiheng Xu wrote:
> On Apr 9, 2012, Richard Guenther wrote:
>>> Certainly there are cases where the type must be made more specific,
>>> and getting the wrong type here would necessarily be a dynamic check.
>>> However, the number of dynamic checks can be substantially reduced.
>>> To
On Sat, Apr 14, 2012 at 2:55 PM, Pedro Lamarão wrote:
> 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 i
Snapshot gcc-4.7-20120414 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120414/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 4/13/12, Torvald Riegel wrote:
> On Fri, 2012-04-13 at 10:46 +0100, Jonathan Wakely wrote:
> > The table at http://gcc.gnu.org/projects/cxx0x.html indicates
> > most of the concurrency work is not done, but I think the status
> > is better than it shows.
> >
> > If I'm not mistaken strong CAS a
On 4/14/12, Gabriel Dos Reis wrote:
> On Apr 14, 2012 Pedro Lamarão wrote:
> > 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 conv
21 matches
Mail list logo
