On Wed, Aug 12, 2015 at 10:38 PM, Bart Van Assche wrote:
> What's wrong with the singleton pattern ?
Less, now :-)
See http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
- Dan
--
_
On 08/12/15 22:18, Jeffrey Walton wrote:
> Its *really* pathetic the C++ language lacks a mechanism for me to say
> "Object 1 depends upon String 1, 2, 3", and "Object 2 depends upon
> Object 1 and String 1, 2, 3".
What's wrong with the singleton pattern ? When using the singleton
pattern non-cir
On Wed, Aug 12, 2015 at 6:02 PM, David Chapman wrote:
> On 8/12/2015 1:09 PM, Dan Kegel wrote:
>> ...
>
> So even though I just told you how to guarantee that global variables in C++
> are initialized before they are used, don't do it. :-) Refactoring sounds
> expensive but in the long run it is
On 8/12/2015 1:09 PM, Dan Kegel wrote:
> On Wed, Aug 12, 2015 at 12:58 PM, Jeffrey Walton wrote:
>> The C++ object that uses it is in another translation unit, and it has
>> a init_pritority attribute.
> File-scope or static C++ objects are the spawn of the devil.
> There is no reliable or portabl
On Wed, Aug 12, 2015 at 1:32 PM, Jeffrey Walton wrote:
> The GCC folks told me to use init_priority for these issues. See
> "Method to specify initialization order across translation units?"
> (https://gcc.gnu.org/ml/gcc-help/2015-08/msg00025.html).
I bet they were thinking "... and get rid of th
On Wed, Aug 12, 2015 at 4:09 PM, Dan Kegel wrote:
> On Wed, Aug 12, 2015 at 12:58 PM, Jeffrey Walton wrote:
>> The C++ object that uses it is in another translation unit, and it has
>> a init_pritority attribute.
>
> File-scope or static C++ objects are the spawn of the devil.
> There is no relia
On Wednesday 12 August 2015 15:58:36 Jeffrey Walton wrote:
> The variable that is triggering the uninitialized access is a simple
> flag and I believe it is initialized:
>
> bool g_flag = false;
>
> The C++ object that uses it is in another translation unit, and it has
> a init_pritority attr
On Wed, Aug 12, 2015 at 12:58 PM, Jeffrey Walton wrote:
> The C++ object that uses it is in another translation unit, and it has
> a init_pritority attribute.
File-scope or static C++ objects are the spawn of the devil.
There is no reliable or portable way to control initialization order,
even wi
I'm catching an uninitialized access on a non-static variable that has
file scope in a C++ translation unit. I'm having trouble interpreting
the finding.
The variable that is triggering the uninitialized access is a simple
flag and I believe it is initialized:
bool g_flag = false;
The C++ ob
