GCC 8 reminds us, don't memcpy() sk_sp
../../include/private/SkTArray.h:496:15:
error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type
‘class sk_sp<GrTextBlob>’ with no trivial copy-assignment; use copy-assignment
or copy-initialization instead [-Werror=class-memaccess]
memcpy(&fItemArray[dst], &fItemArray[src], sizeof(T));
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This may be safe in context and the sort of thing we're used to getting
away with, but I think it's probably also the sort of thing we should
try to do as little as possible.
If this is really a major performance choke point, it might make sense
to going back to an array of raw pointers? That's what we had back
before https://skia-review.googlesource.com/c/skia/+/9535/.
Change-Id: If16918f908e8950b81e73b70764bae200bda2e62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258265
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
diff --git a/src/gpu/text/GrTextBlobCache.h b/src/gpu/text/GrTextBlobCache.h
index 1484cee..90046c7 100644
--- a/src/gpu/text/GrTextBlobCache.h
+++ b/src/gpu/text/GrTextBlobCache.h
@@ -161,10 +161,10 @@
return -1;
}
- uint32_t fID;
+ uint32_t fID;
// Current clients don't generate multiple GrAtlasTextBlobs per SkTextBlob, so an array w/
// linear search is acceptable. If usage changes, we should re-evaluate this structure.
- SkSTArray<1, sk_sp<GrTextBlob>, true> fBlobs;
+ SkSTArray<1, sk_sp<GrTextBlob>> fBlobs;
};
void add(sk_sp<GrTextBlob> blob) {
