Programming thread

Also memory is very important to learn [for C programming]. Lean malloc, memset and the dereferencing rules and you pretty much know all the important stuff.
Heh, you left out the most fun part: debugging wild pointers scribbling over memory they shouldn't be touching, as well as other less difficult memory bugs. I gather there's now quite a set of tools that will try to detect this for you, Valgrind is the only one I know by name. If you know or can find out what's getting smashed and roughly when, you can use a low level debugger to set a write breakpoint there and catch it in the act. If you're starting to write a C program from scratch, using a linter from the very beginning might save you a lot of trouble (it's seldom profitable to try to starting linting a codebase of any age, unless it was very well written). For that matter, FOSS compilers are doing a lot more for you nowadays, like Clang and GCC, compile with the maximum tolerable level of warnings.
 
  • Informative
Reactions: A Weddell Seal
Sending out a shot in the dark here - has anyone played around with Visual Studio's CMake integration? I can't get it to stop dumping all the CMake* temp files in my default "My Projects" root rather than with the project they're actually part of. I haven't been able to find much online about this either.
I realize the answer may very well be "CMake in VS is broken".
 
Sending out a shot in the dark here - has anyone played around with Visual Studio's CMake integration? I can't get it to stop dumping all the CMake* temp files in my default "My Projects" root rather than with the project they're actually part of. I haven't been able to find much online about this either.
I realize the answer may very well be "CMake in VS is broken".
I've gotten it working with vscode with these two lines in settings.json
Code:
   "cmake.buildDirectory": "${workspaceFolder}/Build",
   "cmake.sourceDirectory": "${workspaceFolder}/Source",

And I have an old vs project that has CMakeSettings.json in the root directory
Code:
{
  "environments": [
    {
      
    }
  ],
  "configurations": [
    {
      "name": "x86-Debug",
      "generator": "Ninja",
      "configurationType": "Debug",
      "inheritEnvironments": [
        "msvc_x86"
      ],
      "buildRoot": "${projectDir}\\bin\\build\\${name}",
      "installRoot": "${projectDir}\\bin\\install\\${name}",
      "cmakeCommandArgs": "",
      "buildCommandArgs": "-v",
      "ctestCommandArgs": ""
    },
    {
      "name": "x86-Release",
      "generator": "Ninja",
      "configurationType": "RelWithDebInfo",
      "inheritEnvironments": [
        "msvc_x86"
      ],
      "buildRoot": "${projectDir}\\bin\\build\\${name}",
      "installRoot": "${projectDir}\\bin\\install\\${name}",
      "cmakeCommandArgs": "",
      "buildCommandArgs": "-v",
      "ctestCommandArgs": ""
    }
  ]
}
Not sure if it's applicable anymore though, IIRC cmake support was experimental at the time and didn't work very well anyway lol
 
Right, VS will automatically create that JSON if it doesn't exist. (I'm not using VS Code so I'm not sure if those settings you mentioned have an exact equivalent)
I'm leaning at this point toward the conclusion that the greybeard-soybeard alliance behind CMake just assumes this will always be run from a command line where "current directory" has a direct relationship to the file you're processing.
 
Right, VS will automatically create that JSON if it doesn't exist. (I'm not using VS Code so I'm not sure if those settings you mentioned have an exact equivalent)
I'm leaning at this point toward the conclusion that the greybeard-soybeard alliance behind CMake just assumes this will always be run from a command line where "current directory" has a direct relationship to the file you're processing.
>not using the command line
You have only yourself to blame.
 
I just spent like ninety minutes pulling my hair out over a database issue. It seemed like if I made a small change to the query I was trying to build, it would return wildly different and broken results. I had gotten to the point where I had chalked it up to a bug in the database driver and was trying to reform the query in a way to work around the bug, but nothing was working.

Finally I got up to take a piss, and it was then, standing there with my stream of urine bubbling in the toilet, that the possible cause came to me. I went back to my laptop, checked my code again, spotted the bug - of course it was in my code - and rebuilt the project. Bam, perfect results.

It's something I knew before, of course, but sometimes it helps to be reminded; when you've hit a wall and you're on the verge of tears, staring at your code for even longer will usually get you nowhere. You need to step away from the computer and take a walk, go out for lunch, explain the problem out loud or in writing to another person or object (rubber ducking), or just do something else AFK while still thinking about the problem. Something about that jogs your brain into thinking about the problem a different way and often the solution will present itself like magic. It seems counterintuitive to solve a computer problem by getting away from the computer for a while, but often it works.
 
Hey, got some programming employment related questions, and I figured this is probably the best place to ask:

1. Anybody have experience with job offers contingent on passing a background screen (like through HireRight)? I submitted all the background check info at the beginning of last week, but still haven't heard anything back yet. There's no massive skeletons in my closet, but it's a bit nerve racking.

2. I've never done a panel interview before, and I have one coming up next week and I feel a bit nervous. Any tips or ways I should prep? First half of the panel interview will be with senior management, second half will be with some senior SWEs.
Sorry to "Dear Diary" shit this thread up, but the video call panel interview was a shitshow (but not because of anything I could have done), as in panel members were cutting each other off and arguing during the interview. That, and lots of other red flags told me that the company was trying to put out some massive fires they have on severely blown deadlines by hiring more staff, so I'm thankful the interview didn't go great.

The positive news is that the background check for the other job came back clear, so I'll be starting a job that will be a 75% increase in total compensation over my old job, along with 5 weeks PTO and lots of other goodies. So things turned out pretty great.

Back on topic, anybody else 'attending' the .NET Conf today?
 
With C, the most important things are thus:
Function pointers (For polymorphism)
Prototyping structs so they can reference themselves in internal declarations
The void pointer which can be cast to anything (polymorphism 2)

Also memory is very important to learn. Lean malloc, memset and the dereferencing rules and you pretty much know all the important stuff.
Honestly just read 'Expert C programming - deep C secrets', it'll tell you everything important, pdf related
 

Attachments

  • Like
Reactions: Wünderkind
Anybody ever interview at companies they don't want to work at just to get practice in being interviewed?

I've held a steady tech job for almost 10 years now. Down side of that is that I don't even remember what being interviewed is like and I'm scared to death by it. I know my stuff but I get locked up when I'm anxious.
 
Anybody ever interview at companies they don't want to work at just to get practice in being interviewed?
Considering I find job interviews to be about as fun as taking an aluminum baseball bat to the ear, no.

My best advice is to be ready to respond to the common questions. What's an interesting problem that you've had in your career and how did you solve it? When's a time you had conflict with co-workers and how did you solve it? What would you do if you were assigned a project you didn't have the time or knowledge to accomplish by yourself? How do you approach learning a new programming language or framework? Have you ever led a team of other developers? Write down answers to these sorts of questions on paper and try to memorize them so you can easily refer to them later, not word-for-word but at least the gists - you don't want your answer to be robotic but at the same time you want to have something competent-sounding to answer with quickly. I mean, I guess lots of "practice" will give you a hint as to what sorts of questions will be asked, but still, I'd rather not waste my time going through an interview if I didn't really want the job.
 
I've held a steady tech job for almost 10 years now. Down side of that is that I don't even remember what being interviewed is like and I'm scared to death by it.
I've held a series of tech jobs over 15 years now and if I wanted to move on I've got a list of friends I can call up who'd love to work with me or get me into another team in their company somewhere. I'd barely have to interview, perhaps there might be some technical interview formality or chat with a future manager in some cases. If you have a good think, perhaps you can do the same - who's left your company lately who you think you impressed for example?

I couldn't imagine trying to get into a company via the recruiting page any more. I'd trawl linked in and get one of my contacts to introduce me to someone who can make things happen.
 
I finally found the source of a heisenbug I'd been hunting for a day. Shit was disturbing initially, I'd made a custom dictionary type, and every run the dictionary contents changed order and the issues occurred in arbitrary places, so I assumed it was some kind of heinous data race, because the inputs were the same each time. A data race made no sense however, because the application was running single threaded at the point where the issues occured.

Things got even weirder though, because the bug only occurred when using strings as input. Eventually I figured out that .Net salts it's string hashes and the salt changes each run, so eliminating that randomness I was able to see exactly where things went wrong. Turns out an old part of the codebase was using subtraction to compare hashcodes, and that was randomly producing invalid comparisons. Honestly I didn't bother to check specifically why that was going wrong —I just fixed it and moved on— but I presume it was occasionally overflowing.

Now to fix the other issues downstream of this problem (:_( TFW fixing this didn't effect the downstream issues and I have no idea where to start
 
I have to ask: why??
The .Net IComparer interface looks like this int Compare(T a, T b). You can then compare the result to zero to extract the specific ordering relationship. Really it's just a generic way to compare objects, like C++'s new spaceship operator.
Subtraction does the same thing so long as it doesn't overflow lol, and if I'd just cast to long before doing the subtraction and cast back after and it would have worked too.
 
The .Net IComparer interface looks like this int Compare(T a, T b). You can then compare the result to zero to extract the specific ordering relationship. Really it's just a generic way to compare objects, like C++'s new spaceship operator.
Sure, but on a hashcode? Why wouldn't this just be done with whichever of .NET's 20 billion variants of IEqualityComparautism is recommended this week? Why would you try to order them?
 
  • Like
Reactions: Besachf Jhakut
Sure, but on a hashcode? Why wouldn't this just be done with whichever of .NET's 20 billion variants of IEqualityComparautism is recommended this week? Why would you try to order them?
Why not?
 
Sure, but on a hashcode? Why wouldn't this just be done with whichever of .NET's 20 billion variants of IEqualityComparautism is recommended this week? Why would you try to order them?
The simplest dictionary is just a sorted array, hence why I was surprised that's where the error was coming from! The parts surrounding it are much more complicated, and it's so simple how could it possibly fail?
As to why subtract instead of using a standard library function, a subtraction has a known cost, and a low one at that. These days I just check the standard implementation with ILSpy or something, and usually it's fine. I really do wish the .Net standard library had more specialty collections.

Edit; Also I figured out why the downstream wasn't working; I was using the presence of a key in a dictionary to determine whether the partial ordering model for a job had been built, but I was reserving entries preemptively when a job was referenced as a dependency of another job, causing the system to mistakenly think the model had already been built. A little bit twiddling here and there and it's all working! It's faster than I'd worried it might be too.
 
Last edited:
  • Thunk-Provoking
Reactions: Dick Justice
Back