C pointer confusion on char arrays

[Kosmic]

Hehe, I have a master degree and more than 20 years exp as a professional programmer mostly in C++ but also C and C#. Trust me I don't lack knowledge 

if you wanted to impress me with this, your attempt is failed. I got master degree with honors in Computer Science (software development of automation systems) 20 years ago, before that I also get bachelor degree in computer electronics. I wrote first C program at about 1992, and learned C++ at about 1994. Most of the time I worked as software development engineer in medical devices industry for a company which was in a top 5 of fortune 500 list.

As you probably understand this is much more strict than usual programming, because it requires additional knowledge of software development lifecycle and medical standards certification (ISO13485 etc) with regular examination to be allowed to work on medical devices projects. If you know requirements for medical devices and software systems used in cardiology surgery and cardiopulmonary resuscitation, then you can understand why it uses so strong requirements for development process and this is what I worked on. And what?

No, I have no need to impress anyone. I'm far passed that point in my career. I was trying to answer your "lack of knowledge" assumption.

Automatic memory management is core to C# design. By completely bypassing it all the time you can't really say you are using the language correctly. If you need or want to manually manage memory that much you should use something else. Like C++. Would be a lot more efficient.

[Kosmic]

Why not simply using C++ then ?

C++ is more unsafe than C# with unsafe code, it's more hard to debug and perform code analysis. Technically yes, you can do all things in C++ more effective, but in practice it will be more hard than in C#, because it will be more easy to do some mistake in C++ and more hard to find/detect it.

If you know the language I don't think so. It's probably because I know C++ pretty well, but I think your unsafe C# is more dangerous.

[radiolistener]

Automatic memory management is core to C# design. By completely bypassing it all the time you can't really say you are using the language correctly. If you need or want to manually manage memory that much you should use something else. Like C++. Would be a lot more efficient.

I don't bypassing it, I just use it more effective with using unsafe code. Of course there is no needs to use unsafe code for a usual code, it is required when you're needs to do proper marshaling and time critical code optimizations. Most of the code in a project don't requires it, but it don't means that this is useless feature which don't needs to be used at all.

[langwadt]

Why not simply using C++ then ?

C++ is more unsafe than C# with unsafe code, it's more hard to debug and perform code analysis. Technically yes, you can do all things in C++ more effective, but in practice it will be more hard than in C#, because it will be more easy to do some mistake in C++ and more hard to find/detect it.

If you know the language I don't think so. It's probably because I know C++ pretty well, but I think your unsafe C# is more dangerous.

how's being "unsafe" some of the time going to be worse than being "unsafe" all the time ?

[Kosmic]

Automatic memory management is core to C# design. By completely bypassing it all the time you can't really say you are using the language correctly. If you need or want to manually manage memory that much you should use something else. Like C++. Would be a lot more efficient.

I don't bypassing it, I just use it more effective with using unsafe code. Of course there is no needs to use unsafe code for a usual code, it is required when you're needs to do proper marshaling and time critical code optimizations. Most of the code in a project don't requires it, but it don't means that this is useless feature which don't needs to be used at all.

Then we are saying the same  thing

It's used for special cases but most of the code is not in unsafe block.

[radiolistener]

If you know the language I don't think so. It's probably because I know C++ pretty well, but I think your unsafe C# is more dangerous.

probably you're didn't worked on a large projects which include C# and C++ projects together.

Can you show some example where C# code is more dangerous than in C++ on your opinion?

[DavidAlfa]

Not again, you both create your own damn thread and fight there!

[Kosmic]

If you know the language I don't think so. It's probably because I know C++ pretty well, but I think your unsafe C# is more dangerous.

probably you're didn't worked on a large projects which include C# and C++ projects together.

Can you show some example where C# code is more dangerous than in C++ on your opinion?

No i don't have good C# exemples. When I was working on a C# project we were avoiding unsafe code as much as possible. That was our guidelines. So we never ended up having exemple of dangerous unsafe C# code.

[radiolistener]

It's used for special cases but most of the code is not in unsafe block.

it depends on the module. Some modules requires unsafe code almost everywhere. Some modules don't requires it at all.

[radiolistener]

No i don't have good C# exemples. When I was working on a C# project we were avoiding unsafe code as much as possible. That was our guidelines. So we never ended up having exemple of dangerous unsafe C# code.

some guidelines are broken by design and can lead to cloning of the same errors. I was seen it... 
You're needs to understand how it works, when and why to use one or another solution by context, not by guidelines...

Do you implementing finalizer for a class which implements IDisposable, but don't holds native resources?

[ArdWar]

However so far my STM32G050F6P6 with 32kB of memory is already >89% full and it is just showing the value on display and instruction.

(s)printf (I assume you use it somewhere) uses a lot of space especially if you actually print floats ("%f"). Even using something as silly as

Code: [Select]

printf("%d.%d", (int)val, (int)fmod(val*10.0), 10)); can save quite a lot depending on your compiler and stdio implementation it uses.

Maybe also try using MCU optimized libraries and see if it helps.

