Re: [DynInst_API:] RFC: parseAPI interface change

["E.Robbins" <er209@xxxxxxxxxx>]

Hi Bill,
I am currently using random-access on blocklists. I can't remember the use case, but I can probably change the code at my end, I'll need to look at the code and get back to you on Monday.

Thanks,
Ed

________________________________________
From: Dyninst-api [dyninst-api-bounces@xxxxxxxxxxx] on behalf of Bill Williams [bill@xxxxxxxxxxx]
Sent: 16 May 2014 20:53
To: paradyn-staff; dyninst-api@xxxxxxxxxxx
Subject: [DynInst_API:] RFC: parseAPI interface change

ParseAPI's Function class has a blocklist typedef that, at present,
translates to a vector<Block*>. This vector results in some unfortunate
data duplication; I'd like to both avoid storing it and avoid generating
it when a user calls the blocks() method. There are a few ways to do
this, but all of them center around making a blocklist no longer be
random-access: you would lose the ability to call blocks()[n]. blocks()
would still provide a sorted range interface (begin, end, in-order
iteration).

Question 1: Is anyone actively relying on the vector nature of
blocklists, either because they're manually resolving the typedef (in
which case you are bad people and should feel bad) or because they're
treating random-access iteration as a defined part of the interface? If
so, can you explain a bit about your use case?

Question 2: I believe I can either make the primary container of blocks
be the Address->Block* map that currently exists, or a set of Block*
(with a bit of cleverness to make map-style lookup work internally).
Mostly for paradyn-staff: any preferences as to whether we fake an index
on a set or project a map down to look set-like?

--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api