john_fushi

I don't want to tangle myself in a "technically correct" kind of discussion however I'd like to point out that Bloom's taxonomy - a widely used model in pedagogical context - has a level for creative work.

It is the highest level of learning, but still a level of learning.

Thanks for the explanation!

That's the part I missed : the first null check can be skipped if the memory is allocated but the constructor hasn't been executed.

Doesn't the singleton example contain an error?

On one hand, the author says that instanciating the singleton and storing it is not safe because there is no synchronization, but on the other hand he says that null check before is safe because the mutex introduces synchronization.

My understanding would be that the mutex protects this whole section and that the atomic is not necessary at all in this case.

Please correct me if I'm wrong.

I guess Matsumoto should have charged for Ruby. I'm sure Mike Perham and Derek Kraan would have been glad to pay for that and that the Ruby community would be in a strong and healthy shape.

(In Canada) The max my bank offers is 10 years, and it comes at a premium. The standard I see around me are 5 years.

Let's say that, hypothetically, I lead a project for a very big customer that ended up being used to commit a (arguably) crime against humanity.

Should I put this on resume and would it be in poor taste to quantify the results?

> val x: Pair<String, Pair<String, String>>

This just describes the structure. Structure without intent is useless.

Comments and out of code documentation both have the same problems : - Blindspots - Rot

That is not to say they are useless, but they are rarely if ever sufficient.

In the end, the most complete and trustworthy source of truth for the code is the code itself.

Help others by having your code describe your intent. Using appropriate variable name and using appropriate types _help_ to keep displayed intent in sync with reality.

Another point to consider is that for the same intent the structure may need to change, to evolve. Proper typing can insulate the code from those changes.

Unless you live in Quebec - then google disabled this option to avoid complying with local children protection law.

Which is also an issue in the author's example, no? So the point would be moot.

Hey! What's up?

Telling someone to "man up" is a telltale sign of toxic masculinity.

N.B. I'm writing my comments as I am reading your code. Please, don't take offense from my criticism, it is meant to be constructive, albeit concise.

/* * @brief Retrieve a continuous block of * valid buffered data. * @param num_reads_requested How many reads are required. * @param skip Whether to increment the read position * automatically, (false for manual skip * control) * @return A block of items containing the maximum * number the buffer can provide at this time. / Block<T> Read(unsigned int num_reads_requested)

Where is skip?

> if (buffer_full) > { > / > * Tried to append a value while the buffer is full. > / > overrun_flag = true; > } > else > { > / > * Buffer isn't full yet, write to the curr write position > * and increment it by 1. > / > overrun_flag = false; > data[write_position] = value; > write_position = (write_position + 1U) % LENGTH; > }

You don't write in the case of an "overrun". Isn't that one of the most interesting property of a ringbuffer? It seems that your implementation is specific to your use case (buffering to sd cards?). I don't think your _current_ implementation is apropriate for a _general_ purpose ring buffer mostly because of api concerns. It may be interesting to emphasis this part in your doc.

> reads_to_end = LENGTH - read_position; > req_surpasses_buffer_end = num_reads_requested > reads_to_end; > > if (req_surpasses_buffer_end) > { > / > * If the block requested exceeds the buffer end. Then > * return a block that reaches the end and no more. > / > block.SetStart(&(data[read_position])); > block.SetLength(reads_to_end); > } > else > { > / > * If the block requested does not exceed 0 > * then return a block that reaches the number of reads required. > */ > block.SetStart(&(data[read_position])); > block.SetLength(num_reads_requested); > }

Maybe : > reads_to_end = LENGTH - read_position; > eff_reads = (num_reads_requested > reads_to_end) ? reads_to_end : num_reads_requested; > //or : eff_reads = std::min(num_reads_requested, reads_to_end) > block.SetStart(&(data[read_position])); > block.SetLength(eff_reads);

Still, I understand the need to be very explicit in an embedded context.

Same principle for ``if (!bridges_zero)`` (the ``else`` case)

> memset(data, 0, LENGTH);

>// ...

> T data[LENGTH];

I'm not sure how important it is in practice, but I'm pretty sure you don't zero out the whole array for sizeof(T) > 1.

Anyhow, memsetting to 0 a complex type is... not something I'd recommend in most cases.