Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #88349 > unrolled thread

About Flibble

Back to article view | Back to comp.lang.c++

Contents

  About Flibble Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-01-02 01:22 +0000
    Re: About Flibble "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-01-02 18:39 +0100
      Re: About Flibble Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-01-02 18:08 +0000
    Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-02 21:41 -0800
      Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-02 21:43 -0800
        Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-02 21:44 -0800
    Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:59 -0800
    Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-11 23:13 -0800
      Re: About Flibble Stuart Redmann <DerTopper@web.de> - 2023-01-13 07:19 +0100
        Re: About Flibble Muttley@dastardlyhq.com - 2023-01-13 10:15 +0000
        Re: About Flibble Manu Raju <MR@invalid.invalid> - 2023-01-13 14:29 +0000
        Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-13 13:43 -0800
          Re: About Flibble Muttley@dastardlyhq.com - 2023-01-14 09:52 +0000
            Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-14 14:44 -0800
              Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-16 11:37 +0100
                Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-16 11:45 -0800
                  Re: About Flibble Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-01-16 20:49 +0000
                    Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 00:02 -0800
                      Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 00:04 -0800
                Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-16 11:52 -0800
                  Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-16 11:57 -0800
          Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-16 11:32 +0100
            Re: About Flibble Muttley@dastardlyhq.com - 2023-01-16 11:31 +0000
              Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-16 11:51 -0800
                Re: About Flibble Muttley@dastardlyhq.com - 2023-01-17 09:34 +0000
                  Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-17 12:36 -0800
                    Re: About Flibble Muttley@dastardlyhq.com - 2023-01-18 09:27 +0000
                      Re: About Flibble Christian Gollwitzer <auriocus@gmx.de> - 2023-01-18 16:22 +0100
                      Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 11:56 -0800
                        Re: About Flibble scott@slp53.sl.home (Scott Lurndal) - 2023-01-18 20:00 +0000
                          Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 12:11 -0800
                            Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-18 21:17 +0100
                              Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 12:35 -0800
                                Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-19 08:55 +0100
                                  Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 20:11 -0800
                                    Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 20:12 -0800
                              Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-18 12:37 -0800
                              Re: About Flibble Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-18 15:30 -0800
                                Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-19 08:55 +0100
                                Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-19 12:16 -0800
                          Re: About Flibble Muttley@dastardlyhq.com - 2023-01-19 09:33 +0000
                            Re: About Flibble David Brown <david.brown@hesbynett.no> - 2023-01-19 15:28 +0100
                              Re: About Flibble scott@slp53.sl.home (Scott Lurndal) - 2023-01-19 14:57 +0000
            Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-16 11:46 -0800
        Re: About Flibble Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-01-14 19:24 +0000
      Re: About Flibble Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-01-14 19:24 +0000
        Re: About Flibble "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-14 13:13 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#88548

