On 12/06/2012 07:51 PM, Thorsten Behrens wrote:
For large parts of UNO, making one not violate the exception
specification, would look like this:
try {
} catch(...) {
throw uno::RuntimeException("Arrgh! General $FOO error!!1!");
}
That is not what I would call error handling.
B
Lubos Lunak wrote:
> > - rtl::OUString
> > + OUString
>
> You cannot compare these with exception specifications. The examples above,
> barring very corner cases, are only about readability and nothing else, while
> exception specifications are not. Arguing that we should remove exception
On Monday 03 of December 2012, Michael Meeks wrote:
> On Fri, 2012-11-30 at 18:53 +0100, Lubos Lunak wrote:
> > On Friday 30 of November 2012, Stephan Bergmann wrote:
> > > I'm not sure this is a good move.
>
> ...
>
> > > Which leaves us with the benefit of shorter, less visually cluttered
> > > d
Hi Thorsten,
Thorsten Behrens píše v Po 03. 12. 2012 v 12:53 +0100:
> > Based on the discussion on the IRC, I've used 'lo::' in the patch,
> > instead of the too generic 'api::'.
>
> For the record, I don't like lo. First, it is redundant
> ("LibreOffice, well sure, I knew what I was git-cloning!
Jan Holesovsky wrote:
> Based on the discussion on the IRC, I've used 'lo::' in the patch,
> instead of the too generic 'api::'.
>
For the record, I don't like lo. First, it is redundant
("LibreOffice, well sure, I knew what I was git-cloning!!1!"),
second, it is too close to this colloquial Englis
Hi all,
Michael Meeks píše v Po 03. 12. 2012 v 10:00 +:
> > Well, that needs some amount of explanation, too, since the nested
> > namespace is still there, and needs to be used when implementing an
> > interface.
>
> Well - IMHO it's far easier to explain 'api' on an ongoing basis t
On 12/03/2012 04:53 AM, Noel Grandin wrote:
Sunday, 2 December 2012, Michael Stahl wrote:
what i'd really like to have though is a C++ keyword with semantics
of "just use the same
exception specification as the base class method" ... plus "error if
there is not actually a base cl
On 12/02/2012 09:03 PM, Michael Stahl wrote:
so... following the above reasoning i have just re-enabled the exception
specifications with eb0cfb3bf220892e4885945452930790f5e22000; they are
written only in an --enable-dbgutil build.
what is still missing then is a macro for use in the API impleme
On 12/03/2012 10:53 AM, Michael Meeks wrote:
On Fri, 2012-11-30 at 18:53 +0100, Lubos Lunak wrote:
On Friday 30 of November 2012, Stephan Bergmann wrote:
I'm not sure this is a good move.
...
Which leaves us with the benefit of shorter, less visually cluttered
declarations of C++ functions.
On 03/12/12 10:32, Jan Holesovsky wrote:
> Hi Thorsten, Stephan,
>
> Thorsten Behrens píše v Pá 30. 11. 2012 v 17:23 +0100:
>
using namespace com::sun::star would save some 5 additional
characters - let me see what a test build yields...
>>>
>>> ...but would increase potential for ambig
On Mon, 2012-12-03 at 10:39 +0100, Thorsten Behrens wrote:
> Jan Holesovsky wrote:
> > Please _please_ PLEASE name it "api" as you proposed first, not "css" -
> > it nearly killed me when I found out what that means when I started with
> > OOo [that it is not "cascade style sheet", but "com::sun::
On Fri, 2012-11-30 at 18:53 +0100, Lubos Lunak wrote:
> On Friday 30 of November 2012, Stephan Bergmann wrote:
> > I'm not sure this is a good move.
...
> > Which leaves us with the benefit of shorter, less visually cluttered
> > declarations of C++ functions. But, as I argue above, I am not sure
On 12/03/2012 10:32 AM, Jan Holesovsky wrote:
using namespace com::sun::star would save some 5 additional
characters - let me see what a test build yields...
...but would increase potential for ambiguities.
Yes, so I went for the css alias in the end. This change has been
pushed to master.
Jan Holesovsky wrote:
> Please _please_ PLEASE name it "api" as you proposed first, not "css" -
> it nearly killed me when I found out what that means when I started with
> OOo [that it is not "cascade style sheet", but "com::sun::star"] - think
> of the newcomers ;-)
>
Well, that needs some amoun
Hi Thorsten, Stephan,
Thorsten Behrens píše v Pá 30. 11. 2012 v 17:23 +0100:
> > >using namespace com::sun::star would save some 5 additional
> > >characters - let me see what a test build yields...
> >
> > ...but would increase potential for ambiguities.
> >
> Yes, so I went for the css alias
On 2012-12-02 22:03, Michael Stahl wrote:
... what i'd really like to have though is a C++ keyword plus "error
if there is not actually a base class method with that parameter
signature"
Here we go,
http://stackoverflow.com/questions/497630/safely-override-c-virtual-functions
there is a new C
Sunday, 2 December 2012, Michael Stahl wrote:
>
> what i'd really like to have though is a C++ keyword with semantics of
> "just use the same
> exception specification as the base class method" ... plus "error if
> there is not actually a base class method with that parameter
> signature", while we
On 30/11/12 18:53, Lubos Lunak wrote:
> On Friday 30 of November 2012, Stephan Bergmann wrote:
>> On 11/29/2012 06:42 PM, Thorsten Behrens wrote:
>>> With SAL_THROW & exception specs on api headers removed, there's a
>>> very nice & substantial cleanup task possible subsequently, that
>>> removes i
On Friday 30 of November 2012, Stephan Bergmann wrote:
> On 11/29/2012 06:42 PM, Thorsten Behrens wrote:
> > With SAL_THROW & exception specs on api headers removed, there's a
> > very nice & substantial cleanup task possible subsequently, that
> > removes it from all implementation methods, too.
>
Stephan Bergmann wrote:
> >using namespace com::sun::star would save some 5 additional
> >characters - let me see what a test build yields...
>
> ...but would increase potential for ambiguities.
>
Yes, so I went for the css alias in the end. This change has been
pushed to master.
Cheers,
-- Tho
On 11/29/2012 06:42 PM, Thorsten Behrens wrote:
Stephan Bergmann wrote:
Right, forgot about the Clang case. So that would mean keeping
SAL_THROW non-deprecated, making it a nop with Clang
--disable-dbgutil (but making it a non-nop for GCC generally), and
changing the cppumaker-generated headers
On 11/29/2012 06:44 PM, Thorsten Behrens wrote:
Stephan Bergmann wrote:
* a bit more extreme - kill ::com::sun::star inside office code, by
having a ~global "using namespace ::com::sun::star;" or
"namespace api = ::com::sun::star;" in e.g. sal/config.h, and
writing only _that_ out
Stephan Bergmann wrote:
> > * should we kill [oneway] in IDL while at it? IIRC it went away in
> >the bridges anyway, via i#116038 or didn't it?
>
> Yes, [oneway] is effectively completely dead by now (compared to
> almost dead before the binary URP rewrite).
>
Killing in progress.
> > * a
Stephan Bergmann wrote:
> Right, forgot about the Clang case. So that would mean keeping
> SAL_THROW non-deprecated, making it a nop with Clang
> --disable-dbgutil (but making it a non-nop for GCC generally), and
> changing the cppumaker-generated headers to use SAL_THROW.
>
So the change meanwhi
On Thursday 29 of November 2012, Michael Stahl wrote:
> also iirc LLVM/clang has no option similar to -fno-enfore-eh-specs, i.e.
> it always enforces exception specifications, so if we were to use that
> for product builds (no i am not proposing that :) ), we'd need to not
> generate the throw in c
On 11/29/2012 02:16 PM, Michael Stahl wrote:
On 29/11/12 14:05, Stephan Bergmann wrote:
On 11/29/2012 12:37 PM, Michael Stahl wrote:
On 29/11/12 01:54, Thorsten Behrens wrote:
* cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
writing out exception specs
iirc we want to
On 29/11/12 14:05, Stephan Bergmann wrote:
> On 11/29/2012 12:37 PM, Michael Stahl wrote:
>> On 29/11/12 01:54, Thorsten Behrens wrote:
>>> * cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
>>> writing out exception specs
>>
>> iirc we want to remove C++ exception specification
On 11/29/2012 12:37 PM, Michael Stahl wrote:
On 29/11/12 01:54, Thorsten Behrens wrote:
* cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
writing out exception specs
iirc we want to remove C++ exception specifications for production code
because they don't make sense there
On 11/29/2012 01:54 AM, Thorsten Behrens wrote:
ploughing through offapi & cppumaker (the tool that generates the
c++ headers), and so far did this:
* unpublished accessibility API
* renamed XAccessibleEventListener methods
* cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
On 29/11/12 01:54, Thorsten Behrens wrote:
> Hi there,
>
> ploughing through offapi & cppumaker (the tool that generates the
> c++ headers), and so far did this:
>
> * unpublished accessibility API
> * renamed XAccessibleEventListener methods
great
> * cleansed cppumaker of dead code, RTL_CO
Hi there,
ploughing through offapi & cppumaker (the tool that generates the
c++ headers), and so far did this:
* unpublished accessibility API
* renamed XAccessibleEventListener methods
* cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
writing out exception specs
There remai
31 matches
Mail list logo
