On Fri, Feb 7, 2014 at 12:28 PM, Tom Browder wrote:
> No argument there! Ideas welcome!. But I'm actually moving toward a
> consolidation of such conversions into a more general function--maybe
My thoughts on the hex/bin str/bu_vls/bitv conversions:
1. As a group they are conversions to/from e
On Fri, Feb 7, 2014 at 2:53 PM, Christopher Sean Morrison
wrote:
> Private headers go into the src subdirectory (e.g., into src/libbu) and none
> should be installed.
Okey dokey.
-Tom
--
Managing the Performance of Clo
On Fri, Feb 7, 2014 at 1:22 PM, Christopher Sean Morrison
wrote:
> On Feb 7, 2014, at 12:28 PM, Tom Browder wrote:
>
>> Among other things, the literals, whether global or not,
>> need to be defined somewhere, and, IMHO, shouldn't be duplicated. I
>> can certainly rename them in accordance with c
On Feb 7, 2014, at 3:36 PM, Tom Browder wrote:
> Okay, is there an existing private header at global scope (./include)
> that is a good candidate to hold them?
Headers in the top-level include/ directory are public API by definition.
They're the ones that get installed and the intent is to get
On Feb 7, 2014, at 12:28 PM, Tom Browder wrote:
> Among other things, the literals, whether global or not,
> need to be defined somewhere, and, IMHO, shouldn't be duplicated. I
> can certainly rename them in accordance with convention.
Absolutely. Rule of Three is good (minimal), DRY is even b
On Fri, Feb 7, 2014 at 8:55 AM, Christopher Sean Morrison
wrote:
> Tom,
>
> Few thoughts and feedback on the recent addition below.
> In all, looks good but where is this to be used? Do you already have
> something in mind?
> As an API, these are four undocumented new symbols and all are incons
Tom,
Few thoughts and feedback on the recent addition below. In all, looks good but
where is this to be used? Do you already have something in mind?
On Feb 6, 2014, at 6:15 PM, tbrowd...@users.sourceforge.net wrote:
> Modified: brlcad/trunk/include/bu.h
> =