On 1/16/2023 11:52 AM, Chris M. Thomasson wrote:
> On 1/16/2023 2:37 AM, David Brown wrote:
>> On 14/01/2023 23:44, Chris M. Thomasson wrote:
>>> On 1/14/2023 1:52 AM, Muttley@dastardlyhq.com wrote:
>>>> On Fri, 13 Jan 2023 13:43:06 -0800
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>>> On 1/12/2023 10:19 PM, Stuart Redmann wrote:
>>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>>>> On 1/1/2023 5:22 PM, Mr Flibble wrote:
>>>>>>>> I am a Generation X white male aphantasiac with self-diagnosed 
>>>>>>>> Asperger's.
>>>>>>>> Bite me.
>>>>>>>>
>>>>>>>> Message ends.
>>>>>>>
>>>>>>> The god damn MSVC debugger is messed up pretty bad! Got another 
>>>>>>> taste of it!
>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Care to elaborate?
>>>>>
>>>>>> I think that the Visual Studios debugging capabilities
>>>>>> are outstanding because of the ability to add custom debug 
>>>>>> visualization.
>>>>>> This is possible using a rather rich extension interface (badly 
>>>>>> documented,
>>>>>> though). It enables us to export our data (2D geometries like 
>>>>>> polygons,
>>>>>> line strings, etc.) into an external viewer with a simple mouse 
>>>>>> click. It
>>>>>> can‘t get more convenient than that.
>>>>>
>>>>> A line of code would push_back an element into a std::vector. The damn
>>>>> debugger would show that the vector contained no elements, however, 
>>>>> one
>>>>> was there. Then there are other oddities.
>>>>>
>>>>> I have never had this problem with MSVC before.
>>>>
>>>> I don't know about VS, but if you use heavy optimisation with gcc 
>>>> then gdb
>>>> will often lose the plot when stepping and examining variables. 
>>>> Perhaps that
>>>> was the issue you had?
>>>>
>>>
>>> In debug mode.
>>
>> "Debug mode" is mostly a meaningless concept.
>>
>> Many IDE's set up two different build configurations - one they call 
>> "Debug" with low optimisation and lots of debugger information, and 
>> one they call "Release" with high optimisation and little debugger 
>> information.  But there is not really such a thing as "optimised" code 
>> and "unoptimised" code - compilers can enable or disable different 
>> passes and different kinds of optimisations.  Some "optimisations" are 
>> done even when compilers are set to "no optimisation", and some 
>> optimisation passes that are possible are not done even on "highest 
>> optimisation" flags.  (And some "optimisations" can make code slower 
>> in practice.)
>>
>> At best, "debug mode" reduces the risk of seeing such disconnects 
>> between the source code and the effect of the object code, but it will 
>> not eliminate it.
>>
> 
> https://i.ibb.co/SV3dMQ7/image.png

I wonder if frame pointers has something to do with it. The thing is 
that MSVC always just worked. I have never experienced anything like 
this in it before. ;^o

[toc] | [prev] | [next] | [standalone]

#88537

On 13/01/2023 22:43, Chris M. Thomasson wrote:
> On 1/12/2023 10:19 PM, Stuart Redmann wrote:
>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 1/1/2023 5:22 PM, Mr Flibble wrote:
>>>> I am a Generation X white male aphantasiac with self-diagnosed 
>>>> Asperger's.
>>>> Bite me.
>>>>
>>>> Message ends.
>>>
>>> The god damn MSVC debugger is messed up pretty bad! Got another taste 
>>> of it!
>>>
>>>
>>
>> Care to elaborate? 
> 
>> I think that the Visual Studios debugging capabilities
>> are outstanding because of the ability to add custom debug visualization.
>> This is possible using a rather rich extension interface (badly 
>> documented,
>> though). It enables us to export our data (2D geometries like polygons,
>> line strings, etc.) into an external viewer with a simple mouse click. It
>> can‘t get more convenient than that.
> 
> A line of code would push_back an element into a std::vector. The damn 
> debugger would show that the vector contained no elements, however, one 
> was there. Then there are other oddities.
> 
> I have never had this problem with MSVC before.

Are you debugging optimised code here?  Remember that when 
single-stepping or using breakpoints, a debugger is working primarily 
with the generated object code.  And when looking at variables, it is 
mainly using the data in memory or registers.  But there is often a 
disconnect between the lines of the source code and the generated object 
code - a line you step over might /logically/ put an element into a 
vector, but the actual change to the data structure could be done far 
latter in the code.

