Spartan-S63

For quite some time now, my PC has hard locked and the only way to recover is to force a reboot. Nothing shows up in the Windows event viewer other than an event caused an unexpected restart. There's no rhyme or reason to these hard locks, either. Sometimes it'll take the PC being booted for two weeks to have one happen, sometimes a hard lock will happen fifteen minutes after a reboot. I can't figure anything out definitively as I'm at a loss for diagnostic information. For background, the RAM is in the qualified vendor list (Corsair Vengeance LPX) for the motherboard. The GPU and motherboard have both been RMA'd once before. The GPU died and the motherboard died, as well. Both are replacement parts from ASUS. When the hard lock happens, the Q Code LED readout reads "04" which indicates "PCH Initialization before Microcode" though I'm not sure if that code means anything significant as it is since the LED changes while the computer is booted up. Machine specs: PSU: EVGA SuperNOVA 700 G2 Mobo: ASUS Maximus IX Forumula CPU: Intel i7 7700k CPU: Asus ROG Strix 1080 Ti RAM: 32GB (4x8GB) Corsair Vengeance LPX 2400Mhz Storage: 500GB Samsung 950 EVO NVMe, 256GB Samsung 830 Pro, 960GB Sandisk SSD, 2TB Toshiba 7200 RPM I've done extensive troubleshooting. I've done the follow: RMA'd the motherboard, ASUS said it was fine RMA'd the CPU, no change Ran Memtest86 and seen no errors with all sticks of RAM and each stick individually Removed two sticks of RAM in hopes that one of the sticks is faulty, still resulted in a hard lock Swapped power supplies to see if that was the issue, no change At this point, the only two things I can think of that might be the culprit is the GPU or the the RAM (and try with a different RAM kit). Does anyone have any advice on what to try next? Thanks!

Like Ciccioo said, we're going to need more code. But just shooting in the dark, I'd say that your buildTree() function is actually the culprit, but I'm not sure because we need more code.

No, there really isn't. At least not one I know of.

You would need a conditional statement using hasNextInt(), if it does have a next int, you can then assign it, but you likely won't because of the way input works in Java. Try my code snippet and tell me if it works.

