Some classes directly call global operator new to reserve space in
addition to the space the class will occupy. These clases must be
deleted with the unsized global operator new. If a build is configured
such that sized global operator new is called from a delete expression,
this must be overridden by such classes.
TBR=reed
Only affects private bits of SkData.
Change-Id: I797935db17a37aa8c2ca7b562a4ea65a7978a9f0
Reviewed-on: https://skia-review.googlesource.com/3678
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This also removes the class operator new override along with
directly calling malloc in SkData, since it has a similar requirements.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot;master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN-Trybot
Change-Id: Ic68aacf2028d6964d9735a55558862afc9edd19b
Reviewed-on: https://skia-review.googlesource.com/3541
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.
Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
Review-Url: https://codereview.chromium.org/2232433002
The code protected by this flag is no longer used. Remove the flag and
code. This also removes SK_SUPPORT_LEGACY_TYPEFACE_PTR from Android, as
it is no longer needed.
TBR=reed
Only removes already guarded API.
Review-Url: https://codereview.chromium.org/2223933002
In order to remove this define it will first need to be defined in
Chromium. However, doing so causes redefinition warnings as errors.
Only define this macro if it is not already defined to avoid this.
TBR=reed
This doesn't change any API.
Review-Url: https://codereview.chromium.org/2198453002
Function- or method- local scope isn't threadsafe; the pointer is generally
zero-initialized on first use in function scope (i.e. lazily... we have to go
deeper), but for globals we can be pretty sure the linker will do that for us.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/651723003
SK_DECLARE_STATIC_LAZY_PTR and
SK_DECLARE_STATIC_LAZY_PTR_ARRAY let you declare a single or
array of static pointers that are lazily initialized.
You can think of this as a restricted, lighter-weight
version of SkOnce. There's no guarantee that Create will be
called exactly once, but we do guarantee all threads will
agree on the resulting pointer.
We'll clean up any other extra pointers we Create()ed by
calling Destroy(), which defaults to SkDELETE. In debug
mode, we also clean up the winning pointer at process exit,
so we can make sure we didn't leak it or free it early.
I've ported SkData (singleton) and SkXfermode (array) as
examples. Once this lands I'll port most other users of
SkOnce.
BUG=skia:
R=bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/306943003
git-svn-id: http://skia.googlecode.com/svn/trunk@14976 2bbb7eff-a529-9590-31e7-b0007b416f81
https://codereview.chromium.org/13925021/
If a non-POD class does not provide a default destructor, one is
provided by teh compiler. GCC will do so, but only at the point where the
vtable is output; since BlockRef has no implementation its destructor is
never output, so there is no complaint. VC++, however, provides the
destructor implementation as soon as it sees the type. If the destructor
of BlockRef is ever defined an error will be reported (since the
destructor of SkData is private).
Declaring (but does not defining) a destructor for BlockRef fixes two
issues. First, it prevents a default destructor from being provided,
removing the VC++ error. Second, BlockRef now blocks access to the
destructor through '->'.
git-svn-id: http://skia.googlecode.com/svn/trunk@8697 2bbb7eff-a529-9590-31e7-b0007b416f81
I have manually examined all of these diffs and restored a few files that
seem to require manual adjustment.
The following files still need to be modified manually, in a separate CL:
android_sample/SampleApp/AndroidManifest.xml
android_sample/SampleApp/res/layout/layout.xml
android_sample/SampleApp/res/menu/sample.xml
android_sample/SampleApp/res/values/strings.xml
android_sample/SampleApp/src/com/skia/sampleapp/SampleApp.java
android_sample/SampleApp/src/com/skia/sampleapp/SampleView.java
experimental/CiCarbonSampleMain.c
experimental/CocoaDebugger/main.m
experimental/FileReaderApp/main.m
experimental/SimpleCocoaApp/main.m
experimental/iOSSampleApp/Shared/SkAlertPrompt.h
experimental/iOSSampleApp/Shared/SkAlertPrompt.m
experimental/iOSSampleApp/SkiOSSampleApp-Base.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Debug.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Release.xcconfig
gpu/src/android/GrGLDefaultInterface_android.cpp
gyp/common.gypi
gyp_skia
include/ports/SkHarfBuzzFont.h
include/views/SkOSWindow_wxwidgets.h
make.bat
make.py
src/opts/memset.arm.S
src/opts/memset16_neon.S
src/opts/memset32_neon.S
src/opts/opts_check_arm.cpp
src/ports/SkDebug_brew.cpp
src/ports/SkMemory_brew.cpp
src/ports/SkOSFile_brew.cpp
src/ports/SkXMLParser_empty.cpp
src/utils/ios/SkImageDecoder_iOS.mm
src/utils/ios/SkOSFile_iOS.mm
src/utils/ios/SkStream_NSData.mm
tests/FillPathTest.cpp
Review URL: http://codereview.appspot.com/4816058
git-svn-id: http://skia.googlecode.com/svn/trunk@1982 2bbb7eff-a529-9590-31e7-b0007b416f81
