On 14 January 2011 16:39, Achilleas Margaritis wrote:
>
> I have already explained it, but I don't mind explaining it once more:
>
> 1) the pragma #autoinclude ("foo.hpp", "foo.cpp") instructs the
> compiler to generate the header 'foo.hpp' from the implementation file
> 'foo.cpp'.
>
> 2) the compi
> I am not mistaken. For a single Ada program that compiles
> successfully, there is 1-to-1 correspondence of a package declaration
> and package body.
>
> >
> > It's not uncommon to have multiple different implementations of the
> > same specification, for example for different target architectur
On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu wrote:
>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
>>> On 12/30/2010 01:08 PM, Robert Millan wrote:
Hi folks,
I had this unsubmitted patch in my local filesystem. It makes Lin
2011/1/12 Joseph S. Myers :
>> I don't understand this code, but what I can do is confirm that disabling
>> linux-unwind.h doesn't cause any breakage. Then we could disable it
>> untill/unless someone more clued than me ports it to kFreeBSD. Would
>> this be ok?
>
> That makes sense to me.
Confi
Achilleas Margaritis writes:
> On Thu, Jan 13, 2011 at 9:53 PM, Ian Lance Taylor wrote:
>> Achilleas Margaritis writes:
>>
>>> How much do you spend in maintaining headers? answers welcomed from
>>> other members as well.
>>
>> In C++, I personally spend very little time doing what I would desc
> the compiler non-conforming makes it a non-starter. This would have to
> be done under some switch.
The switch idea is fine by me, although not necessarily required,
since it can be implicit anyway (it's like saying to the end-users:
hey, you don't have all the functions inline with #autoinclude
On 14 January 2011 17:10, Achilleas Margaritis wrote:
>>> There is a solution to that: the compiler, knowing that foo::bar is
>>> not an inline function, it does not inline the function but it
>>> automatically compiles the relevant symbol in the foo.o object file.
>>
>> Which is a change to the la
On 1/14/2011 12:10 PM, Achilleas Margaritis wrote:
There is a solution to that: the compiler, knowing that foo::bar is
not an inline function, it does not inline the function but it
automatically compiles the relevant symbol in the foo.o object file.
Which is a change to the language semantics!
>> There is a solution to that: the compiler, knowing that foo::bar is
>> not an inline function, it does not inline the function but it
>> automatically compiles the relevant symbol in the foo.o object file.
>
> Which is a change to the language semantics!
The compiler can inline the trivial memb
On 1/14/2011 11:44 AM, Achilleas Margaritis wrote:
Oh yes it does. Have you seen a Qt source code file? we are talking
about some comments being many pages long. Multiply that with multiple
inclusions of the same header, add lots of files, and you get the
idea.
There are lots of specs in the A
On 14 January 2011 15:39, Achilleas Margaritis wrote:
> On Fri, Jan 14, 2011 at 5:29 PM, Axel Freyn wrote:
>> On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
>>> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
>>> wrote:
>>> > On 14 January 2011 13:26, Achilleas Margaritis
On Fri, 14 Jan 2011, Robert Millan wrote:
> I can prepare an updated version of this patch (relative to
> trunk + your linux.h overhaul [2]).
Yes, that seems appropriate (it would now just be relevant to trunk since
my gnu-user.h patch is now in trunk).
--
Joseph S. Myers
jos...@codesourcery.c
On Fri, Jan 14, 2011 at 6:22 PM, Robert Dewar wrote:
> On 1/14/2011 11:10 AM, Achilleas Margaritis wrote:
>
>> The same documentation can be put in the implementation file.
>
> Yes, if you have formal conventions for documentation you can
> achieve the separation (as is done in well-written Java p
> There you are definitely wrong. Of course headers are specifications,
> they specify the parameter types etc.
Headers contain specifications, I agree to that. However:
1) headers could contain anything, at least in C/C++.
2) said specifications can be part of a single file of code; there is
no
On 1/14/2011 11:18 AM, Achilleas Margaritis wrote:
On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner
wrote:
The Ada people call their headers 'specifications', because a lot of
program specifications are placed in those headers.
But they are not specifications in a sense that you can have multi
On Fri, Jan 14, 2011 at 05:39:58PM +0200, Achilleas Margaritis wrote:
> > [...]
> > There is a violation of the C++-standard:
> > - when main.cpp is compiled, the compiler reads "foo.hpp" -- and it
> > learns that the class "Foo" has a member-function "bar" which can be
> > call from within ma
On 1/14/2011 11:10 AM, Achilleas Margaritis wrote:
The same documentation can be put in the implementation file.
Yes, if you have formal conventions for documentation you can
achieve the separation (as is done in well-written Java programs),
but it is so much easier to do if you have separate
On 1/14/2011 11:08 AM, Achilleas Margaritis wrote:
On Fri, Jan 14, 2011 at 5:59 PM, Paul Koning wrote:
...
2) I like headers because they are specifications (they aren't, but
what can I do if one believe so? nothing).
I think that's a matter of opinion, and language-specific as well.
I dis
On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner
wrote:
>> The Ada people call their headers 'specifications', because a lot of
>> program specifications are placed in those headers.
>>
>> But they are not specifications in a sense that you can have multiple
>> implementations of them. I.e. there i
> The Ada people call their headers 'specifications', because a lot of
> program specifications are placed in those headers.
>
> But they are not specifications in a sense that you can have multiple
> implementations of them. I.e. there is a 1-to-1 correspondence between
> Ada package declarations
On 1/14/2011 11:07 AM, Richard Kenner wrote:
Back many years ago when I was doing VLSI design, there was one large
CAD system written in C (I forget which one now) that had extensive
documentation in their header files. I think that was a major part of
the quality of that tool.
There you go R
On Fri, Jan 14, 2011 at 6:07 PM, Richard Kenner
wrote:
>> And as an implementer of large C/C++ based embedded systems, I tend to the
>> view that, while some programmers don't think of headers as specifications,
>> they should, and doing so is helpful to achieving high quality.
>
> Back many year
On Fri, Jan 14, 2011 at 5:59 PM, Paul Koning wrote:
>> ...
>>
>> 2) I like headers because they are specifications (they aren't, but
>> what can I do if one believe so? nothing).
>
> I think that's a matter of opinion, and language-specific as well.
I disagree that it is 'a matter of opinion'. It
> And as an implementer of large C/C++ based embedded systems, I tend to the
> view that, while some programmers don't think of headers as specifications,
> they should, and doing so is helpful to achieving high quality.
Back many years ago when I was doing VLSI design, there was one large
CAD s
> ...
>
> 2) I like headers because they are specifications (they aren't, but
> what can I do if one believe so? nothing).
I think that's a matter of opinion, and language-specific as well. C is such a
loose language that applying the notion of "specification" is hard. Ada is
quite another st
On Fri, Jan 14, 2011 at 5:29 PM, Axel Freyn wrote:
> On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
>> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
>> wrote:
>> > On 14 January 2011 13:26, Achilleas Margaritis wrote:
>> >> My proposal does not change the language in an
2011/1/12 Ian Lance Taylor :
> All that said, I see little harm in using a PT_GNU_STACK header on
> binaries even if the kernel does not fully support them. Except for the
> small amount of wasted space in every .o file and every executable, but
> I lost that argument years ago.
Thanks Ian. Seei
2011/1/12 Robert Millan :
>> * The headers config/kfreebsd-gnu.h etc. override
>> GLIBC_DYNAMIC_LINKER. But the 64-bit configurations
>> x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
>> use any header that would override GLIBC_DYNAMIC_LINKER32 and
>> GLIBC_DYNAMIC_LINKER64,
On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
> wrote:
> > On 14 January 2011 13:26, Achilleas Margaritis wrote:
> >> My proposal does not change the language in any way, it only is a
> >> copy-and-paste job.
> >
> > That'
>> 1) It is not interesting work for me, so you do it or pay someone else
>> to do it (you seem to be into that camp).
>
> That's always an appropriate response! The remedy is to propose a
> patch yourself (or pay someone to do it), then we can see if it
> makes sense when the details are worked ou
On 1/14/2011 10:17 AM, Achilleas Margaritis wrote:
The #autoinclude pragma can select to inline only those member
functions that are good candidates for inlining. I.e. it can inline
trivial code. I believe the GCC code already contains such criteria,
like any other good compiler.
Not sure what
On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely wrote:
> On 14 January 2011 13:26, Achilleas Margaritis wrote:
>> My proposal does not change the language in any way, it only is a
>> copy-and-paste job.
>
> That's not true, your example with an inline member function
> demonstrates that the compi
On 14 January 2011 13:26, Achilleas Margaritis wrote:
> My proposal does not change the language in any way, it only is a
> copy-and-paste job.
That's not true, your example with an inline member function
demonstrates that the compiler must be changed to support your
proposal, so that functions de
On Fri, Jan 14, 2011 at 4:55 PM, Robert Dewar wrote:
> On 1/14/2011 9:23 AM, Achilleas Margaritis wrote:
>
>> All newer languages don't have header files...
>
> And to me, it is a serious flaw :-) One of
> several, e.g. in Java.
>
>
Actually, it is not a flaw, it is a blessing :-).
On 1/14/2011 9:23 AM, Achilleas Margaritis wrote:
All newer languages don't have header files...
And to me, it is a serious flaw :-) One of
several, e.g. in Java.
On Fri, Jan 14, 2011 at 4:14 PM, Robert Dewar wrote:
> I guess I would just summarize things as follows. You
> can possibly generate headers automatically (just as
> you could generate subprogram specifications in Ada
> automatically).
>
> No one would ever think of suggesting doing this
> automat
On Fri, Jan 14, 2011 at 4:09 PM, Robert Dewar wrote:
> On 1/14/2011 8:47 AM, Achilleas Margaritis wrote:
>
>> 2) the actual knowledge about the program stored in a header is, from
>> my rough estimation, up around 20% of what the program actually does.
>> In order to incorporate the actual knowled
I guess I would just summarize things as follows. You
can possibly generate headers automatically (just as
you could generate subprogram specifications in Ada
automatically).
No one would ever think of suggesting doing this
automatically in Ada.
Why not? Because you might be able to generate
the
On 1/14/2011 8:47 AM, Achilleas Margaritis wrote:
2) the actual knowledge about the program stored in a header is, from
my rough estimation, up around 20% of what the program actually does.
In order to incorporate the actual knowledge required, a lot of
documentation has to be written. I comment
On Fri, Jan 14, 2011 at 3:35 PM, Robert Dewar wrote:
> Ian Lance Taylor wrote:
>
>> In C++, I personally spend very little time doing what I would describe
>> as "maintaining headers." I write class definitions in .h files and
>> function implementations in .cc files. The only data which appear
Ian Lance Taylor wrote:
In C++, I personally spend very little time doing what I would describe
as "maintaining headers." I write class definitions in .h files and
function implementations in .cc files. The only data which appears in
both places is the function signature. Yes, it would be sl
On Thu, Jan 13, 2011 at 9:53 PM, Ian Lance Taylor wrote:
> Achilleas Margaritis writes:
>
>> How much do you spend in maintaining headers? answers welcomed from
>> other members as well.
>
> In C++, I personally spend very little time doing what I would describe
> as "maintaining headers." I wri
İLERİ DANİSMANLİK'TAN KOBİLE'RE MALİ DANİSMANLİK HİZMETİ
KOBİ'lere Mali Danışmanlık hizmeti!
Avukatlara ve Mali Müşavirlere dosya hazırlıkta destek!
Tüm hizmetlerimiz için web sitemizi ziyaret ediniz.
www.ileridanismanlikhizmetleri.com
Vergi Davaları
Uzlaşma
Vergi Suçları
İflasın Ertelenme
43 matches
Mail list logo
