today still no std::htonll

Compared to that whole bunch of handy functions https://doc.rust-lang.org/std/primitive.u64.html#method.to_be

today still no std::htonll

how i could read inputs from stdin ?

https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-htonll

this one is win-only

In linux(*nix), you have https://linux.die.net/man/3/htonl , part of inet

there is no htonll which is for 64 bit integer

there is no htonll which is for 64 bit integer

There is bswap64 https://manpages.ubuntu.com/manpages/xenial/man9/bswap64.9freebsd.html

again these are not portable

What do you mean by "portable"?

In this case, bswap64 and htonll only appear in some specific impl, that means you have to use macros to detect current environment first before using any of them

today still no std::htonll

C++23 is introducing byteswap.

byteswap only swaps the bytes blindly, regardless of host endianness

You can check the endianness using the enum endian which is already available in C++20 and decide whether you want to call byteswap or not

yup, but it takes one more step

How come such common thing does not appear until c++23

If that is your case, you can use boost libraries that provides functions outside the std. (Mainly used by emulators like yuzu) which works irrespective of the platform like std If you use boost libraries, the function will be something like boost::endian::little_to_native()

It is a consteval check which will be done at compilation time. Has no runtime effect

boost is really one choice for c++ (c: ?) but one will have to decide, is it worth to add in another library just for these helpers? That will complicates the building process for sure. Btw in rust, to install a library all you need to do is just cargo add

boost is really one choice for c++ (c: ?) but one will have to decide, is it worth to add in another library just for these helpers? That will complicates the building process for sure. Btw in rust, to install a library all you need to do is just cargo add

At first, there is no such thing as cargo add in Rust. I believe you are referencing dependencies. If that is the case, I believe ninja can do the same along with cmake.

That is how languages evolve. Apparently the community felt that all the changes introduced till C++20 were more important than a byteswap functionality which can be hand implemented trivially and is not going to have as much of an impact as other new features that were introduced

At first, there is no such thing as cargo add in Rust. I believe you are referencing dependencies. If that is the case, I believe ninja can do the same along with cmake.

I can get your point. Is that why c++ is involving so slow?

Being a Rust programmer myself, I know of many disadvantages it has. Since I work in AI field, i can't seem to find nearly 1% of libraries that I would have immediate access to if I were programming in C++. Yes cargo is a build tool that C++ community lacks but b2 and an evolving cmake are getting there. The 3rd party library support in C++ ecosystem is too difficult to ignore

Yes but the problem is that the ecosystem in C++ is split. Sometimes cmake doesn't work out of the box. We have to give credit where it is due. Cargo was betterdesigned and works perfectly and Rust programmers would never feel the need to switch to another build system. But the compilation times in Rust is a pain. C++ with heavy template code still compiles faster than Rust.

Lack of packages is really a problem, but it only takes time and effort. When someone do the work, the problem solved. On the other hand, the c++ committee will definitely not provide an official solution for package mgmt. that’s why we have so many alternatives now, cmake/ninja/xmake/bazel etc. but why there isn’t one of them rule the whole ecosystem?

It is not. Right now C++ is introducing a lifetime annotations like feature a reference implementation for which is already available in Clang. Once that becomes approved, the advantages of Rust would pale in comparison and people would have no reason to migrate to Rust. Given the existing code base, it would make more sense to stick with C++

At first, there is no such thing as cargo add in Rust. I believe you are referencing dependencies. If that is the case, I believe ninja can do the same along with cmake.

Ohh I missed this one. FYI cargo add was a custom command. It has been added to cargo recently.

Seriously. It is much more easier to introduce a unified build system than to design all the packages that C++ ecosystem has to offer in a different language. Bazel, bjam and xmake are no longer in the picture. B2, Cmake and ninja (though cmake can build .ninja files) are the only ones to have an established market presence with cmake controlling a big chunk. I see a move towards CMake in the longer run when it will become the defacto build tool. The non availability of a standard build tool hasn't had as much of an impact on C++ community as you make it out to be. I don't deny that a good standardized build tool like cargo would make a developer's life easier but somehow the C++ community has found ways to work around it. With modern CMake now more popular than ever, the community believes that it will be the tool to use going forward and a majority of the C++ developers already use it.

I have heard the lifetime annotation akin to rust that is being implemented by clang. This will definitely solve some issues like UAF, but will it bring you a sound guarantee? Think of it a bit

Nope. I am on nightly

It will definitely. Use after free is one major problem. The other problem is using stack after return. Both of these will be addressed by lifetime annotations. There are some issues related to multithreading which still need to be handled but hey it is one piece at a time and the community is moving in the right direction. Why do you think there can't be a strong guarantee on it? The whole reason this feature is being implemented is for not just safety but also for better interoperability with Rust code. The lifetime annotations are modelled on Rust lifetimes and Rust already proves that it works. So I am not sure why you think it won't work on C++?

