> 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
>> 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 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
> 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 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
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
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 prop
>> 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 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 functi
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 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 t
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
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
> a
>> 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
>> 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 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
>>>
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
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 the pragma
#pragma autoinclude("foo.hpp")
it does t
20 matches
Mail list logo
