On Thu, Aug 08, 2013 at 08:15:29PM -0700, Brian Smith wrote:
> On Thu, Aug 8, 2013 at 3:57 PM, Ehsan Akhgari wrote:
>
> > On 2013-08-08 11:34 AM, Brian Smith wrote:
> >
> >> My position is that we should fix STLPort's implementation
> >> for GCC 4.4 ARM Linux (maybe just backport a fixed version)
On Thu, Aug 8, 2013 at 3:57 PM, Ehsan Akhgari wrote:
> On 2013-08-08 11:34 AM, Brian Smith wrote:
>
>> My position is that we should fix STLPort's implementation
>> for GCC 4.4 ARM Linux (maybe just backport a fixed version) and use
>> std::type_traits everywhere.
>>
>> Now that I know we can modi
On 2013-08-08 11:34 AM, Brian Smith wrote:
On Wed, Aug 7, 2013 at 6:47 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:
But for whatever it's worth, I think that in general, for the std
replacement code living in MFBT, it's best for us to try really hard
to match the C++ sta
On Wed, Aug 7, 2013 at 6:47 PM, Ehsan Akhgari wrote:
> But for whatever it's worth, I think that in general, for the std
> replacement code living in MFBT, it's best for us to try really hard to
> match the C++ standard where it makes sense. We sometimes go through a
> crazy amount of pain to do
On Wed, Aug 7, 2013 at 6:47 PM, Ehsan Akhgari wrote:
> (Sorry for the late reply, please blame it on Canadian statutory holidays,
> and my birthday date!)
>
Happy birthday!
On Fri, Aug 2, 2013 at 11:09 PM, Brian Smith wrote:
>
>> 1. It avoids a phase of mass rewrites s/mozilla:Whatever/std::wha
(Sorry for the late reply, please blame it on Canadian statutory holidays,
and my birthday date!)
On Fri, Aug 2, 2013 at 11:09 PM, Brian Smith wrote:
> On Sat, Aug 3, 2013 at 12:47 AM, Ehsan Akhgari wrote:
>
>> On 2013-08-02 5:21 PM, Brian Smith wrote:
>>
>>> 3. How should we handle bridge suppo
On 08/02/2013 08:09 PM, Brian Smith wrote:
> 2. It is reasonable to expect that std::whatever works as the C++ standard
> says it should. It isn't reasonable to expect mozilla::Whatever to work
> exactly like std::whatever. And, often, mozilla::Whatever isn't actually
> the same as std::whatever.
On 8/2/2013 10:09 PM, Brian Smith wrote:
2. It is reasonable to expect that std::whatever works as the C++
standard says it should. It isn't reasonable to expect
mozilla::Whatever to work exactly like std::whatever. And, often,
mozilla::Whatever isn't actually the same as std::whatever
Judgin
On 8/2/2013 4:21 PM, Brian Smith wrote:
For purposes of discussion, I think it's worth breaking down the C++ (and
C) standard library into the following components:
* Containers--vector, map, etc.
* Strings
* I/O
* Platform support (threading, networking, filesystems, locales)
* Other helpful uti
On Sat, Aug 3, 2013 at 12:47 AM, Ehsan Akhgari wrote:
> On 2013-08-02 5:21 PM, Brian Smith wrote:
>
>> 3. How should we handle bridge support for standardized features not yet
>>> universally-implemented?
>>>
>>>
>> Generally, I would much rather we implement std::whatever ourselves than
>> implem
On Fri, Aug 02, 2013 at 02:44:57PM -0700, Justin Lebar wrote:
> > I agree that iostream-based logging would be safer. If we had it I
> > wouldn't have had to work on this one:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=855335
>
> I can't access that bug, but maybe you mean
> https://bug
On Fri, Aug 02, 2013 at 06:47:08PM -0400, Ehsan Akhgari wrote:
> On 2013-08-02 5:21 PM, Brian Smith wrote:
> >>3. How should we handle bridge support for standardized features not yet
> >>universally-implemented?
> >>
> >
> >Generally, I would much rather we implement std::whatever ourselves than
>
It was brought to my attention that it's unclear what I'm looking for in
this conversation, so let me try to summarize. I am not convinced that
there is something wrong with the way that things currently work (polyfill
where the feature is not available everywhere, else use it if
appropriate). I'
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement mozilla::Whatever, all other things being equal.
Yes, but it's still
Sorry I should've noticed that 855335 is a sec-bug. It's title is "Audit
SIPCC printf-style format strings" which means we went through every
logging call and repaired a few which had incorrect printf-style args.
-EH
On Fri, Aug 2, 2013 at 2:44 PM, Justin Lebar wrote:
> > I agree that iostr
> I agree that iostream-based logging would be safer. If we had it I
> wouldn't have had to work on this one:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ?
I feel like the goals there a
>It is very useful for building a logging interface that is safer and more
>convenient than NSPR's printf-style logging. Note that, again, Eric
>Rescorla already built an (partial) iostream-based wrapper around NSPR for
>WebRTC. I would say that, if there is no additional overhead, then we
>should
On Wed, Jul 31, 2013 at 7:41 PM, Joshua Cranmer 🐧 wrote:
> implementation, libc++, libstdc++, and stlport. Since most nice charts of
> C++11 compatibility focus on what the compiler needs to do, I've put
> together a high-level overview of the major additions to the standard
> library [3]:
> * std
Neil wrote:
Joshua Cranmer 🐧 wrote:
On 7/31/2013 9:19 PM, Mike Hommey wrote:
Now think of all those NS_LITERAL_STRING() and other horrible
boilerplate we have.
... and my next target is s/PRUnichar/char16_t/, the last step of
which basically amounts to killing NS_LITERAL_STRING. :-)
Wil
Another example of a project that extends or reimplements much of the STL to
suit the developer's needs, which might provide inspiration here, is 'nall' by
byuu, author of the emulation platform higan. Though the library itself is
poorly documented, it is heavily based on C++11 and byuu has a te
Joshua Cranmer 🐧 wrote:
On 7/31/2013 9:19 PM, Mike Hommey wrote:
Now think of all those NS_LITERAL_STRING() and other horrible
boilerplate we have.
... and my next target is s/PRUnichar/char16_t/, the last step of
which basically amounts to killing NS_LITERAL_STRING. :-)
Will that include
On Wed, Jul 31, 2013 at 3:22 PM, Joshua Cranmer 🐧 wrote:
> We also have needs like
> sizeOfIncludingThis/sizeOfExcludingThis that can't be as easily satisfied
> with STL code.
This is, unsurprisingly, a requirement that's close to my heart. We
actually have a few instances of std:: classes alrea
On 7/31/2013 9:19 PM, Mike Hommey wrote:
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
Thoughts/comments/corrections/questions/concerns/flames/insightful
discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step ba
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
> Thoughts/comments/corrections/questions/concerns/flames/insightful
> discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step back and start by defining what we
want to
On 7/31/2013 2:38 PM, Justin Lebar wrote:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
We've tuned tarray, nsthashtable, strings, etc. to meet our precise
needs, and the implementations are consistent across all platforms.
I can imagine things be
On 7/31/2013 2:08 PM, Ehsan Akhgari wrote:
On 2013-07-31 1:41 PM, Joshua Cranmer 🐧 wrote:
With all of that stated, the questions I want to pose to the community
at large are as follows:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
I'm not sure
> 1. How much, and where, should we be using standard C++ library
> functionality in Mozilla code?
We've tuned tarray, nsthashtable, strings, etc. to meet our precise
needs, and the implementations are consistent across all platforms.
I can imagine things becoming quite messy we had three or four
On 2013-07-31 1:41 PM, Joshua Cranmer 🐧 wrote:
With all of that stated, the questions I want to pose to the community
at large are as follows:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
I'm not sure if it's easy to have this discussion in gene
tl;dr - I ask some questions near the end, you probably need to read the
entire post to be able to insightfully answer them.
The Mozilla codebase, which I define loosely as mozilla-central,
comm-central, JS, NSS, NSPR, LDAP C SDKs, and any other small project
included in mozilla-central that i
29 matches
Mail list logo
