In Message-ID: <[EMAIL PROTECTED]>
Stephan Bergmann <[EMAIL PROTECTED]> wrote:
> 3 WE NEED YOU!
>
> Here at Hamburg, we will only concentrate on those platforms we build
> ourselves. Also, due to the fact that our build environment is slightly
> different from a typical OOo build environment
Hi Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Propagating errors is the broader concept, comparing assertions and
error propagation. So, if in doubt, propagate! Never swallow unclear
situations (especially _not_ in _production_ code, following effects may
destroy valua
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
At OSL_DEBUG_LEVEL == 0,
OSL_VERIFY(callFoo(bar) == good);
is just
((void)(callFoo(bar) == good);
which you also trust the compiler to simplify.
Honestly: no, I wouldn't.
Huh? I assume you do use OSL_VERIFY. So you ei
Hi Kay,
> Propagating errors is the broader concept, comparing assertions and
> error propagation. So, if in doubt, propagate! Never swallow unclear
> situations (especially _not_ in _production_ code, following effects may
> destroy valuable data), upper levels may know what to do or at least
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Just some (selected :-) examples:
case PROPERTY_ID_REFVALUE :
147 OSL_VERIFY( _rValue >>= m_sReferenceValue );
148 calcValueExchangeType();
149 break;
150
151 case PROPERTY_ID_UNCHECKED_REFVALU
Hi Stephan,
> At OSL_DEBUG_LEVEL == 0,
>
>OSL_VERIFY(callFoo(bar) == good);
>
> is just
>
>((void)(callFoo(bar) == good);
>
> which you also trust the compiler to simplify.
Honestly: no, I wouldn't. I would have expected that this is simply
expanded to
callFoo(bar) == good
There's p
Joerg,
Joerg Barfurth wrote:
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
I agree. If they signal runtime conditions that prevent normal
operations, they can be converted to exceptions, otherwise they should
be dealt with or propagated as approriate. (I think i
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
It is the very purpose of OSL_VERIFY to evaluate the expression
regardless of debug level. For expressions without side effect
OSL_ASSERT/OSL_ENSURE should be used instead.
It is used to avoid cluttering the code with extra
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
As I wrote before, I think
if (!callSomeFooWhichSignalsSuccess(bar)) {
OSL_ENSURE(false, "this was expected to succeed!");
}
is the better alternative to the OSL_VERIFY above, as it does not
violate the Principle of Least
Hello!
Does somebody know, which RTF-Version OpenOffice.org 2.0 use? Is it 1.6
or 1.7?
Greetings
Alexander Peters
Hi Stephan,
> As I wrote before, I think
>
>if (!callSomeFooWhichSignalsSuccess(bar)) {
> OSL_ENSURE(false, "this was expected to succeed!");
>}
>
> is the better alternative to the OSL_VERIFY above, as it does not
> violate the Principle of Least Surprise (and helps get rid of a s
Hi Philipp,
>>I definately think that
>> OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) );
>>is the better (non-weird) alternative here.
>
> That case is weird, because you choose to ignore the return value. In
> that you create a possibly not easy to find error. Ignoring return
> values is
Joerg Barfurth wrote:
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would
expect that only weird code would relay on the evaluation in case of a
zero debug level. An
Philipp Lohmann - Sun Germany wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Philipp Lohmann - Sun Germany wrote:
Can I interpretate this in a way, you to be willing to join our
diagnose and debug macro consolidation meeting?! So, watch out for an
event notification for sometime next week :-
Kay Ramme - Sun Germany - Hamburg wrote:
Philipp Lohmann - Sun Germany wrote:
Can I interpretate this in a way, you to be willing to join our diagnose
and debug macro consolidation meeting?! So, watch out for an event
notification for sometime next week :-)
Very good, that will test the vacat
Stephan Bergmann wrote:
3 OSL_VERIFY
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding un
Philipp Lohmann - Sun Germany wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would
expect that only weird code would relay on the evaluation in case
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in case of a zero
debug level. And these case can probab
Hi Philipp,
Philipp Lohmann - Sun Germany wrote:
I definately think that
OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) );
is the better (non-weird) alternative here.
That case is weird, because you choose to ignore the return value. In
that you create a possibly not easy to find erro
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in case of a zero
debug level.
Why "weird"?
Hi Kay,
>>Oh, while we're at it, let me throw in one of my favourites: Shouldn't
>>we consolidate the DBG_* and OSL_* diagnostics macros?
> YES, YES, YES. May be you have some time the next weeks, to dive into
> more details?
Count me in. The current inconsistencies suck^Ware cumbersome and
anno
Ken Foskey wrote:
On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote:
Warning free code is a basic precondition for robust industrial quality
code. This as well is current scientific knowledge as the result of the
personal experience of Hamburg-internal engineers, as well as the
opini
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in case of a zero
debug level.
Why "weird"?
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in case of a zero
debug level.
Why "weird"?
On 8/31/05, Carsten Driesner <[EMAIL PROTECTED]> wrote:
>
>
> If you want to try the hard way, please let me know and I will give a
> summary how you can do it.
>
>
That would be great as I'm currently evaluating different implementation
options for one of our projects.
Matthias
Jens-Heiner Rechtien wrote:
Speaking of STLPort: It seems that these incredible number of
ANACHRONISM warnings regarding missing typenames on unxsols4 and
unxsoli4 can be fixed with a single line of change in STLPort. I'll
suggest that we fix this one in another CWS which has a chance to get in
Hi,
sorry, could not resist...
>>Sorry for the (may be stupid) question, but why not just change
>>OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
>>that only weird code would relay on the evaluation in case of a zero
>>debug level.
>
> Why "weird"? The alternative is
Stephan,
Stephan Bergmann wrote:
Maybe we could, but *not* on CWS warnings01. We already have enough to
do here to get rid of all warnings. If we take the burden of any
additional clean up (like unifying OSL_ENSURE and OSL_ASSERT) that is
not directly necessary to get rid of warnings, we
Hi Kay,
> Sorry for the (may be stupid) question, but why not just change
> OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
> that only weird code would relay on the evaluation in case of a zero
> debug level.
Why "weird"? The alternative is something like
#if OSL_DE
Kay Ramme - Sun Germany - Hamburg wrote:
Stephan Bergmann wrote:
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of d
Speaking of STLPort: It seems that these incredible number of
ANACHRONISM warnings regarding missing typenames on unxsols4 and
unxsoli4 can be fixed with a single line of change in STLPort. I'll
suggest that we fix this one in another CWS which has a chance to get in
OOo 2.0, if Martin agrees.
Matthias Benkmann wrote:
I'd like to know if the new "programmatic control of menu and toolbar items"
feature will allow me to create a custom ComboBox in a toolbar. Thanks.
Hi Matthias,
I think it's possible, but there is no easy way to do it. We plan to
implement an easy way for the next ma
Stephan Bergmann wrote:
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding unxsoli4 and unx
33 matches
Mail list logo