Right, because it isn't doing quite what you want it to. I'll show you another example that does do what you want it to. You need to parse the integer within the scanned input using the Integer wrapper class, like so: import java.util.Scanner;public class main { public static void main(String[] args) { Scanner in = new Scanner(System.in); String strLength; int length; boolean finished = false; while (!finished) { System.out.print("Enter the length: "); strLength = in.nextLine(); // or in.next() if each integer isn't on its own line try { length = Integer.parseInt(strLength); finished = true; } catch (NumberFormatException nfe) { System.out.println("Input wasn't an integer! Try again?"); } } }} As you can see, this method removes the need to catch the InputMismatchException but it adds a NumberFormatException from the Integer.parseInt() method. This should work exactly as you want it to.

Changing the code to something like this, will alleviate the problem: import java.util.Scanner;public class main { public static void main(String[] args) { Scanner in = new Scanner(System.in); int length; boolean finished = false; while (!finished) { try { System.out.print("Enter the length: "); length = in.nextInt(); finished = true; } catch (InputMismatchException ime) { System.out.println("Couldn't read your input. Try again?"); } } }} In the event of an exception in in.nextInt(), the flow will travel to the catch block and not set finished equal to true and will result in the loop beginning again until good input is sent in. However, this may still not give you what you want.

I'm not sure how .NET developers create products that are "easily shared" or particularly "mobile." .NET is Windows specific (yes, Mono exists, but isn't in widespread use). .NET is really only wanted in companies that employ Microsoft software. If you want to lock yourself to one ecosystem, .NET is a good choice. But if you want to be able to work anywhere, it's better to write your business logic in a shared code base and just attach a native GUI to that interface to make things "easily shared." You are correct here. C++ only makes you pay for the features you use. If you were to compile plain C code with a C++ compiler, you would likely get identical (or very close to identical) performance from the C code compiled by a true C compiler. C++ does incur overhead when you begin to use abstractions, but that's part of the reason why people use C++. It affords the same low level capabilities as C, but allows you to use higher level abstractions. Definitely look into smart pointers (unique_ptr and shared_ptr) because they reference count the allocated memory and automatically dispose of it. This is called RAII or Resource Allocation is Initialization. It's an alternative to classic GC (which C++ DOES NOT have) and even works with file handles.

Just make sure that when you learn C++, you write idiomatic C++. Idiomatic C is not the same as idiomatic C++. The idioms are quite a bit different. You'll commonly see pointers that are void* or casts like (int)someVar. You should never do either thing in C++. That's why I encourage people to learn C++ before they learn C. C is pretty much a subset of C++, but it has more elastic idioms. So learning a more restrictive language like C++ first actually builds better habits rather than doing the opposite. Learning C first can actually result in writing pretty poor C++. While Go may be good for performance, it's a garbage collected language. GC has its own unique problems. It's more of a hassle, but sometimes safer to pick a language that requires that you manually manage your memory, or one with RAII (such as C++ or Rust). If you're interested in a newer language, definitely check out Rust. It blows Go out of the water and it allows you to do a lot of things you can do in C++. It's still in its infancy so it has some performance issues, but it uses LLVM as the back-end so it benefits from some pretty good optimizations. It's shown to match C++ in quite a few benchmarks.

It depends on what version of GCC/g++ you're using. If you're using an older version (pre 4.8, IIRC), it's likely that the standard library that ships with GCC doesn't support the multithreading libraries in C++11's STL. Check which version of GCC is installed and reply back here. Also, tell me what operating system you're using.

If you're talking concepts, you don't even need to touch a real language then. Why not play with pseudocode to learn these concepts? Memory management is only teachable in a language that has manual memory management which really narrows down the options to C or C++ which then comes back to my point I made about bad programming habits and things. So I really fail to see your argument here.

I would argue it's actually detrimental to learn C before C++ because even though C and C++ are interchangeable, C teaches bad C++ habits. The biggest that come to mind is the unneeded malloc() calls in C++ (new and delete, respectively, or unique_ptr and shared_ptr in C++11) and C-style casting, not to mention the void* data type. In C, given kernel-level development, it makes sense to have void* but in a general purpose application, you better not be using that. And the C-style cast is dangerous in C++. Instead you should be using static_cast, dynamic_cast, reinterpret_cast, and const_cast. C-style strings are also deprecated in C++. Sure, the std::string class is just a wrapper for C-style strings, but it makes it a ton easier to manipulate and work with strings in an abstracted way. Another thing is the difference between cout and printf. Printf is unsafe, cout is just better as far as type enforcement and overflow is concerned. Same goes for scanf and cin. Not to mention streams are infinitely better than "scanned" input because you don't have to take in words. It makes processing binary data THAT much easier (especially if you're messing with endianness as well). There are just far too many benefits to learning C++ first, that learning C first if C++ is your goal doesn't make any sense anymore.

I'm going to chime in on my own opinion from programming for many years and working two years professionally as well as starting my undergrad in computer science. I would recommend you start learning C++, not C, not Java, not Python, but C++. The reason why is because C++ is a modern language, teaches good habits, educates you about memory management and lower level optimization while offering the higher level abstractions that Java does as well as mixed paradigm programming (OO and non-OO, which in my opinion is important because purely OO languages are fundamentally flawed because not everything fits in an OO hierarchy). I recommend against C because it has a more niche purpose in system-level programming (kernels, integrated systems, etc) anymore. It's not old by any means, but C++ is a better general purpose language for most jobs. See my above comments about C++. On top of those, Java is cross-platform, but it's fundamentally slower and abstracts memory management, which is crucial to learn first before you learn higher level languages. It's harder to learn those lower level concepts from moving downward. It's important to build a solid base of skill in lower level languages before moving up in level of abstractions. I wouldn't recommend Python. The syntax is pretty confusing, to be honest, and it's another interpreted language. I would only recommend learning Python after learning C++ and Java. Refer to my original two parts, C isn't where you should start. Java qualifies as a high level language. It hides a TON of stuff. C++ would be better because it hides as much as you want it to hide.

I know this questions has been answered, but I'm just going to leave a little bit extra here. I've read through some of the responses and a couple pieces of advice I want to give you is that if your ultimate goal is to learn C++, don't learn C first. C is older and has a different idea of how code should be written. While C and C++ share a common subset, C++ is vastly different, especially with the new C++11 standard. That being said, do not worry about the tools you're using to write code. XCode is simply an IDE on Mac OS X just like Visual Studio is an IDE on Windows. Any code written in either IDE can be opened in the other so collaboration isn't impossible. Another big thing that people have told you that just isn't true anymore is that C# is a Windows-specific language. While it's true that Microsoft did create C#, it's not longer tied to one platform. Through the use of the Mono framework *nix operating systems can now run C# code. It does take a little work to port the code, but you can now write multiplatform C# code.

No, the second OS isn't installed yet. It would be some distribution of Linux. The reason why it isn't installed yet is because I can boot off installation media, however, it quits reading from the media and just hangs on a black screen.

I was wondering if any of you owned an MSI GS70 if you had any luck with dual booting a second operating system. I'm having a hard time getting it to boot from removable media. I try booting with both an external disc drive and a USB flash drive, but it quits reading from it after a short time of getting past a GRUB boot menu. I'm at a loss and was wondering if anyone else had any advice or experience with the problem.