Well, the memory safety guarantee in rust mainly comes from the borrow rules. Can you remember what are the borrow rules?

Well, the memory safety guarantee in rust mainly comes from the borrow rules. Can you remember what are the borrow rules?

Lifetime annotations will fix the problem of UAF and USAR. I didn't say it is a one pill solution for everything. The borrow rules in Rust will be a headache for C++ developers and will never be implemented as it is in C++ but that does not mean there can't be an alternative solution for it in C++. For example instead of enforcing a single mutable borrow or multiple shared borrows at any time, C++ may take the happy path of using software transactional memory to address the majority of issues plaguing C++ code. This admittedly doesn't fix all the issues but atleast it also doesn't restrict developers too much giving them the freedom they had always.

Do you think someone would call themselves a Rust programmer without knowing what the borrow checker does? Really?

It is not the lifetime annotations that ultimately fix the issue. It it the static analyzer. Imagine you write everything in the main function without defining any other functions. Modern compilers and analyzers can already tell if UAF is gonna happen. With lifetime annotations, you can pass the objects and references around functions, and the analyzer has the knowledge about how data flow thanks to that. Nothing more. That’s why I say the whole thing is still not sound.

Nooooo. Do you think compilers can be smart enough to detect all use after free cases without being provided lifetime annotation hints? If you think so then you are mistaken. The reason why tools like valgrind detect such cases is because they enforce a call to their own version of heap allocations and they enforce tracking to check how memory is used. This slows down the program a lot. Compilers by themselves can't figure out all such cases without help from the developers. This is where lifetime annotations helps and like you said they paint a complete picture for the compiler which helps it analyze the code better. If static analysis could detect all UAF and USAR cases, then people would not need to use sanitizers. And even these sanitizers can't catch all issues which is where lifetime annotations steps in.

In Rust, you never write a specific lifetime within a function. Why?

You need lifetimes only for arguments and return values. The lifetimes of values declared within a function is implicit and don't need to be specified. What sort of a question is that? And can you stick to discussing C++ alone in this community? If you have a question specific to Rust, tell us why it is related to C++ while asking it.

Because the compiler is able to infer everything local, right? Same thing applies to C++

Does that fix all UAF and USAR issues?

Definitely no🤪

Which is why you need lifetime annotations

Alright I feel sorry that I still cannot make it clear🥲 Nowadays analyzers can already catch some issues. Lifetime annotations can catch more, but it still does not make the system sound.

It can't catch everything. When did I say that lifetime annotations is a one stop solution for everything? But it definitely can catch every UAF and USAR use case. Can you tell me why it can't handle all of those cases? If you can then there is no argument and I will have to accept what you say. There are other bugs that borrow checker handles and lifetime annotations alone can't handle them. But Transactional Memory can handle a significant chunk of them. There will then be a few more use cases that Rust handles that C++ can't even with TM but that is for another time. But with a majority of the bugs out of the way, the C++ ecosystem would be too strong an incentive to prevent people from migrating to Rust which is what I have been saying all along.

#include <iostream> #include <vector> int main() { std::vector<int> xs = { 10, 20, 30 }; auto it = xs.cbegin(); xs.push_back(40); std::cout << *it; // possible use-after-free: dereferencing an iterator that was invalidated } https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377

Did you read the section below the limitations section which says how this cannot be addressed currently because of how iterators work. This needs the borrow checker and unfortunately that can't be the case for C++. But a simple Java like solution of ConcurrentModificationException exists. The standard wouldn't choose it because it breaks backwards compatibility. But there are ways to work around this. Ranges already avoid this problem when coupled with lifetime annotations. Unfortunately C++ has to live with the backwards compatibility baggage. A developer's solution to problems like these would be to use constant iterators and constant data structures where you don't require to modify them which is sound advice but unfortunately developers don't heed it. When modification is required, only use a single variable to do the modification which is also never heeded. So I get what you are saying and this is the use case that I was looking for. This however does not mean that this can't be fixed ever. Ranges already offer a solution. Deprecating iterators though it may not happen would prevent this. But yeah I get what you are saying : lifetime annotations may not be a one pill solution and I dodnt deny this. There are some UAF cases that do require a borrow checker unlike what I thought. Iterators are evil.

Is that a UAF case?

Hello, i wanna ask something. Why malloc with size 1 is possible to allocate memory. When i want to access element or assignment outside the size it works.

Undefined behavior

Yaa i know😭, but i need the reason maybe with example :)

This is THE reason

Hi guy Why my linear search program is not working properly? #include<stdio.h> int main( ) { int a[10]={ 2,4,6,8}; int num,i,position,flag=0; printf("enter the number to be searched?..."); scanf("%d",&num); for(i=0; i<5; i++) { if( a[i]==num); { printf("the number is present at position:%d",i); } } }