https://paste.ubuntu.com/p/54y7bPshdF/ i get seg fault error

To malloc a 2D array, you first need to allocate in that int** pointer an array of pointers, and then allocate each pointer with an array of ints

To malloc a 2D array, you first need to allocate in that int** pointer an array of pointers, and then allocate each pointer with an array of ints

int (*arr)[][n] = malloc… is that wrong ?

You should do something like this: int ** arr = (int**) malloc(sizeof(int*) * rows); for (int i=0; i<rows; ++i) arr[i] = (int*) malloc(sizeof(int) * cols);

malloc returns a void*, so seems logical to me doing that. It might be verbose, but I don't see why you shouldn't

I prefer being explicit of what I do rather than let the compiler do an implicit cast

And that's why I hate C. I don't agree at all with those kind of implicit castings. I'm of the team that implicit casts are hell. Maybe those are my forms as a C++ programmer rather than a C one

I basically don't agree. I've seen so many things going wrong because of implicit castings

One example is when comparing integers with different sign types. Sometimes I want the comparison to happen between the unsigned type and some others I want it with the signed one, depending on the design

Well, I'd like to live in a world where the STL has signed size_t, but we don't, and most of the time I prefer signed types in my design, but still have to compare with the unsigned type the STL chose

The thing that unsigned types have that discontinuity in the 0 is a hell in many ways. In fact, C++20 added ssize to the STL in order to get the size of a container, but with a signed type instead of the good old unsigned one

That hints that maybe choosing an unsigned type for containers' size wasn't the best one

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html

Because I don't want to do signed vs unsigned comparisons, and sometimes my designs are easier with signed types, I cast to the type I want so I don't compare values with different sign-ness

And also to avoid the warnings that the compiler throws

Guys chill out let each other have their own opinion. Sometimes there is no right or wrong...

It's okay you don't like explicit castings, but I choose to use them wherever it's possible, so I'm completely clear about my intentions

I guess we are not going to agree. There's also stuff in the cpp core guidelines I don't agree with

And the proposal talks about more motivations other than the span one. The problem became clear with span, but it wasn't just because of span

Guidelines aren't immutable. If they were, we'd be still following the "return const by value" that was present in the Scott Meyers one

Scott Meyers’ Effective C++, Third Edition (Item 3, page 18)

Guys please just stop beeing so angry. Just agree each other's opinions even if they are right or wrong. Please stop!

It implied that a signature like const ObjectType f(...); could be a good thing, which was obviously changed in later editions

Guys please just stop beeing so angry. Just agree each other's opinions even if they are right or wrong. Please stop!

I think we both can learn, I don't see anything wrong in discussing points of view, as long as the discussion is respectful

I'm not angry, I'm just trying to explain my point of view in a specific topic, that's all

I guess it was an erratum then, but it was there at some point

I guess it was an erratum then, but it was there at some point

^

Again, I said it turned out to be an errata fixed in 2009: https://www.aristeia.com/BookErrata/ec++3e-errata.html

11/ 4/07 nxd 18-19 The text implies that all by-value returns should 7/17/09 be const, but cases where non-const by-value returns are good design are not difficult to find, e.g., return types of std::vector<T> where callers will use swap with an empty vector to "grab" the return value contents without copying them.

The thing is that guidelines might be good at some point, but turn out to be not so good in the future

Who knows penetration testing

Idk guys, but I think that sometimes we also have to take a look at how important something is in real world scenarios: I mean except from styles and suggestions, does it really matter if someone cast's a void* to an int* explicitly? I mean seriously it might be harder to read, and in C it is more common to NOT cast it, but it does not matter in a small program. It might matter in a huge for readability but let's be honest even in companies many programmers sometimes use their own styles - they use the company style mainly and some smaller things like they want... so I think it's rather redundant to discuss this...

For the signed/unsigned size_t/ssize_t problem, it's more important!

Who knows penetration testing

Guys anybody reply me

"Please consider updating the answer. The cast is no longer dangerous, and repeating oneself is not necessarily a bad thing (redundancy can help catch errors)"

