Unimportant

Don't use naked new/delete. Read up about std::unique_ptr, then incorporate it into your code and all your errors (i.e. copy ctor does not deep copy, etc...) Will automatically become apparent if you carefully read the compilation errors.

9 hours ago, BotDamian said:

I'm sure I can grasp and have grasped way more than you.

Clearly you haven't. Your refusal or inability to think outside the box is obvious, you're solely focused on the energy usage by the mining, any and all side-effects be damned.

I know people in Turkey who recently bought a new car. Not because the old one was worn or defective, heck, it wasn't even that old. But because of the 10%+ inflation rate over there you need to spend your money on something, anything, because if you hang on for it for a while it's value is gone...

So their decision to save (and don't think saving money, but think saving what that money represents: commodities, labour, energy) is diverted into wasteful spending, replacing a perfectly fine car, because of monetary concerns.

This is happening all over the world, to a more or lesser degree, negative real interest rates are practically everywhere, discouraging savings and encouraging wasteful spending, often even on credit.

This is wasteful by definition because, normally, one buys what one needs and wants first and then saves what is left over. So if people are pushed towards spending over saving they're literally buying stuff they neither really want nor need.

This is a fundamental requirement of a fiat monetary system: endless growth (only nominal if need be) is required to service the debts, contraction cannot be allowed to happen. If humanity suddenly would be happy with only consuming half of what it is consuming now (which would be awesome for the environment) governments and central bankers would be tripping over each other with new programs to stoke spending and inflation, because any nominal contraction can not be allowed.

The waste caused by this dwarfs whatever mining uses. Bitcoin is a attempt at fixing this. Weather it'll work or not, or even survive no one knows, but we should give it a chance. It's only 10 years old and exceeded the wildest expectations.

Then I'm not even talking about the energy usage of millions of bankers around the world in their skyscrapers, offices, and everything around it. Again, because the perverse effects of a fiat money system throughout an entire economy dwarf narrow minded thinking like this.

You nor anyone else can know what is superior : PoW or PoS, that is for the market and participants to decide. What if there is some fatal flaw or side effect to PoS that has not come to light yet?

I hope that I've peaked some of the more open minded and curious people's interest enough with this to go do their own research. That's all I can hope for so I won't respond here any further. There's no hope for those with a closed mind anyway.

13 hours ago, Eigenvektor said:

The total energy used world wide would've been reduced by whatever has been used by Bitcoin.

12 hours ago, BotDamian said:

I assume that you mean that someone would use the GPUs to play games right?

No, I'm literally talking about energy that would otherwise been wasted, such as hydro or wind power that is generating more energy then is consumed locally. That water is still going to fall and that wind is still going to blow, weather you use that energy or not. It's those things bitcoin miners flock to because it's cheap energy, and mining can easily be moved towards the energy source.

Quote

In the case of green-energy solutions such as wind farms and solar, it is often very difficult to store or even sell that energy if the supply outweighs demand.

...

Simply put, countries that attract cryptocurrency miners with cheap electricity can do so because the supply greatly outstrips the demand. Cryptocurrency mining plays an important role in normalizing international energy markets by consuming power that would otherwise go to waste.

(source: https://thenextweb.com/news/bitcoin-drives-energy-innovation)

13 hours ago, Eigenvektor said:

What is relevant is energy/transaction (i.e. efficiency), not total energy. Bitcoin uses more energy to achieve less, so it is fair to say it wastes energy compared to other competing systems.

12 hours ago, BotDamian said:

People like you are the problem honestly, you barely put any thought into it and spreading fake info and rumors.

I'm not going to debate this. Those with an open mind and curiosity can research this on their own and see how far the rabbit hole takes them.

I'm talking about much deeper issues then you seem able to grasp. Like how an inflation based monetary system requires endless growth or else it collapses.

So while you're stuck calculating how much watts are spent for a transaction, I'm talking about how a monetary system can shape an entire society towards being either frugal or towards debt based wasteful spending.

There's also a couple hundreds of million people on this planet that are financially oppressed and have no access to a banking system that are being uplifted by bitcoin who would like a word with you. But who cares about them, right? 

Just some toughts I wanted to add:

1) The entire "proof of work (bitcoin) wastes electricity" thing is overdone, lots of the electricity used by bitcoin mining would've gone to waste anyway because of various reasons. 

2) When comparing the waste of a system, be fair, and compare it to the waste of the competing system. Our current inflation based fiat monetary system encourages massive waste by design.

