Hi Stephan,
On Monday, 2012-10-15 12:24:38 +0200, Stephan Bergmann wrote:
> symbols were matched against white/black-lists, and lcl_* was always
> black-listed. Long gone (and I have no idea why people didn't
> simply use "static" anyway).
IIRC, by chance, not using static stems from times wher
On 10/09/2012 07:59 AM, Tor Lillqvist wrote:
Where did this lcl_ convention come from? The lcl_ prefix has no
meaning to a compiler or linker.
One way this /did/ have influence on linking was the old mechanism to
select symbols for DLL export on Windows, where the available symbols
were match
On 10/09/2012 01:59 AM, Tor Lillqvist wrote:
Where did this lcl_ convention come from? The lcl_ prefix has no
meaning to a compiler or linker. If the intent is to make such
functions file-local, why not use the static keyword, or an anonymous
namespace instead, so that they actually *are* local a
On Tuesday 09 of October 2012, Tor Lillqvist wrote:
> Where did this lcl_ convention come from? The lcl_ prefix has no
> meaning to a compiler or linker. If the intent is to make such
> functions file-local, why not use the static keyword, or an anonymous
> namespace instead, so that they actually
Hi Tor,
On Tue, 2012-10-09 at 09:29 +0300, Tor Lillqvist wrote:
> Anyway, my main point was not that we should drop the "lcl_" prefix,
> but that we should make these functions *actually* local, also for the
> tool-chain, i.e. either static or in anonymous namespaces.
Amen - we should sta
On Tue, Oct 09, 2012 at 08:59:47AM +0300, Tor Lillqvist wrote:
> Where did this lcl_ convention come from?
http://wiki.openoffice.org/wiki/Writer_Code_Conventions#free_functions_and_methods
> The lcl_ prefix has no meaning to a compiler or linker. If the intent is to
> make such functions file-lo
On Tuesday 09 of October 2012, Miklos Vajna wrote:
> On Tue, Oct 09, 2012 at 09:29:45AM +0300, Tor Lillqvist wrote:
> > > > Where did this lcl_ convention come from?
From a codebase that is ridden with Hungarian notation and other
eye-"pleasing" features?
> > But how is the fact that you see t
On Tue, Oct 09, 2012 at 09:29:45AM +0300, Tor Lillqvist wrote:
> But how is the fact that you see that some lcl_Function is "local"
> make it easier to understand what the function does? Isn't it only
> unnecessary visual fluff?
Example: if it's lcl_Foo(), I just search in the local file. If it's
> So I think it's useful: when I read code, it makes understanding a bit
> easier.
But how is the fact that you see that some lcl_Function is "local"
make it easier to understand what the function does? Isn't it only
unnecessary visual fluff?
Anyway, my main point was not that we should drop the
On 2012-10-09 07:59, Tor Lillqvist wrote:
Where did this lcl_ convention come from? The lcl_ prefix has no
meaning to a compiler or linker. If the intent is to make such
functions file-local, why not use the static keyword, or an anonymous
namespace instead, so that they actually *are* local als
On Tue, Oct 09, 2012 at 08:59:47AM +0300, Tor Lillqvist wrote:
> Where did this lcl_ convention come from? The lcl_ prefix has no
> meaning to a compiler or linker. If the intent is to make such
> functions file-local, why not use the static keyword, or an anonymous
> namespace instead, so that th
Where did this lcl_ convention come from? The lcl_ prefix has no
meaning to a compiler or linker. If the intent is to make such
functions file-local, why not use the static keyword, or an anonymous
namespace instead, so that they actually *are* local also to the
tool-chain? (You can still keep the
12 matches
Mail list logo