[radiolistener]

(s)printf (I assume you use it somewhere) uses a lot of space especially if you actually print floats ("%f"). Even using something as silly as

Code: [Select]

printf("%d.%d", (int)val, (int)fmod(val*10.0), 10)); can save quite a lot depending on your compiler and stdio implementation it uses.

Maybe also try using MCU optimized libraries and see if it helps.

I remember that iar printf library code for MSP430 has some issue which can lead to hung with some specific formatting and yes, it eats a lot of space. And if you look at library code for format parsing, it has a bunch of useless code which is almost never used. So, I'm agree - it's really better to use simplified printf format and don't use library with full printf support. This saves a ton of memory and makes the code noticeably faster

[Kosmic]

No i don't have good C# exemples. When I was working on a C# project we were avoiding unsafe code as much as possible. That was our guidelines. So we never ended up having exemple of dangerous unsafe C# code.

some guidelines are broken by design and can lead to cloning of the same errors. I was seen it... 
You're needs to understand how it works, when and why to use one or another solution by context, not by guidelines...

Do you implementing finalizer for a class which implements IDisposable, but don't holds native resources?

I don't think our guidelines was necessarily wrong considering our base C# programmer was struggling understanding references and implications of capturing references in a lambda.

In general C# teach programmers to let go of memory management so when they suddenly have to manage it in a unsafe section, the risk of problem increase drastically.

[radiolistener]

In general C# teach programmers to let go of memory management so when they suddenly have to manage it in a unsafe section, the risk of problem increase drastically.

I don't agree, on the contrary, C# requires to understand memory management more deep in order to properly work with it, so when you going to unmanaged code it will be even more easy because all memory is assumed as unmanaged and there is no needs to take care about possible issues related to background memory defragmentation. And C# learns to write code more clean and deterministic. Also C# compiler has many checks and more strict syntax so it teaches you not to make stupid mistakes which can remains in C++ code for a long time unnoticed.

There are really some difference which may lead to mistakes when switching from C# to C++, but this is just a matter of habit.

But in general, writing code in different languages learn you to write code more clean and make less mistakes. So, switching from C# to C++ and back learns you to write code more clean and allows to notice hidden issues.

[Kosmic]

In general C# teach programmers to let go of memory management so when they suddenly have to manage it in a unsafe section, the risk of problem increase drastically.

I don't agree, on the contrary, C# requires to understand memory management more deep in order to properly work with it, so when you going to unmanaged code it will be even more easy because all memory is assumed as unmanaged and there is no needs to take care about possible issues related to background memory defragmentation. And C# learns to write code more clean and deterministic.

Ok, how is this possible when the memory is managed ? Normally it's all automated and you don't take care of it. By definition, C# doesn't require you to understand everything about memory management. In C/C++ you don't really have the choice to learn since it's not done automatically for you.

I understand you might be really proficient at managing your memory with unsafe code in C# but I really doubt this is the case for your average C# programmer that never did any C/C++.

[radiolistener]

Ok, how is this possible when the memory is managed ? Normally it's all automated and you don't take care of it.

it is automated, but you're needs to understand how it works and sometime how to control it under the hood in order to use it more efficiently and don't make hidden bugs. Even if you don't use unsafe code at all, you're still needs to understand it to avoid unexpected performance degradation.

[radiolistener]

I understand you might be really proficient at managing your memory with unsafe code in C# but I really doubt this is the case for your average C# programmer that never did any C/C++.

Yes, unfortunately there are a lot of people who writing in C# and don't understand what is the pointer at all. But this is a side effect of possibility to write pure safe code in C#. This is not good and such peoples often make stupid mistakes related to memory management even in safe code.

It seems that some peoples just unable to understand what is the pointer, this is curious but I found that for some reason this is just impossible to explain them it. They still can write code, but when it's going to pointers they just unable to understand it. It sounds like joke, but such issue really exists and I have no idea how it is possible, probably this is some kind of genetic predisposition 

[Kosmic]

I agree with your points. What I'm trying to say is because it's automated, peoples get lazy and they tend to don't understand how it's working under the hood. and that can lead to really dangerous situation when they start playing with unsafe code.

I'm generalizing here but this is what I observed anyway.

[radiolistener]

I agree with your points. What I'm trying to say is because it's automated, peoples get lazy and they tend to don't understand how it's working under the hood. and that can lead to really dangerous situation when they start playing with unsafe code.

I'm generalizing here but this is what I observed anyway.

I think this is happens when people just using ready to use libraries, and when they needs to implement something they looking for existing library that can do it and just call it instead of implementing required functions. But if you're writing your own libraries to communicate with devices and OS, it always needs to learn how it works under the hood.

There is side effect of such lazy coding. Most of ready to use libraries come with limitations, for example it cannot run on some platform or incompatible with old OS, or require some payment, or sending unwanted telemetry, etc. So, if you use such approach, your code will be bloated with unexpected functions and will not be portable, so your app will be able to run on some specific OS with specific libraries only.