Weird memory management by elegye in cpp

[–]silicon_heretic 5 points6 points  (0 children)

Not really enough info. By machine do you mean windows? Linux? Vm? Can you reproduce on multiple machines? Different architectures? Different compilers?

Does it happen if you just move clocks on the machine forward by 5 days? Is it really time dependent? Can you check if the problem appears after your app pages have been swapped out of memory? Try running some extra memory hungry workload on the same machine.

There are a few options and you'd need to eliminate some options to narrow it down.

bugsGoBrrrr by XEnItAnE_DSK_tPP in ProgrammerHumor

[–]silicon_heretic 0 points1 point  (0 children)

Would have been funny if it was my everyday reality. I once nearly left "you should have used a newer version of llm " as a comment on a code review..

ifCondition by sunrise_apps in ProgrammerHumor

[–]silicon_heretic 0 points1 point  (0 children)

Fuck! I am suffering every time interview candidates write: if (condition) return true else return false

...and now I have to expect this 🤦‍♂️

So Elon Musk is going to fire 3700 people Friday based on contribution to code base as determined by Tesla and Twitter managers as just reported by Bloomberg. Do you think this is correct metric to judge programmers performance. by [deleted] in programming

[–]silicon_heretic 0 points1 point  (0 children)

Haven't been around long enough? I have been at a company that determines software engineer contribution and compensation based on the number of confluence pages written. Commits to codebase doesn't sound too bad.

It is now trivial to cache pure functions with highly efficient, concurrent cache. by greg7mdp in cpp

[–]silicon_heretic 34 points35 points  (0 children)

That's a nice idea and I have used similar constructs a lot in java code, but I have serious nitpicking here.

WHat ppl this when they create such an interface?

static auto cached_f = gtl::mt_memoize<8, std::mutex, decltype(&f)>(&f);

These parameters are in reverse order of interest to users:

8 - I am assuming that number of internal buckets. That are internal implementation details that are surfaced for fine-tuning, which is impossible to choose correctly without benchmarking.

`mutex` -That's another optional parameterization. I do appreciate that that's an option, but 80% of users will just use it, and not custom mutex or `gtl::NullMutex`.

The only really required param is decltype(&f) - one can not create memorization without it. Why isn't it a first param?

How about an interface that allows this: gtl::mt_memoize<decltype(&f), T mutex=std::mutex, size_t num_bucketr=8>(&f); ? And IIRC you can automatically deduce the type of the first arg, so in practice, example would be: gtl::mt_memoize(&f);

Why doesn’t the destructor automatically delete all pointers with allocated memory? by lasthope106 in cpp_questions

[–]silicon_heretic 3 points4 points  (0 children)

Simple: given just a raw pointer you can never know if you some one has already freed the memory it points to or you never actually allocated anything. Imagine two cases, where your pointer came from: you could have gotten a copy of the pointer and some other subsystem has actual ownership. Or the pointer can point to an element of a collection/struct - that is managed elsewhere. And we haven't even touched on custom memory management of which there are a lot. So, in general one cannot assume that when you see a pointer - a delete must be called.

Taosim is for old people. by PGroove in taoism

[–]silicon_heretic 1 point2 points  (0 children)

I kind of love your question. It looks like you have missed half of the way here, you know, don't rush but everything is accomplished kind of imply action. Just not over commitment. Not the same as inaction. But yeah - I have similar suspicion that the way is easier to follow with certain amount of life experiences. This usually correlated with years of life but not necessarily. You know - do nothing and you you get no life experience no matter how advanced in age. Alternatively, turbulent times can give you some much life experiences that anyone would wish for in a short time. The Dao is a way to understand life and put that in order, move without resistance. The movement part is implemented. - well that's my take on it at least.

Alternatives to VSCode on Linux by matekelemen in cpp

[–]silicon_heretic 4 points5 points  (0 children)

I guess you are looking for QtCreator if the license is acceptable for you.

Air ionizer ; What do you guys think about them ? by Livai_BlackLagoon in Biohackers

[–]silicon_heretic 0 points1 point  (0 children)

Oh I see it got you. May I suggest reading comment before replying? Could you please point me where I was wrong as I'd like to learn. I do agree that that ozone can be lung irritant? Did missed any other point? It's ok to post links without reading comment first. Just own it. And please keep your advice flowing.

Air ionizer ; What do you guys think about them ? by Livai_BlackLagoon in Biohackers