MSVC has traditionally had quite a simplistic handling for a lot of code 
generation - it has done little in the way of re-arranging code.  But I 
have heard (I don't use the tool myself) that is does more manipulation 
these days.

When using gcc and a debugger, it is quite normal for single-stepping to 
jump around the code, for things to happen long before or long after you 
might think from the "current" source line, for variables to be 
"optimised out", etc.  Debugging optimised code is something of an art.

[toc] | [prev] | [next] | [standalone]

#88539

On Mon, 16 Jan 2023 11:32:34 +0100
David Brown <david.brown@hesbynett.no> wrote:
>When using gcc and a debugger, it is quite normal for single-stepping to 
>jump around the code, for things to happen long before or long after you 
>might think from the "current" source line, for variables to be 
>"optimised out", etc.  Debugging optimised code is something of an art.

And debugging optimised multithreaded code will end up with you gibbering in
a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.

[toc] | [prev] | [next] | [standalone]

#88546

On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
> On Mon, 16 Jan 2023 11:32:34 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> When using gcc and a debugger, it is quite normal for single-stepping to
>> jump around the code, for things to happen long before or long after you
>> might think from the "current" source line, for variables to be
>> "optimised out", etc.  Debugging optimised code is something of an art.
> 
> And debugging optimised multithreaded code will end up with you gibbering in
> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
> 
> 

MSVC's debugger was always pretty damn good. I have used it to debug 
nightmare multi-threaded code created by somebody else, where I had to 
pause threads at a specific line, in order to reproduce a certain bug 
that would only trip once in a blue moon. Found it during artificially 
stress and load testing. This was a long time ago. Actually, I think I 
wrote about it here some years ago on this group.

Optimization is turned off in Debug mode. Wrt to the IDE:

https://i.ibb.co/SV3dMQ7/image.png

Never had this problem before.

[toc] | [prev] | [next] | [standalone]

#88553

On Mon, 16 Jan 2023 11:51:56 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>> On Mon, 16 Jan 2023 11:32:34 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>> jump around the code, for things to happen long before or long after you
>>> might think from the "current" source line, for variables to be
>>> "optimised out", etc.  Debugging optimised code is something of an art.
>> 
>> And debugging optimised multithreaded code will end up with you gibbering in
>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>> 
>> 
>
>MSVC's debugger was always pretty damn good. I have used it to debug 
>nightmare multi-threaded code created by somebody else, where I had to 
>pause threads at a specific line, in order to reproduce a certain bug 

Thats fine if you know where the line is but usually with threading issues
(and to be fair non threaded code too) a bug/crash occurs due to an earlier 
bug or design error which in itself goes unnoticed.

[toc] | [prev] | [next] | [standalone]

#88574

On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
> On Mon, 16 Jan 2023 11:51:56 -0800
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>> jump around the code, for things to happen long before or long after you
>>>> might think from the "current" source line, for variables to be
>>>> "optimised out", etc.  Debugging optimised code is something of an art.
>>>
>>> And debugging optimised multithreaded code will end up with you gibbering in
>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>
>>>
>>
>> MSVC's debugger was always pretty damn good. I have used it to debug
>> nightmare multi-threaded code created by somebody else, where I had to
>> pause threads at a specific line, in order to reproduce a certain bug
> 
> Thats fine if you know where the line is but usually with threading issues
> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
> bug or design error which in itself goes unnoticed.
> 

Touche. Well, if there is a bug in my OpenGL code, I have not found it 
yet. Humm... So far, everything works and renders perfectly. My 
debugging issue with MSVC had to do with push_back's on a vector, then 
the debugger showed that it had no items. I said, shit... So, I iterated 
the vector and sure enough, it was not empty and all of my vector data 
(vertex, color, texture vertex, normals, ect...) was all there and 
filled in with the correct data. Strange. I was thinking if the debugger 
says the vector is empty, then how did all of the data get successfully 
uploaded to the GPU! Argh!

Fwiw, here is an crude example scene of my current project:

https://youtu.be/n13GHyYEfLA

[toc] | [prev] | [next] | [standalone]

#88596

On Tue, 17 Jan 2023 12:36:06 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
>> On Mon, 16 Jan 2023 11:51:56 -0800
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>> On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>>> jump around the code, for things to happen long before or long after you
>>>>> might think from the "current" source line, for variables to be
>>>>> "optimised out", etc.  Debugging optimised code is something of an art.
>>>>
>>>> And debugging optimised multithreaded code will end up with you gibbering
>in
>>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>>
>>>>
>>>
>>> MSVC's debugger was always pretty damn good. I have used it to debug
>>> nightmare multi-threaded code created by somebody else, where I had to
>>> pause threads at a specific line, in order to reproduce a certain bug
>> 
>> Thats fine if you know where the line is but usually with threading issues
>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>> bug or design error which in itself goes unnoticed.
>> 
>
>Touche. Well, if there is a bug in my OpenGL code, I have not found it 
>yet. Humm... So far, everything works and renders perfectly. My 

The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
fine for 2 months" type.

[toc] | [prev] | [next] | [standalone]

#88602

Am 18.01.23 um 10:27 schrieb Muttley@dastardlyhq.com:
> On Tue, 17 Jan 2023 12:36:06 -0800
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
>>> Thats fine if you know where the line is but usually with threading issues
>>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>>> bug or design error which in itself goes unnoticed.
>>>
>>
>> Touche. Well, if there is a bug in my OpenGL code, I have not found it
>> yet. Humm... So far, everything works and renders perfectly. My
> 
> The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
> correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
> fine for 2 months" type.
> 

Yes, and here are my 2cents to debug these: valgrind, helgrind and 
address sanititzer (million times more worth than 2 cents)

	Christian

[toc] | [prev] | [next] | [standalone]

#88610

On 1/18/2023 1:27 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 17 Jan 2023 12:36:06 -0800
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 16 Jan 2023 11:51:56 -0800
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>> On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>>>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>>>> jump around the code, for things to happen long before or long after you
>>>>>> might think from the "current" source line, for variables to be
>>>>>> "optimised out", etc.  Debugging optimised code is something of an art.
>>>>>
>>>>> And debugging optimised multithreaded code will end up with you gibbering
>> in
>>>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>>>
>>>>>
>>>>
>>>> MSVC's debugger was always pretty damn good. I have used it to debug
>>>> nightmare multi-threaded code created by somebody else, where I had to
>>>> pause threads at a specific line, in order to reproduce a certain bug
>>>
>>> Thats fine if you know where the line is but usually with threading issues
>>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>>> bug or design error which in itself goes unnoticed.
>>>
>>
>> Touche. Well, if there is a bug in my OpenGL code, I have not found it
>> yet. Humm... So far, everything works and renders perfectly. My
> 
> The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
> correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
> fine for 2 months" type.

Usually, those type of bugs are with race-conditions. My code is not 
using multiple threads yet.

[toc] | [prev] | [next] | [standalone]

#88612

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 1/18/2023 1:27 AM, Muttley@dastardlyhq.com wrote:
>> On Tue, 17 Jan 2023 12:36:06 -0800
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>> On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
>>>> On Mon, 16 Jan 2023 11:51:56 -0800
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>>> On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>>>>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>>>>> jump around the code, for things to happen long before or long after you
>>>>>>> might think from the "current" source line, for variables to be
>>>>>>> "optimised out", etc.  Debugging optimised code is something of an art.
>>>>>>
>>>>>> And debugging optimised multithreaded code will end up with you gibbering
>>> in
>>>>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>>>>
>>>>>>
>>>>>
>>>>> MSVC's debugger was always pretty damn good. I have used it to debug
>>>>> nightmare multi-threaded code created by somebody else, where I had to
>>>>> pause threads at a specific line, in order to reproduce a certain bug
>>>>
>>>> Thats fine if you know where the line is but usually with threading issues
>>>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>>>> bug or design error which in itself goes unnoticed.
>>>>
>>>
>>> Touche. Well, if there is a bug in my OpenGL code, I have not found it
>>> yet. Humm... So far, everything works and renders perfectly. My
>> 
>> The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
>> correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
>> fine for 2 months" type.
>
>Usually, those type of bugs are with race-conditions. 

Or using uninitialized variables, particularly in
functions.   Could work for weeks, then the program
takes a different path and the stack contains a
value that causes a crash.

[toc] | [prev] | [next] | [standalone]

#88613

On 1/18/2023 12:00 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 1/18/2023 1:27 AM, Muttley@dastardlyhq.com wrote:
>>> On Tue, 17 Jan 2023 12:36:06 -0800
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>> On 1/17/2023 1:34 AM, Muttley@dastardlyhq.com wrote:
>>>>> On Mon, 16 Jan 2023 11:51:56 -0800
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>>>> On 1/16/2023 3:31 AM, Muttley@dastardlyhq.com wrote:
>>>>>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>>>>>> jump around the code, for things to happen long before or long after you
>>>>>>>> might think from the "current" source line, for variables to be
>>>>>>>> "optimised out", etc.  Debugging optimised code is something of an art.
>>>>>>>
>>>>>>> And debugging optimised multithreaded code will end up with you gibbering
>>>> in
>>>>>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> MSVC's debugger was always pretty damn good. I have used it to debug
>>>>>> nightmare multi-threaded code created by somebody else, where I had to
>>>>>> pause threads at a specific line, in order to reproduce a certain bug
>>>>>
>>>>> Thats fine if you know where the line is but usually with threading issues
>>>>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>>>>> bug or design error which in itself goes unnoticed.
>>>>>
>>>>
>>>> Touche. Well, if there is a bug in my OpenGL code, I have not found it
>>>> yet. Humm... So far, everything works and renders perfectly. My
>>>
>>> The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
>>> correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
>>> fine for 2 months" type.
>>
>> Usually, those type of bugs are with race-conditions.
> 
> Or using uninitialized variables, particularly in
> functions.   Could work for weeks, then the program
> takes a different path and the stack contains a
> value that causes a crash.

True. Well, so far, I don't think I have a problem. MSVC is pretty good 
at flagging uninitialized variables, and I have a habit of always 
initializing them.

int x = 0;

instead of:

int x;

Well, if I do have a bug, its a good thing that my program is in 
pre-alpha experimental stage!

[toc] | [prev] | [next] | [standalone]

#88614

On 18/01/2023 21:11, Chris M. Thomasson wrote:
> On 1/18/2023 12:00 PM, Scott Lurndal wrote:

>> Or using uninitialized variables, particularly in
>> functions.   Could work for weeks, then the program
>> takes a different path and the stack contains a
>> value that causes a crash.
> 
> True. Well, so far, I don't think I have a problem. MSVC is pretty good 
> at flagging uninitialized variables, and I have a habit of always 
> initializing them.
> 
> int x = 0;
> 
> instead of:
> 
> int x;
> 

That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
course).  It is bad precisely because it stops the compiler from warning 
you when you have forgotten to put a real value in the variable.