"Ok. I think it's bad to assume that anyone reading here has a particular compiler. Also, since C11 the entire "implicit function" concept is gone, I didn't know that" also that's true. Many people still use older C so no C11

Seems to be a hot topic

Yes I think if you want C11 on Windows clang is the way to go. MSVC is shit; it does not even fully support C99! Each time I have to write: #define restrict __restrict I'm getting upset about it!

Oh really? I didn't knew that! That's a shame! I like the C11 multithreading library - is there no way to get it on Windows except for MingW?! I think they should all start implementing C11!!

I hoped I could drop pthreads for C11 but looks like I could not :(

Oh my 😐

int main(){ char * a = "emir "; char * b = "alkal"; printf(strcat(a, b)); } is this why illegal instruction?

The output is Illegal instruction: 4

int main(){ char * a = "emir "; char * b = "alkal"; printf(strcat(a, b)); } is this why illegal instruction?

assign strings like those to const char * instead of just char * to minimise errors

strcat function is writing location of a string of a+b , am i get right? Isn’t that new memory locate for new string

strcat function is writing location of a string of a+b , am i get right? Isn’t that new memory locate for new string

man 3 strcat

okay i get it thanks

man 3 strcat

thanks a lot, i will check

#include <stdio.h> #include <string.h> int main(){ char * a = "emir"; char * b = "alkal"; printf(strncat(a, b, sizeof(b))); } it’s illegal too?

#include <stdio.h> #include <string.h> int main(){ char * a = "emir"; char * b = "alkal"; printf(strncat(a, b, sizeof(b))); } it’s illegal too?

You should allocate the memory first

#include <stdio.h> #include <string.h> int main(){ char * a = "emir"; char * b = "alkal"; printf(strncat(a, b, sizeof(b))); } it’s illegal too?

dude, your destination is still a string literal

i told you to use const char * for this exact reason

i want to 2 bss string combine, isn’t that possible?

i want to 2 bss string combine, isn’t that possible?

not with 2 string literals which are read only by definition

doing char * doesn't mean their constness magically vanishes, they are still const. stop writing to them

not with 2 string literals which are read only by definition

okay, thanks char * a = “blabla”; means const char * a =“blabla” isn’t that?

#include <stdio.h> #include <string.h> int main(){ char * a = "emir"; char * b = "alkal"; printf(strncat(a, b, sizeof(b))); } it’s illegal too?

Allocate the memory for the designated pointer in strcat function

okay, thanks char * a = “blabla”; means const char * a =“blabla” isn’t that?

no

okay, thanks char * a = “blabla”; means const char * a =“blabla” isn’t that?

Just allocate the memory to the designated pointer and it will work fine.

Just allocate the memory to the designated pointer and it will work fine.

okay

okay

you can also use normal arrays char a[10] = "emir"; const char *b = "alkal"; puts(strcat(a, b));

you can also use normal arrays char a[10] = "emir"; const char *b = "alkal"; puts(strcat(a, b));

if i write that a[6] it is buffer over flow, right?

if i write that a[6] it is buffer over flow, right?

yes

i get it stuff, thanks

if i write that a[6] it is buffer over flow, right?

technically the solution i gave before editing to strcat won't result in buffer overflow strncat(a, b, sizeof(a) - strlen(a) - 1); // make sure a is char[N] type and not char * type in this scope

hi my codeblock won't load

hi my codeblock won't load

switch to something more modern

Visual studio is premium

Visual studio is premium

Visual Studio community is free

technically the solution i gave before editing to strcat won't result in buffer overflow strncat(a, b, sizeof(a) - strlen(a) - 1); // make sure a is char[N] type and not char * type in this scope

okay i get it

this is kinda sorta outdated. should mention VSCode. and maybe KDevelop too

this is kinda sorta outdated. should mention VSCode. and maybe KDevelop too

@admin

🤷

for macOs CLion too

for macOs CLion too

CLion is cross-platform

CLion is cross-platform

okay i didn’t see cross platform tag

Is there any good books for learning c++ as there are many but I don't know which of them is better?

Also any practice bokks for c++ for beginners?