felipecrv commented on issue #34535:
URL: https://github.com/apache/arrow/issues/34535#issuecomment-1966755978
> towards compile times
Not primarily, binary size is the primary concern. As it is now, we don't
have to inline the `ChunkResolver` constructors, for instance.
> In that case, we can have the Resolve method be templated rather than the
entire class
You can have crashes if the user passes the wrong type parameter to the
method call and in your solution, you're adding
`std::vector<std::shared_ptr<Array>> chunks_;` to the list of members.
There is a way here based on **composition** that you will probably like. We
can bring most of `chunked_internal.h` to here (or a different header that
includes `chunk_resolver.h`) but improve on the design as it will now become
public.
I recommend you to do that **on a separate PR** as `chunked_internal.h` is
much more dependent on other internal stuff.
```cpp
template <typename ArrayType = std::shared_ptr<Array>>
class ArrayChunkResolver {
public:
using ArrayPtr = /* template thingie that gives you the raw-est pointer
type from `ArrayType` */;
private:
ChunkResolver _resolver; // owns a vector of chunk offsets and assumes
chunk sizes are immutable
std::vector<ArrayType> &chunks_; // the resolver doesn't own the vector
of chunks
public:
// ctor, move-ctor, and move-assign.
inline ArrayPtr Resolve(int64_t index) const;
inline ChunkLocation ResolveLocation(int64_t index) const; //
delegate to _resolver
inline ChunkLocation ResolveLocationWithHint(ChunkLocation
hint) const; // delegate to _resolver
};
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