Get in the habit of declaring local variables only when you have 
something useful to put in them, and initialising them at that point. 
But if you must declare a variable before you have an initial value, do 
not artificially initialise it - you are just making it harder for the 
tools to find your bugs.

[toc] | [prev] | [next] | [standalone]

#88615

On 1/18/2023 12:17 PM, David Brown wrote:
> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
> 
>>> Or using uninitialized variables, particularly in
>>> functions.   Could work for weeks, then the program
>>> takes a different path and the stack contains a
>>> value that causes a crash.
>>
>> True. Well, so far, I don't think I have a problem. MSVC is pretty 
>> good at flagging uninitialized variables, and I have a habit of always 
>> initializing them.
>>
>> int x = 0;
>>
>> instead of:
>>
>> int x;
>>
> 
> That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
> course).  It is bad precisely because it stops the compiler from warning 
> you when you have forgotten to put a real value in the variable.
> 
> Get in the habit of declaring local variables only when you have 
> something useful to put in them, and initialising them at that point. 
> But if you must declare a variable before you have an initial value, do 
> not artificially initialise it - you are just making it harder for the 
> tools to find your bugs.

Yes. I have been told this, damn near, exact same warning before David 
on a couple of jobs.

[toc] | [prev] | [next] | [standalone]

#88619

