|
If the data type is defined as an array then use it as array in expressions.
If the data type is defined as a pointer then use it as a pointer in expressions.
honey the codewitch wrote: some people prefer &foo[bar]
Rather certain that I am one that would not want to see that. I work to write code that is maintainable and using tricks just because the exist is not something that I look on favorably.
|
|
|
|
|
That's not really a trick.
It's "get me the address of the Nth array element."
It's just another way of writing (foo + bar);
If you insist on not mixing pointer and array ops than you'd be stuck with the very syntax you don't like in order to get the address of an array element, unless there's a 3rd way to do it I'm not considering?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
So you say it is an array. Then use it as an array when you identify the element you want to take the address of.
|
|
|
|
|
that's exactly what &foo[bar] does.
Literally it reads as take the address of the bar element of foo.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Right. So use that, rather than (foo + bar).
|
|
|
|
|
honey the codewitch wrote: It's just another way of writing (foo + bar);
yes I know.
honey the codewitch wrote: If you insist on not mixing pointer and array ops
Not sure what you mean.
If I create an array of pointers then I would use it like an array.
If I create a pointer to memory that contains sequential blocks (regardless of type) then I would use it like a pointer.
The fact that syntactically the access is the same and tradable is not a consideration.
|
|
|
|
|
jschell wrote: Not sure what you mean.
I mean this
jschell wrote: If I create an array of pointers then I would use it like an array.
If I create a pointer to memory that contains sequential blocks (regardless of type) then I would use it like a pointer
So I think somewhere we started talking past each other.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
&(foo[bar])
makes it real obvious you want the address of the barth element of array foo
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
fair enough.
Edit: To me the operation is obvious, such that using parentheses never even occurred to me. Clearly that's not the case with the other people that have commented here.  Not sure what that says about my code. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
It's obvious to me too, but I've been coding C since I upgraded from assembler back in the late 80's  . Those who aren't as strong in C that have looked at my code always find it easier to understand pointer manipulation if I use array notation with those redundant (). They have more difficulty with foo + bar -- the idea that foo + 1 moves the pointer by (size of what foo points) bytes instead of 1 byte always blows their mind.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
|
|
Did you intend to put an 'Enter' between 'foo' and 'bar'?
If the comma was intended as an 'Enter', I guess that the comma between, 'bar' and '+' would have fouled it up.
|
|
|
|
|
That is wrong, yes ... I was letting it slide because I was so late in on the thread that I figured no one would notice. Is it me or has the complexion of such changed lately? Anyway.
What I meant to type was "foo,bar+". I'm no programmer just an antique calculator button presser. 
|
|
|
|
|
One of the things that pisses me off in this book I bought about programming GPUs is that he presents so called "pseudocode" example for presenting his solutions. This pseudocode makes extensive use of C style pointer arithmetic, such as (foo + bar) without a word of mention; the reader is supposed to understand what it means, regardless of his programming background or preferred language.
I do have enough background to understand it when I see it. But I see pseudocode as abstracted above one specific programming language, not just as an excuse for ignoring specific requirements of one chosen language. (foo+bar) is something you'll never find in any comparable language. It doesn't belong in any abstracted pseudocode.
So does it belong in concrete code in one specific language?
Well, if you strive to establish a tribal code, to distinguish between those who are in and those outside, this may be one of your tools. Those who say 'But that is an array, FGS! - Why don't you treat it as one?' - and recoil in horror. Maybe those could have been good developers for your project.
|
|
|
|
|
In Visual Studio (latest), C++ solution.
I have a project like :
project\app
project\lib1
project\lib2
project\lib3
project\util
app <-- lib1 <-- util
<-- lib2
<-- lib3
lib1 is dependant on util and app is dependant on lib1.
util needs to be build before lib1 and lib1 before app.
In the project dependencies window, I select lib1 and then check the util dependency.
I've also looked at the project references and my lib1 is setup correctly to reference the util library.
When rebuilding lib1, I expected util to be build before.
There must be something I'm missing. (obviously)
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
modified 15-Nov-23 13:45pm.
|
|
|
|
|
I assume you're using VS. I never had a problem with it once dependencies were set up correctly, although I migrated builds to CMake last year. The only thing I can think of is that if lib1 changed but not util, then the build can just start with lib1.
|
|
|
|
|
Thanks,
I'm in the process of physically moving libraries around (don't ask) and cleaning up the solution.
When I rebuild from scratch, I just want to build the util library first so that all other libraries and eventually the app can build.
I don't think I can change to cmake (that would require a revolution).
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
CMake is integrated with VS now. Migrating to it (about 20 libraries) wasn't anywhere near as hard as I anticipated, and builds are much faster under Ninja. If you're interested, here's[^] an overview.
|
|
|
|
|
I'm working in an antediluvian organisation.
Eventually we'll do it. (or not)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Every organization is antediluvian! 
|
|
|
|
|
Project dependencies can be changed by going to the Solution properties (right click on the solution explorer root of the tree)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
When I read the OP I was also wondering if they were referring to what you said or perhaps they thought the compiler would just figure it out.
|
|
|
|
|
I'm not discussing this on r/embedded for fear of starting a flame war.
For those of you that do embedded, you're probably told to not dynamically allocate memory, but rather to allocate up front.
I cheat.
The problem is with things like TrueType and SVG depending on the complexity of the content the memory requirements can vary wildly application to application, and firmware is difficult (but not necessarily impossible) to adequately profile on the embedded hardware itself.
These features are typically used on systems with at least 360KB of RAM but will run in as little as 192KB that I've tried, at least for some applications (I haven't gotten exhaustive metrics on the memory usage of these things)
What I've done is dynamically allocate in these situations, and then test my app, usually for days to make sure it's stable. I've also run this graphics code (which I use in all my projects) through its paces with deleaker so I'm confident in it.
I could use a custom pool and allocate from that, but I'd still have to know how much TTF for example, would use up front for that given font - which requires instrumenting the application, which costs money.
One advantage to dynamic allocation is my fonts for example, only use it while rendering. It is therefore possible to (while not rendering) use that memory for other (temporary) things. I rarely do this in practice, but it's definitely doable, if you're careful about fragmentation. In these cases, you have to test thoroughly, but again, doable.
How terrible is this approach? I'm self taught and was sort of drafted into embedded so I'm unsure of myself here.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: How terrible is this approach? I'm self taught and was sort of drafted into embedded so I'm unsure of myself here.
Not so terrible, rest assured; don't damage your self-esteem
The biggest issue with dynamic allocation, and where this mantra of "no mallocs" came, is the potential for memory fragmentation. You don't know how well the memory manager behaves and you risk running out of big memory chunks.
However, if you think about it, this is a phenomena specific to multi-tasking, where each task is oblivious of other tasks that may exist in the system. This is not what happens in an embedded system where you have only one "task" (footnote: yes, there are exceptions to this scenario). You certainly have multiple threads but those threads cooperate, not compete for resources.
If you would have an anal boss that wants to enforce the "no malloc" rule, you can allocate all the available memory and run a memory manager inside your app that allocates chunks of this pool. On the outside the system would behave the same way because there is only one task/app. Again, I'm over-simplifying here: there is still a network stack that needs some buffers but you get the gist. In embedded world, quoting Taylor Swift: "This is our place, we make the call".
Mircea
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