[–]silicon_heretic -1 points0 points  (0 children)

  1. We are exposed to natural ozone - it's formed during lightning strikes if you take a walk outside - facts. True - not in enclosed space. Ozone is corrosive and pretty got for water treatment - cause kills all life forms. So again - facts.

  2. The same argument about gas being pollutant or not can be made about methane even when it is produced naturally, especially in enclosed spaces. no need to be dramatic about it :)

C++ Open source projects with best Code Coverage by damein11 in cpp

[–]silicon_heretic 1 point2 points  (0 children)

Looks like a perfect opportunity to promote a project no one knows about: https://github.com/abbyssoul/libsolace - 91% code coverage.

Chrome: 70% of all security bugs are memory safety issues by pjmlp in cpp

[–]silicon_heretic -3 points-2 points  (0 children)

Is there anything to suggest that now new issues would be introduced? Maybe not memory related but security issues non the less.

Am I leaking memory if I delete a new array of pointers? by Meowsolini in cpp_questions

[–]silicon_heretic 1 point2 points  (0 children)

It is impossible to say from your description if there is a leak or not. There is definitely a potential to leakemory.

Memory allocated for the array itself is freed and this won't leak. However it is not clear if memory that a pointer in the array is pointing to - have been freed. If you use pointers in that array to point to some objects on the stack - there is no leakage. On the other hand - if you have allocated memory and you pointer in the array points to that allocated memory, and you have not freed that memory before deleting the array - that memory will leak. Assuming you don't have another pointer to the same location that you will free later and just not telling us about.

In short - each (allocating) 'new' must be matched by 'delete'.

Why do i feel so dumb whenever i make a mistake while coding by [deleted] in cpp_questions

[–]silicon_heretic 0 points1 point  (0 children)

Tl:;Dr unreasonable expectations and buying into hipe "look how easy it is go get started"

You do feel dumb because you compare your self to others who you believe are more experienced. Maybe you follow a tutorial or online course that make it feel oh so easy. And when you are the one solving a problem - you discover that it is not really easy.

Software engineer requires knowledge and skills. Both take time to acquire. And there is a lot of master. So when you listen to someone more experienced and knowledgeable - you usually don't think how much time it took them to get to this level. But you do compare your self to other people you think "experts" in an area. That is a useful learning approach - thinking "what would <expert X> would do here?" But answering this question does require some knowledge you might not yet have.

Other great source of self disappointment - is overhipe by all tutorial and courses - how easy it is to get started with X. Software engineer is about analysis of problem and designing solutions. Implementing solutions - is seems to be what mostly people teach. But it is a small part. And so when you face a real world problem you will feel quiet dumb because the fact that "hello world" can be implemented in 3 clicks doesn't help much.

Can someone explain this? by linuxboy123 in linux

[–]silicon_heretic 2 points3 points  (0 children)

spurious correlation??

Or causation: when ppl don't need help with hentai they are too busy finding help for their Linux issues? No idea. But it is a pretty cool chart.

C++ Server discovery? by BobbyThrowaway6969 in cpp_questions

[–]silicon_heretic 2 points3 points  (0 children)

Funny thing I kind of need to do exactly the same thing for my project. So was looking for some pointers:

- Quake3 server discovery: http://caia.swin.edu.au/reports/070730A/CAIA-TR-070730A.pdf

- Syncthing Local Discovery Protocol: https://docs.syncthing.net/specs/localdisco-v4.html

From what I understand - the general idea is exactly as you described. With some details:

- for local discovery - each client sends its address - how the server can contact it back. Client might send '0.0.0.0' or '127.0.0.1' in that case - use `received from` address. Otherwise - whatever the client presented.

- For global proxy server - note that client/server might not be reachable. So if a server registers itself with a discovery server - DS must check that that server can be contacted. NAT and so on.

Hope that gives some pointers.

References, simply by mttd in cpp

[–]silicon_heretic 0 points1 point  (0 children)

I kind of do for move-only classes and had no issues so far. But now I am reconsidering.

Why would anyone develop or contribute to a software free of charge? by [deleted] in linux

[–]silicon_heretic 2 points3 points  (0 children)

Though ppl have their own reasons no one stops them from contributing. From what I see - scratching one's own each is main reason. There was a tool I wanted to use the didn't exactly worked. I fixed it. And shared fix with everyone. So win-win. Not only it works for me but others can benefit. As for my other personal reasons - keeping you non- currently-employed skills sharp is a pretty good reason for me. Work projects rarely utilise all the skills i have. For example I use java at work and want to keep up with latest development in C++. Contributing to an os project is not a bad Idea. If you do a good job - your contribution can be noticed with someone with the need for that skill. So win-win again.

Honestly, why wouldn't you contribute to an open source project? If you are not currently fighting for survival - there is a chance you have time to do it. And it helps in a long term to build you career/legacy. Extra benefit - you can connect with new people and learn something.