On 18/01/2023 21:35, Chris M. Thomasson wrote:
> On 1/18/2023 12:17 PM, David Brown wrote:
>> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>>
>>>> Or using uninitialized variables, particularly in
>>>> functions.   Could work for weeks, then the program
>>>> takes a different path and the stack contains a
>>>> value that causes a crash.
>>>
>>> True. Well, so far, I don't think I have a problem. MSVC is pretty 
>>> good at flagging uninitialized variables, and I have a habit of 
>>> always initializing them.
>>>
>>> int x = 0;
>>>
>>> instead of:
>>>
>>> int x;
>>>
>>
>> That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
>> course).  It is bad precisely because it stops the compiler from 
>> warning you when you have forgotten to put a real value in the variable.
>>
>> Get in the habit of declaring local variables only when you have 
>> something useful to put in them, and initialising them at that point. 
>> But if you must declare a variable before you have an initial value, 
>> do not artificially initialise it - you are just making it harder for 
>> the tools to find your bugs.
> 
> Yes. I have been told this, damn near, exact same warning before David 
> on a couple of jobs.
> 

That should give you a clue that it is a good idea!

[toc] | [prev] | [next] | [standalone]

#88794

On 1/18/2023 11:55 PM, David Brown wrote:
> On 18/01/2023 21:35, Chris M. Thomasson wrote:
>> On 1/18/2023 12:17 PM, David Brown wrote:
>>> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>>>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>>>
>>>>> Or using uninitialized variables, particularly in
>>>>> functions.   Could work for weeks, then the program
>>>>> takes a different path and the stack contains a
>>>>> value that causes a crash.
>>>>
>>>> True. Well, so far, I don't think I have a problem. MSVC is pretty 
>>>> good at flagging uninitialized variables, and I have a habit of 
>>>> always initializing them.
>>>>
>>>> int x = 0;
>>>>
>>>> instead of:
>>>>
>>>> int x;
>>>>
>>>
>>> That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
>>> course).  It is bad precisely because it stops the compiler from 
>>> warning you when you have forgotten to put a real value in the variable.
>>>
>>> Get in the habit of declaring local variables only when you have 
>>> something useful to put in them, and initialising them at that point. 
>>> But if you must declare a variable before you have an initial value, 
>>> do not artificially initialise it - you are just making it harder for 
>>> the tools to find your bugs.
>>
>> Yes. I have been told this, damn near, exact same warning before David 
>> on a couple of jobs.
>>
> 
> That should give you a clue that it is a good idea!
> 

