Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

New projects "Custom Vars" tab

<< < (4/5) > >>

sodev:
C programmers writing C++ code...

I'm not affiliated with CodeBlocks but i have to drop my 0.5 cent here. Seeing an iterator that is passed around to a different entity is already looking strange, but seeing a pointer to an iterator is really weird. This is not how iterators are used, they are meant as a pointer replacement and usually are used value like together with their container in a close relationship.

oBFusCATed:
@earlgrey: Hm, your explanation is not enough. I don't understand what you want to achieve. You want to filter the variables by enabled/disabled? But why? What is the benefit?

earlgrey:
CompileOptionsBase vars are now like this :

--- Code: ---typedef struct
{
    wxString    value;
    wxString    comment;
    int         flags;                    ~ active / inactive vars are just 2 bits in this field ~
} CustomVar;

--- End code ---
Since the vars can be now of several categories ( with the flags ), whose active and inactive are just two possibilities, you may want to enumerate them following these categories : typically the original C::B code targets only active vars while the CompileOptionsDialog deals with other vars categories.

The difficulty is then to enumerate a subset of a STL container, by filtering properties of the objects it contains. And with a minimal API call code. It is perfectly possible that I am not enough skilled for doing this properly. Suggestions are welcome. ( I found only std::map<Key,T,Compare,Allocator>::equal_range and std::list<T,Allocator>::remove, remove_if, which dont fit )
The simpler implementation of active and inactive vars :

* without the flags extension
* with two wxHashMaps, one for active vars, one for inactive varsthat does not lead to filtering a STL container ( coz there are 2 wxHashMaps ) may be preferable ?

oBFusCATed:
What is the goal? Performance? Ease of use?
Why don't you return a vector/array with the CustomVar struct?

earlgrey:
> What is the goal ?
With the flags, you can extend vars properties in the future

> Performance ?
You have a  supplementary filtering code, so evidently less preformance

> Ease of use ?
Yes, one line code, and  CompileOptionsBase do the filtering, not the caller :

--- Code: ---for ( CustomVarHash::const_iterator * it = object->VarEnumGetFirst(properties_flags) ; it != nullptr ; it = object->VarEnumGetNext() )

--- End code ---

> Why don't you return a vector/array with the CustomVar struct ?
That is interesting ; I made that because I could not return the wxHashMap directly ; And I didnt want to build a filtered wxHashMap and return it ( heavy object, and the existing C::B code that calls GetAllVars() enumerates the keys, but dont uses the mapping feature). But a vector, why not ? Something like this :

--- Code: ---virtual vector< CustomVar const & > VarGetAll(int _i_flags = eVarActive) const;

--- End code ---
I just didnt think at it  >:(. I do this and I post on github so the code can be reviewed.
By the way the name "CustomVar" in the global namespace is not satisfying to me. CompileOptionsBase::Var would be logically OK but it is heavy ? Does someone have a replacement / suggestion to make.

Navigation

[0] Message Index

[#] Next page

[*] Previous page