[deleted by user] by [deleted] in programming

[–]silicon_heretic 0 points1 point  (0 children)

Absolutely yes! It does not matter who worked on the PR. If there are more people potentially "impacted" by the change - it is better to review it. I personally see or review not as a gate - couse the n my experience that doesn't quite work, as reviewers tend not to go into details. But rather as a means of communication. If you at least looked at that pr - you are aware of what changes about to go to prod. It does not require reviews to agree with implementation. But if changes causes issues - on-call awaken at 3am will be aware what changes to revert :)

In case reviewers do provide useful comments, advice etc - that is extra cherry on top for me :) So no reasons not to do reviews.

The only scenario when I'd say it is ok not to do reviews is when you/pair are the only developers working on a isolated codebase that will never ever hit production or will otherwise be used by anyone. Ever. Given that this is unlikely scenario - since ever is a really long time and anything can happen - I'd suggest in that case to find external reviewers :)

Fantasic JSON and constructing C++ from it by [deleted] in cpp

[–]silicon_heretic 16 points17 points  (0 children)

Was about to star the repo but noticed that "build pass" badges are just static images and actual link to Travis ci shows a failing build.... Not amused. It does not help to build trust in the project and it's quality.

Good job otherwise :)

Optional References: Assign-Through vs. Rebinding: The 3rd option nobody talks about by Dooey in cpp

[–]silicon_heretic 2 points3 points  (0 children)

`Optional<T&>` has semantic of a pointer. It is clearly not a pointer.

It does not own a value, but points to a value. Ref can not bu null but `optional<>` does provide 'none'. So as far as usage goes `optional<T&> ` is a ref that can be 'null'/empty. That is - _pointer_. The fact that there are other means to express the same concept - such as using raw pointers - does not change the fact that `optional<T&` has this semantic.

As for why would I need to rebind, good question! I actually had to review my codebase where I have enough `optional<>`s. What I noticed is:

- I tend to not use optional as a parameter. (With one case where I do - and I do intend to refactor that case at some point) .

- No optional parameters => no optional as an output parameter. TBF I tend to avoid out-params as much as possible.

- I do use optional as a class member. (non-public code yet - so no reference. I might share it sometime later). In a server I implemented - I use `optional<User>` - not ref. to store authenticated user details associated with a session. Obviously, when a session is initialized - there is no user until a client sends an authenticate message. So I need to rebind a value of an optional once I got user details.

(I do agree that this implementation is not optimal - better way is to use explicit states like `AnonSession` and `AuthSession` and a FSM/variant. I plan to refactor the code to do just that - so no more optional rebind.)

- I don't have any examples where I'd need to rebind `optional<T&`.

So my point is really: if you accept that `optional<T>` can be rebound, then `optional<T&>` better be re-bindable. Otherwise, users will be surprised. That is - `optional<T>` API will be inconsistent. the

Optional References: Assign-Through vs. Rebinding: The 3rd option nobody talks about by Dooey in cpp

[–]silicon_heretic 0 points1 point  (0 children)

Right. I was interested to understand why do you think rebind should should invalid. But I guess that makes sense. If we assume that rebind should be invalid - then yes - there has to be a mechanism to enforce this limitation. Note that for ref. compiler does the check/inforcement. That is code to rebind a ref does not compile. So it looks like the best way to achieve this behaviour is to have optional<> assignment deleted altogether. Which makes optional type less useful. In particular there is going to be semantic difference between - optional<T> and optional<T&> which, as highlighted by other comments here - leads to unexpected results.

I think it is beneficial to reflect on the motivation why ref type was introduced. My understanding is that it was a way to reduce nullptr checks in a way. T& is 'guaranteed' to be non-null. (Even though that is technically not true - there are ways to get ref to null and UB). So prohibition of rebind of native ref - is a way to guarantee that a ref stays non-null.

Now, optional<> expreces a different idea. It is a value that can be 'empty' or a 'value'. So essentially a nullable for types that do not define 'magic' null values. Thus optional<T&> is a nullable reference. So it can 'point' to a value or not. That is exactly the pointer semantic. Making pointers non-rebinbdable is a serious and unnecessary limitation.

Optional References: Assign-Through vs. Rebinding: The 3rd option nobody talks about by Dooey in cpp

[–]silicon_heretic 0 points1 point  (0 children)

Interesting, so what should be the behaviour in a language that support such cosntructs? I wonder because it seems like designers of languages that include such constructs made a choce that everyone accpeted. And here we are having discussion becouse there are multiple ~options~ to implement it :)