Nodding. So far, I have found a bug in my code yet. During a refactor.

[toc] | [prev] | [next] | [standalone]

#88795

On 1/23/2023 8:11 PM, Chris M. Thomasson wrote:
> On 1/18/2023 11:55 PM, David Brown wrote:
>> On 18/01/2023 21:35, Chris M. Thomasson wrote:
>>> On 1/18/2023 12:17 PM, David Brown wrote:
>>>> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>>>>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>>>>
>>>>>> Or using uninitialized variables, particularly in
>>>>>> functions.   Could work for weeks, then the program
>>>>>> takes a different path and the stack contains a
>>>>>> value that causes a crash.
>>>>>
>>>>> True. Well, so far, I don't think I have a problem. MSVC is pretty 
>>>>> good at flagging uninitialized variables, and I have a habit of 
>>>>> always initializing them.
>>>>>
>>>>> int x = 0;
>>>>>
>>>>> instead of:
>>>>>
>>>>> int x;
>>>>>
>>>>
>>>> That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
>>>> course).  It is bad precisely because it stops the compiler from 
>>>> warning you when you have forgotten to put a real value in the 
>>>> variable.
>>>>
>>>> Get in the habit of declaring local variables only when you have 
>>>> something useful to put in them, and initialising them at that 
>>>> point. But if you must declare a variable before you have an initial 
>>>> value, do not artificially initialise it - you are just making it 
>>>> harder for the tools to find your bugs.
>>>
>>> Yes. I have been told this, damn near, exact same warning before 
>>> David on a couple of jobs.
>>>
>>
>> That should give you a clue that it is a good idea!
>>
> 
> Nodding. So far, I have found a bug in my code yet. During a refactor.

God damn it! I have NOT found a bug yet. f'ing typos!

Shit.

[toc] | [prev] | [next] | [standalone]

#88616

On 1/18/2023 12:17 PM, David Brown wrote:
> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
> 
>>> Or using uninitialized variables, particularly in
>>> functions.   Could work for weeks, then the program
>>> takes a different path and the stack contains a
>>> value that causes a crash.
>>
>> True. Well, so far, I don't think I have a problem. MSVC is pretty 
>> good at flagging uninitialized variables, and I have a habit of always 
>> initializing them.
>>
>> int x = 0;
>>
>> instead of:
>>
>> int x;
>>
> 
> That's a /really/ bad idea (unless you actually /want/ x to be 0, of 
> course).  It is bad precisely because it stops the compiler from warning 
> you when you have forgotten to put a real value in the variable.
> 
> Get in the habit of declaring local variables only when you have 
> something useful to put in them, and initialising them at that point. 
> But if you must declare a variable before you have an initial value, do 
> not artificially initialise it - you are just making it harder for the 
> tools to find your bugs.

