Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Unimportant

Member
  • Content Count

    1,219
  • Joined

  • Last visited

Reputation Activity

  1. Agree
    Unimportant got a reaction from straight_stewie in Creating a memory error   
    On x86 it causes a machine check exception, for which the OS can install a handler. Windows will typically display a blue screen (which is still better then unknowingly working with possibly corrupted data). But on mission critical systems the OS/application could attempt recovery.
  2. Agree
    Unimportant got a reaction from gabrielcarvfer in Creating a memory error   
    On x86 it causes a machine check exception, for which the OS can install a handler. Windows will typically display a blue screen (which is still better then unknowingly working with possibly corrupted data). But on mission critical systems the OS/application could attempt recovery.
  3. Informative
    Unimportant got a reaction from Sauron in Creating a memory error   
    On x86 it causes a machine check exception, for which the OS can install a handler. Windows will typically display a blue screen (which is still better then unknowingly working with possibly corrupted data). But on mission critical systems the OS/application could attempt recovery.
  4. Agree
    Unimportant got a reaction from Eigenvektor in I FOUND THE BUG [C++]   
    @BuckGupWhat exactly is the problem. How exactly to replicate ?
     
    Have you compiled with all warnings enabled. It spits out quite a few things. Quick look also shows there's a memory leak.
  5. Informative
    Unimportant got a reaction from BuckGup in Read Tab-delimited File Into Object [C++]   
    @BuckGup All the above examples don't incorporate any possible error checking such as failure to extract a line from the file other then eof and file formatting errors. That's why you're getting bogus values, it's probably hitting some error and marching on. Here's a proper example:
    #include <iostream> #include <fstream> #include <string> #include <sstream> #include <vector> #include <stdexcept> struct Job { int pid; int burst; int arrival; int priority; }; void ReadJobs(std::istream& is, std::vector<Job>& jobs) { auto lineNumber = 0; while (1) { ++lineNumber; //Read a line. std::string line; std::getline(is, line); //Check if stream still valid. if (!is) { //If not, check for eof. if (is.eof()) { //Invalid stream, but eof => reached end of file. return; } else { //Invalid stream, but not eof => some technical error. throw std::runtime_error("Error retrieving line " + std::to_string(lineNumber)); } } //Parse line. Job job; std::stringstream ss(line); ss >> job.pid >> job.burst >> job.arrival >> job.priority; //Check stringstream state still valid. if (!ss) { //Invalid stringstream => file format error. throw std::runtime_error("Formatting error on line " + std::to_string(lineNumber)); } jobs.push_back(job); } } int main() { //Open file as ifstream. std::ifstream infile("input.txt"); if (!infile.is_open()) { std::cout << "Failed to open file!\n"; return 1; } std::vector<Job> jobs; //Read jobs from file. try { ReadJobs(infile, jobs); } catch (std::runtime_error& e) { std::cout << e.what() << '\n'; return 2; } //Print jobs. for (const auto& job : jobs) { std::cout << "Pid: " << job.pid << '\n'; std::cout << "Burst: " << job.burst << '\n'; std::cout << "Arrival: " << job.arrival << '\n'; std::cout << "Priority: " << job.priority << "\n\n"; } return 0; } It assumes there's no header in the file, so remove the:
    Pid Burst Arrival Pri line from the input file.
     
    If you really want that line in the input file, or perhaps even check if it's there to validate the file, then report back for modified code.
  6. Informative
    Unimportant got a reaction from BuckGup in Read Tab-delimited File Into Object [C++]   
    std::getline simply returns the stream you give it as input, it does not return a bool. By testing for bool you're employing the returned stream's bool operator, which evaluates to false if the stream is in a invalid state. That does not tell you *why* it's in a invalid state. Could be eof, could be a failure due to a network drive being down, or a bad sector on your harddisk. You need to separate between eof and technical errors.
     
    And no, no lines are being tossed away. This is a common error when working with c++ streams. When eof is set (or any other error) the read has failed and thus nothing was read. If you process the data first before checking eof you actually add a bogus line. The only correct way is: read, check stream state and take approriate action, process data if stream still valid.
  7. Like
    Unimportant got a reaction from Eigenvektor in Read Tab-delimited File Into Object [C++]   
    @BuckGup All the above examples don't incorporate any possible error checking such as failure to extract a line from the file other then eof and file formatting errors. That's why you're getting bogus values, it's probably hitting some error and marching on. Here's a proper example:
    #include <iostream> #include <fstream> #include <string> #include <sstream> #include <vector> #include <stdexcept> struct Job { int pid; int burst; int arrival; int priority; }; void ReadJobs(std::istream& is, std::vector<Job>& jobs) { auto lineNumber = 0; while (1) { ++lineNumber; //Read a line. std::string line; std::getline(is, line); //Check if stream still valid. if (!is) { //If not, check for eof. if (is.eof()) { //Invalid stream, but eof => reached end of file. return; } else { //Invalid stream, but not eof => some technical error. throw std::runtime_error("Error retrieving line " + std::to_string(lineNumber)); } } //Parse line. Job job; std::stringstream ss(line); ss >> job.pid >> job.burst >> job.arrival >> job.priority; //Check stringstream state still valid. if (!ss) { //Invalid stringstream => file format error. throw std::runtime_error("Formatting error on line " + std::to_string(lineNumber)); } jobs.push_back(job); } } int main() { //Open file as ifstream. std::ifstream infile("input.txt"); if (!infile.is_open()) { std::cout << "Failed to open file!\n"; return 1; } std::vector<Job> jobs; //Read jobs from file. try { ReadJobs(infile, jobs); } catch (std::runtime_error& e) { std::cout << e.what() << '\n'; return 2; } //Print jobs. for (const auto& job : jobs) { std::cout << "Pid: " << job.pid << '\n'; std::cout << "Burst: " << job.burst << '\n'; std::cout << "Arrival: " << job.arrival << '\n'; std::cout << "Priority: " << job.priority << "\n\n"; } return 0; } It assumes there's no header in the file, so remove the:
    Pid Burst Arrival Pri line from the input file.
     
    If you really want that line in the input file, or perhaps even check if it's there to validate the file, then report back for modified code.
  8. Funny
    Unimportant got a reaction from kapa12 in Costume keyboard question   
    "Costume keyboard"
     

     
    (Sorry, couldn't resist xD)
  9. Funny
    Unimportant got a reaction from Prodigy_Smit in Costume keyboard question   
    "Costume keyboard"
     

     
    (Sorry, couldn't resist xD)
  10. Like
    Unimportant got a reaction from trag1c in C++ Undefined symbols for architecture x86_64 on CMake   
    Still not agreeing, sorry.
    Signed allows for faster code, as signed overflow is undefined and opens up a whole suit of optimization options.
    The difference between 2 offsets/indexes can be negative.
    In C++ we have stuff like range based for loops and STL functions that can (should) replace many loops.
     
    We've had to fix far too many bugs over the years because of this. Disagreeing with Stroustrup, Herb Sutter and Chandler Carruth reeks off exactly the over-confidence that'll get you caught in a really bad spot one day.
     
    Again, the main issue here is that unsigned does not model numbers that cannot be negative, it models modular arithmetic. Like Carruth says in the video, when is the last time you wanted modular behavior? There are literally *no* upsides to using unsigned over signed, only downsides, why make life hard for yourself?
  11. Informative
    Unimportant got a reaction from shadow_ray in C++ Undefined symbols for architecture x86_64 on CMake   
    @AluminiumTech Template arguments must be constexpr since templates are "expanded" at compile time.
    @gabrielcarvferNo! Don't use unsigned except for very special reasons such as bit manipulation. Always always use signed , I explained in detail in this post : https://linustechtips.com/topic/1082025-c-variable-storage-size-bytes/?do=findComment&comment=12727003
     
  12. Agree
    Unimportant reacted to gabrielcarvfer in C++ Undefined symbols for architecture x86_64 on CMake   
    Could you try moving the template functions to the header file? They will then be loaded into each file (compilation unit) they're included, the template will get specialized and everything should work.
     
    I think you could also specialize the template by calling it after each class definition for every header of the classes you're making based on it.
     
     
  13. Agree
    Unimportant got a reaction from wanderingfool2 in convertion error on C function   
    That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns.
     
    A solution would be to pass a pointer to str to the function for it to use.
  14. Agree
    Unimportant got a reaction from Sakuriru in convertion error on C function   
    That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns.
     
    A solution would be to pass a pointer to str to the function for it to use.
  15. Agree
    Unimportant got a reaction from AbydosOne in convertion error on C function   
    That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns.
     
    A solution would be to pass a pointer to str to the function for it to use.
  16. Informative
    Unimportant got a reaction from Coldblackice in Could you make your own PCIe extension?   
    @W-L is right, but for more reasons then just noise. At the speeds PCIe is using, 250MHz - 1.25GHz, things behave differently compared to your average LF circuit. You get transmission line effects , such as reflection . this requires careful matching of the transmission line's characteristic impedance . One way to achieve this is by using striplines .
     
    Shielding isn't some magic bullet against noise, perhaps even the opposite if improperly used. In order to increase noise immunity differential signaling is used, which requires matching the lengths of the conductors in each differential pair so the loop lengths match and the noise pickup is equal between them. At these speeds even the speed electricity travels at plays a role. Matching the lengths of the conductors can be required to assure all the bits arrive at the same time. If you've ever seen traces on a motherboard snake around for no reason and wondered why, now you know.

     
    I could go on but I think the point is made. Implementing these techniques is impossible with just plain wires, which is why most decent commercial extension cables come in some form of printed flat flex or similar.
     
    Additional source for those interested: https://www.nxp.com/files-static/training_presentation/TP_HARDWARE_DESIGN_PCI_SMGIII.pdf
  17. Like
    Unimportant got a reaction from porina in Is modern ram less reliable?   
    With RAM sizes increasing constantly, the statistical error chance rises with it.
    If you double your RAM there's now twice as many bits to possibly go faulty.
    Now, of course the manufacturing technology improves as well and increases the reliability of the produced parts.
    However, do you think it realistic to improve reliability at the same rate as size increases ? It isn't.
     
    So yes, statistically, RAM is becoming more unreliable with size increases outpacing manufacturing improvements.
  18. Agree
    Unimportant got a reaction from straight_stewie in Programming 101   
    I'd say the low level stuff.
     
    There's an abundance of ever more abstract languages, further and further removed from the hardware, and the accompanying programmers who know less and less about how things work under the hood.
     
    That's nice and all but what I see regularly:
    Their abstract machine fails in some way or the other -> they're clueless about what to do next. Less and less people in the fields that actually design and build the underlying systems these languages run on. And as a result, those who do have this knowledge can eat all the other's lunch.
  19. Like
    Unimportant got a reaction from Hackentosher in will my circuit work?   
    I think you've got your terminology mixed up. A FET can be controlled in it's linear region, just as a BJT. And that IS analog. The linear region simply means it's neither fully on or fully off but somewhere in between, just allowing the required amount of current to flow. It's PWM that isn't linear (the switching device is either fully on or fully off) and can be seen as more digital rather then analog.
     
    However, using a FET in it's linear region is rare(*) because the key feature of a FET is that it has (can have) a very low on resistance, making it an excellent switch that dissipates little power when fully on. By using it in it's linear region it would dissipate power anyway and a much cheaper BJT can be used instead. 
     
    (*) It can have it's uses tough if the application demands a voltage controlled transistor rather then current controlled.
  20. Like
    Unimportant got a reaction from Kilrah in Recaping how to?   
    Both ESR and capacitance measurements are influenced by any circuits in parallel to the capacitor under test, so it's best to remove them and measure them out of circuit. He's right in that if you've removed them anyway why not just replace them?
  21. Like
    Unimportant got a reaction from Hackentosher in Recaping how to?   
    Both ESR and capacitance measurements are influenced by any circuits in parallel to the capacitor under test, so it's best to remove them and measure them out of circuit. He's right in that if you've removed them anyway why not just replace them?
  22. Agree
    Unimportant reacted to Kilrah in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    Yep, commonly referred to as Polyswitch
    https://www.littelfuse.com/products/polyswitch-resettable-ptcs.aspx
  23. Agree
    Unimportant got a reaction from Kilrah in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    Nah, this is actually a nice example of the Dunning Kruger effect, where someone has too little knowledge about a subject to be able to realize how little he/she knows.
     
    I'm not trying to discourage someone from learning and trying to build whatever he/she wishes but I think it's healthy to make them realize they're embarking on climbing a mountain, not the molehill their flawed perspective makes it out to be.
  24. Agree
    Unimportant got a reaction from Hackentosher in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    A 'scope with the bandwidth to make eye diagrams at pcie frequencies (to check signal integrity for your layout) cost as much as a nice car... 
  25. Agree
    Unimportant got a reaction from Kilrah in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    A 'scope with the bandwidth to make eye diagrams at pcie frequencies (to check signal integrity for your layout) cost as much as a nice car... 
×