js/public/Vector.h

Tue, 06 Jan 2015 21:39:09 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Tue, 06 Jan 2015 21:39:09 +0100
branch
TOR_BUG_9701
changeset 8
97036ab72558
permissions
-rw-r--r--

Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.

     1 /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
     2  * vim: set ts=8 sts=4 et sw=4 tw=99:
     3  * This Source Code Form is subject to the terms of the Mozilla Public
     4  * License, v. 2.0. If a copy of the MPL was not distributed with this
     5  * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
     7 #ifndef js_Vector_h
     8 #define js_Vector_h
    10 #include "mozilla/Vector.h"
    12 /* Silence dire "bugs in previous versions of MSVC have been fixed" warnings */
    13 #ifdef _MSC_VER
    14 #pragma warning(push)
    15 #pragma warning(disable:4345)
    16 #endif
    18 namespace js {
    20 class TempAllocPolicy;
    22 // If we had C++11 template aliases, we could just use this:
    23 //
    24 //   template <typename T,
    25 //             size_t MinInlineCapacity = 0,
    26 //             class AllocPolicy = TempAllocPolicy>
    27 //   using Vector = mozilla::Vector<T, MinInlineCapacity, AllocPolicy>;
    28 //
    29 // ...and get rid of all the CRTP madness in mozilla::Vector(Base).  But we
    30 // can't because compiler support's not up to snuff.  (Template aliases are in
    31 // gcc 4.7 and clang 3.0 and are expected to be in MSVC 2013.)  Instead, have a
    32 // completely separate class inheriting from mozilla::Vector, and throw CRTP at
    33 // the problem til things work.
    34 //
    35 // This workaround presents a couple issues.  First, because js::Vector is a
    36 // distinct type from mozilla::Vector, overload resolution, method calls, etc.
    37 // are affected.  *Hopefully* this won't be too bad in practice.  (A bunch of
    38 // places had to be fixed when mozilla::Vector was introduced, but it wasn't a
    39 // crazy number.)  Second, mozilla::Vector's interface has to be made subclass-
    40 // ready via CRTP -- or rather, via mozilla::VectorBase, which basically no one
    41 // should use.  :-)  Third, we have to redefine the constructors and the non-
    42 // inherited operators.  Blech.  Happily there aren't too many of these, so it
    43 // isn't the end of the world.
    45 template <typename T,
    46           size_t MinInlineCapacity = 0,
    47           class AllocPolicy = TempAllocPolicy>
    48 class Vector
    49   : public mozilla::VectorBase<T,
    50                                MinInlineCapacity,
    51                                AllocPolicy,
    52                                Vector<T, MinInlineCapacity, AllocPolicy> >
    53 {
    54     typedef typename mozilla::VectorBase<T, MinInlineCapacity, AllocPolicy, Vector> Base;
    56   public:
    57     Vector(AllocPolicy alloc = AllocPolicy()) : Base(alloc) {}
    58     Vector(Vector &&vec) : Base(mozilla::Move(vec)) {}
    59     Vector &operator=(Vector &&vec) {
    60         return Base::operator=(mozilla::Move(vec));
    61     }
    62 };
    64 } // namespace js
    66 #endif /* js_Vector_h */

mercurial