Fwiw, I am going to start fresh in a couple of days. Basically refactor 
my experimental pre-alpha code base into a fresh project on a 
part-by-part basis. I need to do it. Basically, clean house!

[toc] | [prev] | [next] | [standalone]

#88617

David Brown <david.brown@hesbynett.no> writes:
> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>
>>> Or using uninitialized variables, particularly in
>>> functions.   Could work for weeks, then the program
>>> takes a different path and the stack contains a
>>> value that causes a crash.
>> True. Well, so far, I don't think I have a problem. MSVC is pretty
>> good at flagging uninitialized variables, and I have a habit of
>> always initializing them.
>> int x = 0;
>> instead of:
>> int x;
>
> That's a /really/ bad idea (unless you actually /want/ x to be 0, of
> course).  It is bad precisely because it stops the compiler from
> warning you when you have forgotten to put a real value in the
> variable.
>
> Get in the habit of declaring local variables only when you have
> something useful to put in them, and initialising them at that point. 
> But if you must declare a variable before you have an initial value,
> do not artificially initialise it - you are just making it harder for
> the tools to find your bugs.

Or initialize it with some recognizably invalid value, if there is such
a value for the type.

Leaving it uninitialized helps the compiler diagnose errors.
Initializing it with recognizable garbage helps with run-time debugging.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#88618

On 19/01/2023 00:30, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>>
>>>> Or using uninitialized variables, particularly in
>>>> functions.   Could work for weeks, then the program
>>>> takes a different path and the stack contains a
>>>> value that causes a crash.
>>> True. Well, so far, I don't think I have a problem. MSVC is pretty
>>> good at flagging uninitialized variables, and I have a habit of
>>> always initializing them.
>>> int x = 0;
>>> instead of:
>>> int x;
>>
>> That's a /really/ bad idea (unless you actually /want/ x to be 0, of
>> course).  It is bad precisely because it stops the compiler from
>> warning you when you have forgotten to put a real value in the
>> variable.
>>
>> Get in the habit of declaring local variables only when you have
>> something useful to put in them, and initialising them at that point.
>> But if you must declare a variable before you have an initial value,
>> do not artificially initialise it - you are just making it harder for
>> the tools to find your bugs.
> 
> Or initialize it with some recognizably invalid value, if there is such
> a value for the type.
> 
> Leaving it uninitialized helps the compiler diagnose errors.
> Initializing it with recognizable garbage helps with run-time debugging.
> 

That can certainly be better than using a plausible value (and 0 is 
often plausible).  But it is still better to leave it uninitialised 
where possible - if it is not spotted by static error checking, it can 
be spotted by a sanitizer at run-time.

Recognizably invalid or implausible values are particularly good if you 
have an array and will use some of it, but perhaps not all of it.  Such 
cases are very hard for static analysis.

[toc] | [prev] | [next] | [standalone]

#88640

On 1/18/2023 3:30 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 18/01/2023 21:11, Chris M. Thomasson wrote:
>>> On 1/18/2023 12:00 PM, Scott Lurndal wrote:
>>
>>>> Or using uninitialized variables, particularly in
>>>> functions.   Could work for weeks, then the program
>>>> takes a different path and the stack contains a
>>>> value that causes a crash.
>>> True. Well, so far, I don't think I have a problem. MSVC is pretty
>>> good at flagging uninitialized variables, and I have a habit of
>>> always initializing them.
>>> int x = 0;
>>> instead of:
>>> int x;
>>
>> That's a /really/ bad idea (unless you actually /want/ x to be 0, of
>> course).  It is bad precisely because it stops the compiler from
>> warning you when you have forgotten to put a real value in the
>> variable.
>>
>> Get in the habit of declaring local variables only when you have
>> something useful to put in them, and initialising them at that point.
>> But if you must declare a variable before you have an initial value,
>> do not artificially initialise it - you are just making it harder for
>> the tools to find your bugs.
> 
> Or initialize it with some recognizably invalid value, if there is such
> a value for the type.

0xDEADBEEF is a fun one. :^)

> 
> Leaving it uninitialized helps the compiler diagnose errors.
> Initializing it with recognizable garbage helps with run-time debugging.
> 

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web