|
&(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
|
|
|
|
|
Mircea Neacsu wrote: you can allocate all the available memory and run a memory manager inside your app that allocates chunks of this pool
The trouble here is determining the pool size up front without just making it the size of available memory. As I mentioned it varies wildly application to application and content to content.
One thing I am doing is playing hot potato with my RAM to avoid fragmentation. I do not keep little allocations around.
Allocations that are kept around are allocated up front. I think that's what saves me 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: without just making it the size of available memory
My point was that you can make it the size of available memory. What else is going to use it? Can user run a 2nd app behind your back?
And if I'm right, and you make it the size of available RAM and manage it inside your app, how is this different from allocating it only when needed? The only difference would be that you use your own memory manager instead of the system one. Is your memory manager going to be better than the standard one? Probably only marginally so.
Mircea
|
|
|
|
|
It depends on the platform. The ESP-IDF for example, likes to temporarily allocate to do just about everything.
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: The trouble here is determining the pool size up front without just making it the size of available memory.
One way around this is to allocate in slabs, adding a new slab when needed. A small system might allocate one slab, whereas a bigger one might allocate, say, four.
honey the codewitch wrote: One thing I am doing is playing hot potato with my RAM to avoid fragmentation. I do not keep little allocations around.
If the memory manager uses buddy allocation and you allocate temporary memory and then free it all before allocating more, fragmentation should be avoided altogether.
honey the codewitch wrote: Allocations that are kept around are allocated up front.
An excellent strategy that is also important in systems where latency must be predictable.
|
|
|
|
|
Greg Utas wrote: One way around this is to allocate in slabs
Right, but you're still allocating. Initially I didn't realize the issue was strictly fragmentation. My TTF rasterizer already uses a custom pool/heap for allocations.
Greg Utas wrote: If the memory manager uses buddy allocation and you allocate temporary memory and then free it all before allocating more, fragmentation should be avoided altogether.
Typically I allocate for the span of an operation in order to improve performance. Sometimes I fallback to a slower method if I can't allocate, so it gets used like a cache. It gets freed once the operation completes.
This is the case in every situation in my graphics library save a couple of very explicit things like "large bitmaps" which are actually composed of a bunch of smaller bitmaps because of heap fragmentation, and things like SVG documents (which are actually kind of small).
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Greg Utas wrote: If the memory manager uses buddy allocation and you allocate temporary memory and then free it all before allocating more, fragmentation should be avoided altogether.
Every time I mention buddy allocation, someone stand up, shouting about internal fragmentation.
That usually goes into a lengthy discussion about the fraction of allocations being 2-powers, how much you should allow yourself to fine tune memory use by, say, changing a long to an int to bring the allocation size down from 516 to 512, and so on. Usually, the shouters end up admitting that an average of 25% internal fragmentation is overly pessimistic.
Buddy allocation is certainly not very much valued among my professional friends. I love it.
|
|
|
|
|
I think one reason buddy allocation originally became popular was its very low management overhead. There may be better schemes, but they would use more management overhead to reduce fragmentation and would need a background task (like a garbage collector) to merge adjacent free areas, something that buddy allocation does on the fly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
