Subject: RE: Poll on ISSUE 1.7
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Mon Dec 02 2002 - 16:46:43 PST
I'd prefer option "c" too.
-- John A.
Warmke, Doug wrote:
> Team,
>
> We need a vote on this issue.
> Swapnajit, can you please organize it?
>
> As I stated in my original mail, we need to get consensus
> on the style we will use when defining the C side.
> That way we stay focused on work and won't get
> sidetracked into controversial philosophy debates.
>
> Of course, I vote for c).
>
> Thanks and regards,
> Doug
>
> Michael Rohleder wrote:
>
>> Hi all,
>>
>> This is just a trial for a short email poll. I have the feeling, this
is
>> something we can close easily.
>> According to Doug there are three options:
>> a) Use system currently in place in DirectC. (Andrzej recommends).
>> b) All access is done through API functions. Different #define or -D
>> could be used to specify an optimization level. (Michael
recommends).
>> c) Use combination of direct and abstract modes, but with no
redundancy.
>> (Doug recommends)
>>
>> I see some motion towards option c), which means *We Remove "A" |
"C".*
>>
>> Is there any agreement/disagreement on this? This might save us some
>> minutes in the next call, hopefully ... Please note that this is
fully
>> separated from the context discussion.
>>
>> -Michael
>>
>>
>> "Stickley, John" wrote:
>> ...
>>
>> > *With Solution 3) Can We Remove "A" | "C" ?*
>> >
>> > I'm not too keen on always requiring pre-processed wrapper macros
or
>> > other cumbersome functions if all the user wants to do is fetch
values
>> > of simple
>> > scalar data types.
>> >
>> > The main purpose of abstract access should be only for access of
more
>> > complex
>> > abstract data types as Doug described in solution 3) of in his
e-mail.
>> > Simple
>> > scalar direct types should be accessed directly (hence the name !)
for
>> > all reasons
>> > stated by Doug below.
>> >
>> > And as Michael pointed out, the debug/error check handling should
be
>> > considered
>> > orthogonal to the access mechanism by making it a transparent
run-time
>> > option.
>> >
>> > A corrollary to this then, is that we can probably get rid of the
"A"
>> > | "C"
>> > specifiers in both the extern and the export declarations.
>> >
>
This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 16:47:30 PST