Achilleas Margaritis writes:
> So, if the compiler checks the code, and the documentation says
> whatever must be said about the program, headers are completely
> redundant.
I think this is often/usually not true in practice though.
It seems _far_ more common for there to be reasonable header fi
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
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, 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
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
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 write class definitions in .h files and
function implementations in .cc
>> Why not? doesn't GCC contain all that is required for that parsing to
>> succeed?
>
> GCC has bugs and doesn't parse everything 100% correctly, given the
> complexity of the language.
Oh, ok then. But I think consistence is more important than
correctness in this case: the result header file s
On 13 January 2011 16:59, Achilleas Margaritis wrote:
>>>
>>> The pragma can be ignored by other compilers. Conditional compilation
>>> would help in including the header for other compilers.
>>
>> Except the header wouldn't exist if you use other compilers, because
>> you need gcc to generate it.
>> A makefile will not work. I explain why below in the section about the
>> problem of clashing of symbols.
>>
>> There is no default transformation. The header's filename extension
>> will be defined in the include string name. For example:
>>
>> #pragma autoinclude("foo.hh")
>> #pragma autoinclu
On 13 January 2011 13:06, Achilleas Margaritis wrote:
> On Thu, Jan 13, 2011 at 2:41 PM, Jonathan Wakely
> wrote:
>> On 13 January 2011 11:09, Achilleas Margaritis wrote:
>>> On Wed, Jan 12, 2011 at 6:16 PM, David Brown wrote:
I can see how such a feature could be useful, but is there
On Thu, Jan 13, 2011 at 2:41 PM, Jonathan Wakely wrote:
> On 13 January 2011 11:09, Achilleas Margaritis wrote:
>> On Wed, Jan 12, 2011 at 6:16 PM, David Brown wrote:
>>>
>>> I can see how such a feature could be useful, but is there any reason why it
>>> should be part of gcc, rather than a sepa
On 13 January 2011 11:09, Achilleas Margaritis wrote:
> On Wed, Jan 12, 2011 at 6:16 PM, David Brown wrote:
>>
>> I can see how such a feature could be useful, but is there any reason why it
>> should be part of gcc, rather than a separate program that takes a cpp file
>> and generates an hpp file
On Wed, Jan 12, 2011 at 6:16 PM, David Brown wrote:
> On 12/01/2011 16:22, Achilleas Margaritis wrote:
>>
>> Hello all.
>>
>> I have a idea for automatic generation of headers in a c++ program.
>> Having to maintain headers is a very time consuming task, and I think
>> we will all benefit from suc
Achilleas Margaritis writes:
> I have a idea for automatic generation of headers in a c++ program.
> Having to maintain headers is a very time consuming task, and I think
> we will all benefit from such a thing. The idea is the following:
>
> Each time the compiler finds the pragma
>
> #pragma au
On 12/01/2011 16:22, Achilleas Margaritis wrote:
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds th
48 matches
Mail list logo