Can't find that code but it looks like a half-bridge so it's probably a N-channel MOSFET.

You might get away by replacing it with a similar device with the same pinout if you deduce voltage and current requirements.

Measure if the pads of the broken cap are in parallel to the caps next to it, which is likely. If it is then it'll work fine without the capacitor.

19 hours ago, Shir0u said:

I want to know why VarNameException is made instead of just making and try ()throw and catch and have all the error cases distinguished at the catch step. Thank you.

Think about *how* different errors are distinguished at the "catch step". You differentiate by type:

try
{
	//Something...
}
catch (FileException& e)
{
	std::cout << "A operation on a file failed: " << e.what();
}
catch (LogicException& e)
{
 	std::cout << "A logic error occured: " << e.what(); 
}
catch (VarNameException& e)
{
 	std::cout << "A VarNameException occured: " << e.what(); 
}
catch (...)
{
 	//unknown exception 
}

Thus, in order to be able to catch a specific type of exception, you must create a new type for the exception. And a type in C++ is basically a class.

@bindydad123 google for "liquid electrical tape".

On 3/5/2021 at 6:09 PM, RTX 3090 said:

Hi, just wanted to ask a question

What is the easiest library to use to communicate with a COM port in C++. I am making a UI for a multimeter, which gives the following COM input

id_x: is the id of the probe, so you can measure multiple voltages at once. The number after that is the volts in this case 0.56

What I need to do is read the COM line, display the voltage in a GUI which I will make in qt designer, and then read the next line, and keep repeating and updating the voltage. I will also have other ID's e.g. for resistance, so I need to read the serial output from the COM port, but all the libraries I have found online look complicated and I want to know which one will be the easiest to implement. Thanks (btw I'm making the application for Windows)

For windows, the WIN32 api has supported COM ports since nearly forever:

https://www.xanthium.in/Serial-Port-Programming-using-Win32-API

https://docs.microsoft.com/en-us/windows/win32/power/system-wake-up-events

I'd look for the AC coupling capacitors on the amplifier output. (between the amp and each speaker). Replace those first and give it a try. If they are indeed the culprit it might be wise to recap the whole thing.

1 hour ago, Sauron said:

