Weak reference helper implementations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Weak reference helper implementations

Peter Kovacs-3
Hello devs,

I am going through the code, when I have little time left.
There is a lot of code I think we don't need the modern implementation should provide us similar functionality.

Is it okay if we target to get rid of such old Code?

Btw. There is a code for a workaround of a bug from gcc version 3. Can we retire that Code?

All the best
Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Marcus (OOo)
Am 14.08.2017 um 19:38 schrieb Peter kovacs:

> I am going through the code, when I have little time left.

:-)

> There is a lot of code I think we don't need the modern implementation should provide us similar functionality.

What do you mean with "modern implementation". Should newer libaries and
frameworks we use nowadays provide this support?
>
> Is it okay if we target to get rid of such old Code?
>
> Btw. There is a code for a workaround of a bug from gcc version 3. Can we retire that Code?

Version 3 started in early 2000. A quick search in our Wiki [1] found
only some hits and these are - surprise - very old. But I don't think
that these are relevant any more.

I cannot lookup what the configure script is tell you as minimal version
of gcc. But I would bet it's far away from 3.

[1] https://wiki.openoffice.org/

My 2 ct - as non-developer.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Peter Kovacs-3
Sorry, for my bad english.
I meant that I think that some of the functionality which we have implemented in helper functions in the past can be retired by using modern c++11 and later standards.
The code will be smaller,and according to Bjarne Stroustrup also faster.
I also would like to limit if not ban usage of C code. It makes tmaintainability more difficult, and I do not see the benefit. Honestly even less then the Java stuff.
I also don't like helper structures. It is a sign for weak architecture in my eyes. (But that's naming and structuring of code)

With our small team, I would opt always for less codelines if possible. Limit is only readability.

I would like to know if there is support from others to remove those whenever possible with c++11 Or later code? Or what strategy do we want to head out for.

I have soon more little time. And then I want to do some stuff. Sadly I will do less then I want to, but I hope it will go fine.

All the best.
Peter


Am 14. August 2017 19:54:06 MESZ schrieb Marcus <[hidden email]>:

>Am 14.08.2017 um 19:38 schrieb Peter kovacs:
>
>> I am going through the code, when I have little time left.
>
>:-)
>
>> There is a lot of code I think we don't need the modern
>implementation should provide us similar functionality.
>
>What do you mean with "modern implementation". Should newer libaries
>and
>frameworks we use nowadays provide this support?
>>
>> Is it okay if we target to get rid of such old Code?
>>
>> Btw. There is a code for a workaround of a bug from gcc version 3.
>Can we retire that Code?
>
>Version 3 started in early 2000. A quick search in our Wiki [1] found
>only some hits and these are - surprise - very old. But I don't think
>that these are relevant any more.
>
>I cannot lookup what the configure script is tell you as minimal
>version
>of gcc. But I would bet it's far away from 3.
>
>[1] https://wiki.openoffice.org/
>
>My 2 ct - as non-developer.
>
>Marcus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Don Lewis-2
On 14 Aug, Peter kovacs wrote:

