Author Topic: New projects "Custom Vars" tab  (Read 1811 times)

Online sodev

  • Regular
  • ***
  • Posts: 334
Re: New projects "Custom Vars" tab
« Reply #15 on: November 27, 2019, 11:22:54 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
Re: New projects "Custom Vars" tab
« Reply #16 on: November 30, 2019, 10:02:54 am »
@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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline earlgrey

  • Multiple posting newcomer
  • *
  • Posts: 102
Re: New projects "Custom Vars" tab
« Reply #17 on: December 01, 2019, 09:50:32 am »
CompileOptionsBase vars are now like this :
Code: [Select]
typedef struct
{
    wxString    value;
    wxString    comment;
    int         flags;                    ~ active / inactive vars are just 2 bits in this field ~
} CustomVar;
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 vars
that does not lead to filtering a STL container ( coz there are 2 wxHashMaps ) may be preferable ?
* OS = Debian Buster - Linux 4.19.06 x64 SMP
* C::B = svn11267 wx-3.0.4 - Linux, unicode 64 bit

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
Re: New projects "Custom Vars" tab
« Reply #18 on: December 01, 2019, 10:55:02 am »
What is the goal? Performance? Ease of use?
Why don't you return a vector/array with the CustomVar struct?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline earlgrey

  • Multiple posting newcomer
  • *
  • Posts: 102
Re: New projects "Custom Vars" tab
« Reply #19 on: December 01, 2019, 01:31:33 pm »
> 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: [Select]
for ( CustomVarHash::const_iterator * it = object->VarEnumGetFirst(properties_flags) ; it != nullptr ; it = object->VarEnumGetNext() )

> 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: [Select]
virtual vector< CustomVar const & > VarGetAll(int _i_flags = eVarActive) const;
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.
* OS = Debian Buster - Linux 4.19.06 x64 SMP
* C::B = svn11267 wx-3.0.4 - Linux, unicode 64 bit

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
Re: New projects "Custom Vars" tab
« Reply #20 on: December 01, 2019, 02:31:29 pm »
> Performance ?
You have a  supplementary filtering code, so evidently less preformance
I doubt someone would make 100 or 1000 variables, so performance is not that important here.
If you want performance you'll leave filtering to the callers or use a bitset, but returning new objects on the stack is massive performance problem (new/delete/copy are really expensive functions).

Something like this :
Code: [Select]
virtual vector< CustomVar const & > VarGetAll(int _i_flags = eVarActive) const;
I just didnt think at it  >:(. I do this and I post on github so the code can be reviewed.
This API is really bad for performance...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline earlgrey

  • Multiple posting newcomer
  • *
  • Posts: 102
Re: New projects "Custom Vars" tab
« Reply #21 on: December 01, 2019, 03:03:22 pm »
> I doubt someone would make 100 or 1000 variables
I know that's why I did add the flags and the filtering.

> This API is really bad for performance...
Yes ; rather like this :
Code: [Select]
~ CompileOptionsBase.h ~
std::vector< CustomVar const & > & CompileOptionsBase::VarGetAll(int _i_flags = eVarActive) const;
Code: [Select]
~ CompileOptionsBase.cpp ~
static  std::vector< CustomVar const & > m_VarGetAllResult;
...
std::vector< CustomVar const & > & CompileOptionsBase::VarGetAll() const
{
    ~ filter the vars, fill m_VarGetAllResult, and return reference to it ~
}
The returned vector does not need to be const.

EDIT
This is wrong :
Code: [Select]
static std::vector< CustomVar const & > m_VarGetAllResult;
wont compile :

error: ‘struct std::_Vector_base<const CustomVar&, std::allocator<const CustomVar&> >::_Vector_impl’ has no member named ‘_M_finish’
  std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
 "forming pointer to reference type"
« Last Edit: December 01, 2019, 03:43:37 pm by earlgrey »
* OS = Debian Buster - Linux 4.19.06 x64 SMP
* C::B = svn11267 wx-3.0.4 - Linux, unicode 64 bit

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
Re: New projects "Custom Vars" tab
« Reply #22 on: December 01, 2019, 03:37:08 pm »
I have no time to write the what is wrong with the last proposal, but this latest one is even worse.
Just leave the filtering to the client please.
Either you'll do it or I'll have to do it when I review your changes.  8)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline earlgrey

  • Multiple posting newcomer
  • *
  • Posts: 102
Re: New projects "Custom Vars" tab
« Reply #23 on: December 01, 2019, 03:44:58 pm »
OK boss  ;D
* OS = Debian Buster - Linux 4.19.06 x64 SMP
* C::B = svn11267 wx-3.0.4 - Linux, unicode 64 bit

Offline earlgrey

  • Multiple posting newcomer
  • *
  • Posts: 102
Re: New projects "Custom Vars" tab
« Reply #24 on: December 04, 2019, 07:09:17 pm »
You can have a look @ https://github.com/earlgrey-bis/obuscated.cb/commit/2b4a0cfa2463fce9f3e0aac1b9791d5a7500f2aa

Missing :
- full & correct handling of keyboard shortcuts.
- some code cleanup ( comments, ... )
* OS = Debian Buster - Linux 4.19.06 x64 SMP
* C::B = svn11267 wx-3.0.4 - Linux, unicode 64 bit