Just out of curiority (the wikipedia page doesn't mention this), is this because ECC ram detects the error and shuts down the system? Bit flips on their own may or may not cause a system crash

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.

@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.

3 hours ago, wanderingfool2 said:

So admittedly, I missed that you had a if(!is) before the EOF...but the statement still stands (just doesn't occur every time)...under your exception handling the last line can be tossed away.

No, it can't.

if (!is)
{
	/* We only get here if the stream state is invalid, which can be caused by:
	eofbit
     	badbit
       	failbit
       	(operations that try reading past the end file fail, and thus eofbit and failbit are set together.)
       	Whenever one or more of these error bits are set the read operation failed AND NOTHING WAS READ! (so there is nothing to toss)
        We don't know which if these bits are set yet, only that the stream is invalid, so now we need to distingish between
       	eof and genuine errors.
	*/ 
	if (is.eof())
	{
		/* if eofbit set, we reached the end of file and we're done. */
		return;
	}
	else
	{
		/* if eofbit NOT set, it means failbit and/or badbit are set, WITHOUT eofbit, which indicates a genuine error. */
		throw std::runtime_error("Error retrieving line " + std::to_string(lineNumber));
	}
}

3 hours ago, wanderingfool2 said:

You can get eof with the failbit error, at which point your last result gets tossed.

Operations that attempt to read past the end of file fail, and thus eofbit and failbit are always set together on eof. (but failbit can be set without eofbit on other errors)

No, the last result is not tossed. Whenever a error bit gets set the read operation failed and NOTHING WAS READ (so there is nothing to toss).

3 hours ago, wanderingfool2 said:

As a note as well, if you have an input file with 1 line on it "1 2 3 4", EOF does get set before the stream becomes invalid and it does get set on the first readline call. 

No it doesn't. if eofbit gets set then the stream is invalid. If any of the eofbit, failbit or badbit are set the stream is invalid. You can't have eofbit AND a valid stream. And no, it does not get set on the first readline call. The first readline call will read the single line, NOT set eof, and the stream state will be valid. The second readline call will fail with eofbit and failbit set and the stream state will be invalid.

3 hours ago, wanderingfool2 said:

Checking for EOF is not a reliable way of distinguishing whether "technical error" had occurred.

The check for eofbit in my code is made inside the block that only executes if the stream state is invalid in which case a eof check IS reliable, as explained in point 1.

3 hours ago, wanderingfool2 said:

..because it is decently simple to add in error checking into the loop that was provided.

    while (std::getline(in, line)) {
        std::istringstream is(line);
        if(!(is >> myJob))//equivalent to is >> myJob.PID >> myJob.burst >> myJob.arrival >> myJob.priority;
        	std::cerr << "Error on line: " << line; 
        std::cout << myJob << std::endl; // prints content of the object
    }
    if(in.fail()) {
    	//Failed stuff here
    }

The above way effectively does what your code does for "errors", so yes it's possible to incorporate error checking

No it doesn't. That code will always fail. When the loop is done because eof is reached, eofbit and failbit are set together and the "//failed stuff here" block will *always* execute, even when there were no actual errors.

8 hours ago, wanderingfool2 said:

Well the EOF doesn't need to really be handled if you are using std::getLine, as it will return false when it no longer is able to read new lines.

Actually, could be wrong (again been a while since working in C++ directly), by checking for EOF after you read a line and before processing the line you actually end up tossing out the last line of data.

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.

@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.

7 hours ago, Rheostat. said:

How do I solve for the resistance for R2?

 

LDR1 and R2 form a resistive voltage divider, the formula for which is:

A transistor starts conducting at around 0.7Vbe.

With Vin = 5V and R1 = 220, you seem to be aiming towards 20mA of current trough the LED.

If we assume a wide ball-park gain of 100 for Q1, 20mA collector current will require 0.2mA base current. 0.2mA base current will drop 0.3V over R3.

So 0.7Vbe + 0.3Vr3 is about 1V.

Rldr1's value will drop with the more light it receives. Measure it's value with the amount of light you want your LED to come on.

Then use the above formula to calculate R2 with Vout = 1V, Vin = 5V and Rldr1 the value you measured.

The circuit is heavily dependent on Q1's gain, which can vary a lot between parts (even of the same type). You might want to use a potentiometer to make the setpoint easily adjustable.

"Costume keyboard"

(Sorry, couldn't resist xD)

A common approach would be to have some kind of ROM/EEPROM with wave audio samples for all the spoken words you need, a DAC and amplifier to convert the digital wave samples to audio that can be output on a speaker, and some sort of microcontroller that keeps the time and orchestrates sending the correct audio samples to the DAC to stitch then together into a sentence.

Not really achieveable without coding expierence.

Perhaps you could look into if something similar does not already exist on linux that could be ran on a raspberri pi or similar device.

This question isn't really relevant Imho.

Whatever power efficient new technologies they invent. If you take such a powerful low power chip and crank up it's voltage and give it more power it'll always go faster still. But now it requires substantial cooling and thus requires a desktop. But that is the main point. Whatever they invent, if you make it bigger and run hotter it'll be faster.

And there'll always be reasons to use the increased processing power. Any pretty game can be made even more detailed, for any processing task it can be desirable to be done faster.

Qt creator

36 minutes ago, gabrielcarvfer said:

Monotonic counters used as address offsets/index are a very special case (e.g. primarily in C loops). Which is why using it makes sense.

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?

25 minutes ago, gabrielcarvfer said:

I have no idea where did you got that from.
Unsigned is the proper type for monotonic counters (e.g. index offsets). The example you provided of a tachometer is not a monotonic counter.
You said it is easier to debug. If you're dealing with little tiny numbers and see a gigantic one, it should be obvious that there is an error.

I do agree that you should not use unsigned everywhere, but this is the exact place where it makes sense to use it other than bit manipulation and bigint soft-math.
Also, you should use iterators if you're not feeling confident in dealing with indexes/pointers. Way safer, has checks to prevent out-of-bounds, etc.

I'm not going to debate this much, this is an ongoing never ending debate between the two camps. But many years of experience has learned us that, those that think they can avoid the traps that come from mixing signed and unsigned, are the first to be bitten by them. And as said, in a real world program variables and their types propagate trough the program. You can't just use unsigned where it makes sense, because at some point the result will be used in another equation where it mixes with something signed.  You'll have to constantly keep track of the types involved and convert where necessary. It *will* bite you! Using signed everywhere (except very special occasions), and immediately safely converting any unsigned data to signed as soon as you get it, is the only way to go imho.

Even Stroustrup repeatedly admitted making size_t unsigned was a big mistake.

Watch this video from 42:40 https://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-Anything

Listen to the man, he knows his stuff.

@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