> Sorry, for my bad english.
> I meant that I think that some of the functionality which we have
> implemented in helper functions in the past can be retired by using
> modern c++11 and later standards. The code will be smaller,and
> according to Bjarne Stroustrup also faster. I also would like to limit
> if not ban usage of C code. It makes tmaintainability more difficult,
> and I do not see the benefit. Honestly even less then the Java stuff.
> I also don't like helper structures. It is a sign for weak
> architecture in my eyes. (But that's naming and structuring of code)
>
> With our small team, I would opt always for less codelines if
> possible. Limit is only readability.
>
> I would like to know if there is support from others to remove those
> whenever possible with c++11 Or later code? Or what strategy do we
> want to head out for.

I don't think we can depend on c++11 at this time.  According to our
build documentation for Windows, we can't use anything newer than MSVC
2008:
  https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7.2C_Windows_8.1.2C_Windows_10



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Don Lewis-2
On 14 Aug, To: [hidden email] wrote:

> On 14 Aug, Peter kovacs wrote:
>> Sorry, for my bad english.
>> I meant that I think that some of the functionality which we have
>> implemented in helper functions in the past can be retired by using
>> modern c++11 and later standards. The code will be smaller,and
>> according to Bjarne Stroustrup also faster. I also would like to limit
>> if not ban usage of C code. It makes tmaintainability more difficult,
>> and I do not see the benefit. Honestly even less then the Java stuff.
>> I also don't like helper structures. It is a sign for weak
>> architecture in my eyes. (But that's naming and structuring of code)
>>
>> With our small team, I would opt always for less codelines if
>> possible. Limit is only readability.
>>
>> I would like to know if there is support from others to remove those
>> whenever possible with c++11 Or later code? Or what strategy do we
>> want to head out for.
>
> I don't think we can depend on c++11 at this time.  According to our
> build documentation for Windows, we can't use anything newer than MSVC
> 2008:
>   https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7.2C_Windows_8.1.2C_Windows_10

... and the version of gcc in CentOS 5 is of a similar vintage.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Peter Kovacs-3
Good points!

But we need to address the dependency aging anyways.
Because modern system having difficulties with our code.

We must develop a plan how we modernise the code.

How about support by version:
With 4.x we will support whatever we have today.
5.x will be on newer compiler dependency.
Mvcs 2010 and gcc 4.4?

6.x will again support later versions.

So we can plan how to start planning what to do.

All the best
Peter

Am 15. August 2017 07:48:22 MESZ schrieb Don Lewis <[hidden email]>:

>On 14 Aug, To: [hidden email] wrote:
>> On 14 Aug, Peter kovacs wrote:
>>> Sorry, for my bad english.
>>> I meant that I think that some of the functionality which we have
>>> implemented in helper functions in the past can be retired by using
>>> modern c++11 and later standards. The code will be smaller,and
>>> according to Bjarne Stroustrup also faster. I also would like to
>limit
>>> if not ban usage of C code. It makes tmaintainability more
>difficult,
>>> and I do not see the benefit. Honestly even less then the Java
>stuff.
>>> I also don't like helper structures. It is a sign for weak
>>> architecture in my eyes. (But that's naming and structuring of code)
>>>
>>> With our small team, I would opt always for less codelines if
>>> possible. Limit is only readability.
>>>
>>> I would like to know if there is support from others to remove those
>>> whenever possible with c++11 Or later code? Or what strategy do we
>>> want to head out for.
>>
>> I don't think we can depend on c++11 at this time.  According to our
>> build documentation for Windows, we can't use anything newer than
>MSVC
>> 2008:
>>  
>https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7.2C_Windows_8.1.2C_Windows_10
>
>... and the version of gcc in CentOS 5 is of a similar vintage.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Patricia Shanahan
In reply to this post by Peter Kovacs-3
I have suggested a refactoring pass to make more use of STL structures
instead of fixed size, unchecked arrays. Some security problem would be
caught by array bounds checking.

We have some new volunteers over on the recruitment mailing list. I
think refactoring would be a good project for getting people involved.

Even if we can't go all the way to C++11, we can make some progress
towards the 21st century.

On 8/14/2017 12:04 PM, Peter kovacs wrote:

> Sorry, for my bad english.
> I meant that I think that some of the functionality which we have implemented in helper functions in the past can be retired by using modern c++11 and later standards.
> The code will be smaller,and according to Bjarne Stroustrup also faster.
> I also would like to limit if not ban usage of C code. It makes tmaintainability more difficult, and I do not see the benefit. Honestly even less then the Java stuff.
> I also don't like helper structures. It is a sign for weak architecture in my eyes. (But that's naming and structuring of code)
>
> With our small team, I would opt always for less codelines if possible. Limit is only readability.
>
> I would like to know if there is support from others to remove those whenever possible with c++11 Or later code? Or what strategy do we want to head out for.
>
> I have soon more little time. And then I want to do some stuff. Sadly I will do less then I want to, but I hope it will go fine.
>
> All the best.
> Peter
>
>
> Am 14. August 2017 19:54:06 MESZ schrieb Marcus <[hidden email]>:
>> Am 14.08.2017 um 19:38 schrieb Peter kovacs:
>>
>>> I am going through the code, when I have little time left.
>>
>> :-)
>>
>>> There is a lot of code I think we don't need the modern
>> implementation should provide us similar functionality.
>>
>> What do you mean with "modern implementation". Should newer libaries
>> and
>> frameworks we use nowadays provide this support?
>>>
>>> Is it okay if we target to get rid of such old Code?
>>>
>>> Btw. There is a code for a workaround of a bug from gcc version 3.
>> Can we retire that Code?
>>
>> Version 3 started in early 2000. A quick search in our Wiki [1] found
>> only some hits and these are - surprise - very old. But I don't think
>> that these are relevant any more.
>>
>> I cannot lookup what the configure script is tell you as minimal
>> version
>> of gcc. But I would bet it's far away from 3.
>>
>> [1] https://wiki.openoffice.org/
>>
>> My 2 ct - as non-developer.
>>
>> Marcus
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Weak reference helper implementations

Peter Kovacs-3
Yes, I had the array activity in mind.
I am suggesting to do the same for pointers and references.

I am unsure which std methods are available in gcc version 4.1 or 4.4 however we could maybe in case of smart and weak pointers fall back to boost if not available in the compiler.

By this we can
# reduce code
# modernize code
# while keeping support for pretty old systems. (Like centos 5)

All the best
Peter

Am 16. August 2017 04:31:25 MESZ schrieb Patricia Shanahan <[hidden email]>:

>I have suggested a refactoring pass to make more use of STL structures
>instead of fixed size, unchecked arrays. Some security problem would be
>
>caught by array bounds checking.
>
>We have some new volunteers over on the recruitment mailing list. I
>think refactoring would be a good project for getting people involved.
>
>Even if we can't go all the way to C++11, we can make some progress
>towards the 21st century.
>
>On 8/14/2017 12:04 PM, Peter kovacs wrote:
>> Sorry, for my bad english.
>> I meant that I think that some of the functionality which we have
>implemented in helper functions in the past can be retired by using
>modern c++11 and later standards.
>> The code will be smaller,and according to Bjarne Stroustrup also
>faster.
>> I also would like to limit if not ban usage of C code. It makes
>tmaintainability more difficult, and I do not see the benefit. Honestly
>even less then the Java stuff.
>> I also don't like helper structures. It is a sign for weak
>architecture in my eyes. (But that's naming and structuring of code)
>>
>> With our small team, I would opt always for less codelines if
>possible. Limit is only readability.
>>
>> I would like to know if there is support from others to remove those
>whenever possible with c++11 Or later code? Or what strategy do we want
>to head out for.
>>
>> I have soon more little time. And then I want to do some stuff. Sadly
>I will do less then I want to, but I hope it will go fine.
>>
>> All the best.
>> Peter
>>
>>
>> Am 14. August 2017 19:54:06 MESZ schrieb Marcus
><[hidden email]>:
>>> Am 14.08.2017 um 19:38 schrieb Peter kovacs:
>>>
>>>> I am going through the code, when I have little time left.
>>>
>>> :-)
>>>
>>>> There is a lot of code I think we don't need the modern
>>> implementation should provide us similar functionality.
>>>
>>> What do you mean with "modern implementation". Should newer libaries
>>> and
>>> frameworks we use nowadays provide this support?
>>>>
>>>> Is it okay if we target to get rid of such old Code?
>>>>
>>>> Btw. There is a code for a workaround of a bug from gcc version 3.
>>> Can we retire that Code?
>>>
>>> Version 3 started in early 2000. A quick search in our Wiki [1]
>found
>>> only some hits and these are - surprise - very old. But I don't
>think
>>> that these are relevant any more.
>>>
>>> I cannot lookup what the configure script is tell you as minimal
>>> version
>>> of gcc. But I would bet it's far away from 3.
>>>
>>> [1] https://wiki.openoffice.org/
>>>
>>> My 2 ct - as non-developer.
>>>
>>> Marcus
>>>
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]