You think that movie-like exoskeletons make perfect sense for practical purposes, are physically doable and only a bit far away technologically speaking. I don't agree with any part of that summary for multiple reasons, but I don't see the point of continuing this conversation. Sorry, but I don't like talking too much in so generic terms and have spent already a quite relevant time here. My ideas are exactly the same than when I wrote my first post, guess that yours too and am OK with that.
think of it as an excavator with a different toolset and interface
But what is the point of having a person inside it if he cannot directly perform the moves? Wouldn't be much better to have a remotely-controlled machine? I can understand a setup on these lines in case of having an appearance which might be appealing to some people (e.g., robot fights), but it doesn't seem the most practical approach for almost anything else.
Hard controls problem != physical impossibility
Exerting certain level of force and lifting certain things from certain positions by involving only certain mass is either practically or completely impossible. I didn't mean to just keep the balance, what is already a quite difficult task, but to be in a position to generate certain amount of force while being standing, jumping, moving, etc.
you seem to be confusing technical challenges with limitations of physics.
I don't think so. Again, my comment was mostly focused on their suitability to exert certain force under conditions which make such an event almost impossible. The underlying idea to most of these fantasies is assuming behaviours similar to human/animal muscles by extending the boundaries beyond what is physically possible. Creating a tentacle moving like Dr. Octopus's and being able to lift heavy weights isn't just extremely difficult from a technical point of view, but also almost impossible according to physics.
Even by assuming that you could create/control something on these lines, the final part of the tentacle wouldn't be able to lift almost anything, simply because of not having enough torque. Just think about how much weight a snake could lift with its head. You have to measure the available torque/distance from the last muscle up to the head which is very small. Additionally, the force you can exert in that last muscle is quite low already due to the high effort required to do virtually anything (lots of movements/muscles = lots of small forces which have to be systematically generated). Even simpler: think about beating (or lifting or performing any other action) with the end of a rigid stick vs. a flexible one.
That expression has no meaning to me since some time ago. At least, not in internet.
A full exoskeleton, though, which itself provides the leg and spine structure, has no real upper limit on carrying capacity.
As clarified above, if the person's body isn't participating directly, yes, although it would be pretty pointless/uncomfortable. In any case, bear in mind that most of machines can lift so heavy stuff in part thanks to being operated under static/perfectly balanced conditions. Creating a robot walking like a person and lifting anything as a person does would be quite difficult too because of the associated instability. Most of actions performed in a movie like Ironman would be extremely difficult or directly impossible, regardless of the fact of having a person inside or not.
Doctor Octopus, btw, doesn't inherently violate physics
You are kind of right, but only in the cases where he isn't standing on his feet or other part of his body. And even when everything is managed by the tentacles, his body would suffer a relevant amount of stress (something like lifting 1 ton seems also out of picture because of this). Additionally, making these tentacles behave as they do, like snakes with lots of mobility, would be a nightmare of complexity and provoke them to become quite weak. The way to make them a bit stronger would be via some external system, what would notably reduce their flexibility.
I appreciate your process and comfort, but another C++ advantage is that lots of people know C++, whereas it appears that only a very few people (perhaps just you) understand your framework and how to use it. For a one-person project that doesn't need to outlive its maintainer, that's not a problem.
If I am out, all my code comes with me? I like that. LOL. Seriously though, this is really "a one-person project that doesn't need to outlive its maintainer" because its maintainer is the same person than its owner, promoter, developer, etc. = myself. I am using it just as a self-promotion of my real income source (being hired to work on whatever development) and only as a final executable because I will keeping it as private source for the time being. Honestly, I don't think that my methodology is so difficult to understand when its point is precisely to be user friendly for a person with limited C expertise, but I am fine with this not being the case too. As said, I only started this mini-thread and considered the eventuality of releasing an independent library because of thinking that other people might find it helpful. Nobody interested? OK, less publicly-releasing work for me:)
Logically, the driver of whatever machine isn't useless, right the contrary. I meant creating a sci-fi exoskeleton (what this whole sub-thread is about) performing whatever human-like action with a person inside not doing anything. Anyway, I guess that my point is pretty clear already and, if not, I don't care because will not clarify it further.
Just to make sure that we are on the same page: if you create whatever machine able to lift certain weight and put a person freely moving inside without any contact with the structure, it might be OK (extremely uncomfortable and pretty useless though). What I meant was the person's body also participating like what happens with a robotic arm or Spiderman's Doctor Octopus.
So, physics makes no sense? Or have you found a way to create an action without a reaction?! Please, share your discoveries with all of us! LOL.
A robot suit can easily lift a ton
Because the robot itself is bearing the corresponding reaction and, lately, transmitting it to floor/walls.
More commonly we call them forklifts.
Excellent all that, but again: how the action/reaction balance is supposed to happen and be transmitted across all the given structure to transform moving a lever into actually lifting 1 ton? Do you have even basic physics (mechanics, which is the the branch of physics dealing with this kind of analysis) knowledge to understand what is going on when something lifts something? You have to perform a static analysis where all the forces have to be fully equilibrated at each point of the machine and the person's body in case of the referred impossible exoskeleton.
There is no reason we can't make them with two legs instead of four wheels.
Sure. You can create a machine emulating a person's body if you wish, but better make sure that you rely on steel or other strong enough material to bear all the stress. In people, the reactions are provided by our muscles which have an upper limit, that's why we cannot lift 1 ton or be an active part of a system lifting such a weight.
So, you are suggesting me to get a proper/objective idea about something by watching what the author of one of the alternatives says about his baby? It doesn't sound like a too reliable source. LOL.
I assure you that 90% of the criticism of C++ Here is bogus,
I care pretty much the same about baseless criticism than promotion. I haven't read/cared/made any decision based on what a random person might write here or anywhere else about C++ or any other target of (honestly, no idea why this is the case at all) unreasonable hate/love. I mostly trust myself and my actual experience in whatever, what I might eventually complement with reasonable, empirically-proven ideas, sensible opinions of people who have shown a proper understanding/knowledge in the past and, in general, any further input, but mostly validated via personally confirming whatever statements are true/applicable to my situation.
As explained since the first moment, moving the referred development to C++ is completely out of picture because of not making any sense under my specific conditions; namely: the code being already quite big and performing perfectly and me feeling quite comfortable with C (+ the dealing-with-C peculiarities approach I came up with). Additionally, one of the main reasons why I firstly thought about C despite my limited experience with it (I am a senior programmer with tons of experience in many other languages) was taking this development as an excuse to properly practice my skills on a so peculiar format. Since my first comment in this thread, I let my position completely clear and also what I was exclusively interested in: C programmers sharing their impressions about the approach I came up with, not because of having any problem about it or doubts or wanting to change anything, just out of pure knowledge extension: I am always looking for knowing more, improving further, etc. what has nothing to do with the behaviour which quite a few of you have been showing here (= almost fanatic adhesion to your approach and systematically trying to convince anyone else to do the same than your do mostly via systematic repetitions?! Why? For what? I will never understand these behaviours!). In fact, the main reason why I firstly posted here was to somehow share my quite positive experience and my non-existent problems when dealing with the C peculiarities about which so many people are systematically complaining.
It seems that whatever I ask here (or in similar places) is automatically misinterpreted as a cry for help rather than as part of what any truly knowledgeable person should systematically be doing (are you seriously so blind that think that asking/wondering/always learning more isn't part of what having actual knowledge implies?). Some of you seem quite knowledgeable and some others extremely ignorant, but all of you share the same "I will teach you whatever canned bit" underlying nonsense! Teach me what? I am feeling so confident about my programming background that I have started a really tough development in a language like C, in which I haven't ever done any relevant work! I made that decision on the spot! I didn't do even a slight research about how should I proceed or what was the most recommendable proceeding! I plainly made many mistakes, learned from them and built an extremely-friendly-for-me approach pretty much on the go! Now, I am coding in C almost as intuitively and carelessly as I do in a modern programming language! I know that I can locate/debug those memory problems you are so scare about almost immediately! The piece of software I am developing is quite complex and is expected to have a good performance under very demanding conditions! And I have reached that stage in a few months, by bearing in mind that this is a quite secondary, R&D, in-my-free-time development! Most of you don't seem to be able to properly understand what I am describing and to properly assess its int
C++ compilation might take longer, but it is no where close to necessary that the executable is less quicker than that of C
This statement is as abstract as all the other ones written in previous comments here and even my preliminary assumption of expecting C to be quicker. As said to many other people before: I haven't done any proper benchmarking and, consequently, I am not in a position to absolutely confirm my looking-pretty-evident-to-me assumption. You or anyone else is welcome to do/refer a proper benchmark; otherwise, you can wait for me to do it myself what isn't precisely in my urgent-to-do list. You can also continue talking generically and without providing any kind of tangible support to your words by absolutely confirming/denying whatever concepts you think that make more/less sense, but please don't count me in.
Just in case this isn't clear to everyone and even by forgetting about different aspects highly constraining what/how can be lifted, note that an equivalent resisting force is required to help during the process and keep it up. If you rely on air, you would need to carry a mass of air equivalent to what you would be lifting. That's why the typical robo-exoskeleton shown in movies allowing a random person to lift 1 ton is plainly impossible: that person would have to provide most of the required force reacting to that ton.
As I said before: designing a system where every function frees the first argument, instead of freeing it yourself, is WRONG.
Are you seriously so stupid? Because it is quite clear to me that you are a quite dishonest person whose motivations aren't properly/adequately learning/understanding; no idea about why you do what you do and honestly don't care. But, on top of that and your evident lack of knowledge, you seem particularly stupid! Apparently, my previous comment was still too complicated for you. Unfortunately, I don't have any puppets with me at the moment, but I will try a still clearer version:
1. Go back to the sample code which I wrote yesterday to try to address your "internal world". 2. In LoopNoFunction, copy the var1 set (up to the first free(var0)) 10 times. Change all the variable names such that they remain unique; you can try with var3, var4, var5, etc. Do the same with LoopFunction. 3. Now, you can redo the "experiment" in my post above and confirm that everything continues working/not if you remove/not any intermediate free. 4. What have you learned now? That you can call that function as many times as you wish without caring about freeing the variable you are using (BTW, if it was an array, the freeing process would have been more complex than just calling free). Without the function, you would have to write as many free as times you re-malloc the variable. Additionally, if you miss any of them you might provoke a serious problem. So, rather than always calling free (or a method to perform the more complex freeing actions on an array) before calling that function, you can include that free inside the function itself! What implies both a lower number of irrelevant writing and a safer approach (= you will never forget about that free).
You should bear in mind that this is just a very simple example helping you to understand what others understood immediately and without any additional help. The final goal is to always call whatever method without caring about malloc/pre-freeing malloced variables. A more descriptive example I wrote in a previous post: var1 = concatenate(var1, var1, var2); which performs the concatenation in a local variable, frees var1 (if required), mallocs it and copy that temporary variable to var1 which is returned; everything in 1 line what cannot be accomplished right away in any other way (you would have to rely on a temporary variable). What this approach does is accepting the underlying C/mallocing-freeing reality and simplifying its usage. I have been using this methodology for a while with a big number of different methods and it is extremely intuitive and error-free. Modesty apart, I came up with this approach (as more comprehensively described in other comments) within the first month of using C (for the first time in the last quite a few years; never for an important development) for a quite demanding implementation, got used to it and now (a few months later), I feel almost as comfortable with that format as with the more modern programming languages on which I usually rely: I almost make no mistakes and immediately debug the few I do. I will certainly keep further evolving/optimising it, but it already represents a quite good first version of what I intended to do: an intuitive way to easily deal with C for someone whose experience is mainly focused on managed-memory/modern programming languages. Anyway, sorry again for the lack of puppets and for having used so many words; and hopefully I will not talk to you ever again, at least, not before you evolve into a person (if you get there at all).
I see. I will try a version more adapted to your "peculiarities". Just follow the instructions below as well as you can, if you don't know how to do one of the steps, don't worry, because you tried and this is all what matters: someone, somewhere might eventually (and probably undeservedly) love you (I guess).
1. Open your C compiler/IDE (if you need help on this, go to Youtube, type C compilation and watch the first video with puppets which you can find). 2. Paste this code into the main file. 3. Call LoopNoFunction() from the start up method, compile/execute and confirm that runs without any issue. 4. Open your system memory log (CTRL+ALT+DEL on Windows or console+a program like htop on Linux), remove the first free(var0); in LoopNoFunction(), compile/run and be ready to terminate the execution as soon as possible (the memory usage will go up quite quickly!). This is why you have to release an allocated variable before reallocating it again! 5. Now test LoopFunction() and confirm that it works fine like in step 3. Why? Because that function frees the variable every time. How can it do such a thing? Because it takes as a first argument the variable to be freed/returned! Magical, don't you think!
Although it seems quite safe assuming that the reality language1 vs. language1+more-things-on-top is associated with the first language being quicker, I cannot tell it for sure because I have never done a proper benchmark. So, it is extremely likely (according to basic objective common sense) that C is faster than C++ in these scenarios, but I cannot tell it for sure: I am honest person with a bit self-respect and professionalism who will never say that something is in some way for sure without having actually confirmed it. As said in other comments, I will do some serious benchmarking when possible; meanwhile, I will be happy with an application notably faster than other existing approaches. Also, feel free to back your absolute statement with something tangible.
OK. Although I honestly don't fully get your behaviour as far as I already said that I was assuming that you were kidding, but you continued anyway in a not particularly funny fashion! It has been something like "You are kidding! - No, I am not! - OK, then let me explain... - Haha, I was actually kidding!". Well, if you are happy and nobody was harmed, I guess that everything is fine; but please never invite me to your comedy show:)
Why the funk is your example function freeing its first argument? And how can you come to the idea that this makes any sense?
OK. I will explain what I see wrong with your behaviour (which curiously haven't happen to any other commentator, but well...). Firstly, the answer to your question is implicit in my first post: the variable which is the first argument has the same name than the one taking the returned value which isn't declared there (= was declared before and perhaps something like a malloc happened). So, just by looking at the code, some people might know the answer, but additionally I expressly said "The first argument of all these methods (stringVariable in the sample) is the output variable" (output variable in that context seems quite evident that refers to the one being returned by the method). So, that first argument isn't exactly an argument in the conventional sense of the world, but the variable to be returned. Even despite all that, you might still have some doubts about that variable having to be freed. How to know that it was malloced before? Because I guess that you know that you have to free all the malloced variables before mallocing them again (this is precisely the reason for that first argument: reusing a variable which was malloced before). A sensible person being in that situation would ask me about that scenario and I would have answered "because all the string variables in that code are always instantiated via malloc". Even though none of the other commentators (all of them with apparently good knowledge about C/C++) had any doubt on this front, you might have missed that issue and asked me. But you didn't ask, you said "the stuff you do is just nonsense. Why the heck would your example function Concatenate_m call "free" on any of its arguments", so you aren't understanding what anyone else does and, on top of that, you don't ask, but attack?! Do you get it already? I don't think so. Do you know why? Because most of our previous 20 something iterations have been exactly like this one. I honestly don't know what is your problem (with me) and I don't care. This will be my last explanation: learn to behave (+ talk only if you know) or be ignored.
Although you seem a quite knowledgeable and sensible person, you are mostly making generic and kind-of-out-of-context references. For example, you are relying on too many generic descriptions (= out-of-context definitions) whose real value is close to zero; you call O(n) something as simple and quick as calling strlen (-> looping through the characters of a single string! One of the fastest things ever) and compare that situation with any other one which you consider that deserves the O(n) label. This is a tremendously inaccurate analysis. Just for your information and out of all the critics you have made to my heap reliance, the only relevant issue is (slight) performance differences which, as said, are partially compensated by my intention of making the whole approach consistent (+ eventually, further optimisable in the future) and string-size-/memory-availability-independent enough. On exchange of that, I get the lightest programming resources (= just pure C), a friendly(-at-least-for-me) environment and the most adaptable/improvable/extensible code which I might further improve/modify in the future, even though it is currently outperforming big names in their field (developed mostly in C++, I think).
I am afraid that this conversation has moved from actually-trying-to-understand/help to the fanatic-like (no offense intended) world, more focused on generic certainties whose reliability in general or under the given conditions is usually none. I am particularly intolerant to said behaviours because I think that they represent pretty much all what is wrong with the software development world: ideally, an objective-correctness/technical field where everything can be easily confirmed/dismissed; practically an extremely faulty sub-world where many people with limited knowledge and not precisely honesty/objectivity in their minds think that can impose whatever egoist interest via group-pressure/repetition. Again, I think that you are a quite knowledgeable person and I am not even completely dismissing some of your points (and will certainly do some tests); but unfortunately you seemed to have misinterpreted my interest about knowing more and going further with me lacking/expecting a canned-knowledge dose. I am grateful for your insights, will certainly welcome any tangible proof of any of your abstract points (I can link a public repository including a descriptive sample of the code I have been commenting if you want) and don't want to offend you, but this has been more than enough abstract talking for me.
You are strongly advised to get a teacher, the stuff you do is just nonsense.
Why the heck would your example function Concatenate_m call "free" on any of its arguments?
??!! You can answer posts without caring about the signature all you want (-> this is what you said me the last time we talked), but I cannot refrain myself from remembering you. Out of all the conversations we have had (not sure, but I think that you might have written me over 20 posts), I have only read one sensible enough comment (the previous to the last one). The rest of them are so ridiculous (+ aggressive?!) that I don't even know how to answer them! Make yourself a favour and read what all the other people in this thread have written and compare them with your nonsense!! Seriously, what is wrong with you? Please, learn to behave or ignore me. I will be extremely non-patient with you and, in case of doubt, I will simply not reply you. This is the last time I clarify you nothing.
What I'm getting out of that is that you carefully constructed a string library that needs some conventions to be safe, and doesn't do complicated things because that gets buggy.
Not exactly. I started a quite demanding development by relying on a language in which I have not too much experience (even though I have lots of experience in many C-based languages). As far as I am not used to the C peculiarities, I spent a relevant amount of time at the start in coming up with a friendly framework allowing me to write code more or less as usual; so, I created quite a few string-modifying methods (because this aspect is very important in that development) similar to the ones you can find in many modern languages. Gradually, I realised about the importance of having an easy-to-use methodology to deal with C memory peculiarities, came up with a methodology and adapted those first methods to it. Despite understanding the importance of that initial part, this was logically quite secondary and that's why I didn't want to spend too much time on it (+ needed to actually test the approach to confirm/dismiss it was really allowing me to comfortably write code). In a first moment, I accounted for multiple-time-used variables, but that approach wasn't too friendly (at least, not for me); that's why I finally decided to let it as explained here: just 1-reuse per variable (anything beyond that requires a temporary variable). I have been using this methodology during the last months for that development and I am quite happy with the results. There is a public repository if you want to get a better picture about all this. In fact, I did include a link to it in one of past conversations, not sure if you visited it.
I'm not knocking your achievement
The referred methodology isn't exactly an achievement, but a side-effect of me wanting to work comfortably. My only relevant achievement here is the resulting application (because I am keeping its main code private for the time being) which is still in a very preliminary/beta stage. On the other hand, I am reading lots of people having problems with C and I am so comfortable with that methodology that I have even thought about creating an independent library to be used by anyone interested. I even asked here in a previous thread, but nobody showed any interest.
but you get most or all of that in C++ for free with simpler syntax. With C++, you get a lot of it in template format
As commented to others here and to you in the past, I am very happy with this approach and will continue doing that development in C. Out of curiousity and to confirm/dismiss what honestly aren't more than reasonable assumptions, I might do some serious benchmarking C/C++ to get better insights into their performance differences. I might also test/further optimise my approach to see whether it might be even faster. But all those are now secondary concerns for me as far as the performance so far is excellent and I am very comfortable by doing that development in plain C.
Okay, so the ownership semantics for the second argument (and later ones?) is always that of a non-owning pointer, so you must explicitly free it.
It it seriously not that difficult. You seem to be more interested in looking for problems than in properly understanding what I am explaining! Let me try it again: all the string variables in this code have been instantiated in the same way (i.e., via calling one of the multiple methods, all of them relying on the same basic malloc/free rules) and all of them are expected to be freed right after being used. You can call one of these methods with 10 arguments and it would only care about freeing/not the first one; all the remaining ones are mostly used as constants and, in any case, they will never be freed/allocated/ inside those methods. So, if you do var1 = whateverFunction_m(var1, var2, var3, var4), you would get a properly malloced var1 which has to be freed and other three variables, whose allocation happened at previous points, which will be freed after their last usage, whateverFunction_m doesn't care about any of them. In fact and as far as I am mostly relying on local variables, the "_m" flag is almost irrelevant because all the string (or array) variables declared in a given method have certainly be instantiated via malloc and certainly need to be released before existing the given method. Do I need to make the small effort to write free/call the array freeing method for each allocated variable? Yes. Would I prefer to not worry about anything of this? Yes. Is that a tremendous problem for me? No, at least not after having got used to this methodology. In case of making a mistake, it would be extremely difficult for me to locate a wrong (de)allocation bit? No, I have done it already quite a few times; every time very quickly. Do I expect everyone to like, use and enjoy that approach? No! Does it work for me? Yes. Is everything clear now?
You're still doing the malloc / copy, you're just doing it inside the function.
This is precisely what I meant, sorry for not having phrased it properly.
No, a well-optimised string library in C (such as glib strings) will be faster than wrapping a well-optimised string library in a scripting language. In contrast, you're using a set of API design choices that preclude most of the common string processing optimisations.
Not so sure about that, but as said in a previous comment I wouldn't mind to do some proper tests to confirm these issues. In any case, this development is going quite well for me so far + have lots of over-work and will look into all this at other point.
Your design, using raw C strings, prevents you from storing a length separately (so you keep needing O(n) strlen calls), prevents you from implicitly sharing large strings (so you need O(n) copies) and prevents you from deferring copying using the twine optimisation (so you need more O(n) copies). It's such a case study in bad design that Raymond Chen wrote a blog about how not to do string processing 20 years ago describing it.
Well, perhaps I should also take a look at this part too. Two comments though: I am getting the length at allocation and almost never call strlen at a later point; I prefer to sacrifice a bit on exchange of overall consistency/ease of use (a bit which might remove at a later point via over-optimisation of a properly working code).
the performance of an interpreted scripting language
As far as you keep making that pointless comparison, I will also highlight that some of the referred methods perform (logically, slightly different versions of) actions delivered by in-built C methods and that I did some preliminary comparisons where both these versions were proven to have a similar performance. I have also to do much more testing on this front, again at a later point. If that future tests prove that my versions are appreciably slower, I certainly will consider to somehow modify my approach.
Try some benchmarking with various optimization flags (people usually settle on -02 as default optimization level) and see which is better for your needs.
I am a bit saturated with work and that specific development is already way behind schedule, but your suggestion is quite reasonable. I will do a proper benchmarking at some point to confirm my preliminary assumptions.
Having multiple copies of your string pointer, possibly storing one or more of them in a struct and knowing when the free should be called.
I rely every time on the same proceeding: new malloc (indirectly via call to any of those methods). Most of my code is based on local variables and, for global ones, I had created specific populate/free methods (BTW, there are also methods to properly free arrays). As commented to others, I perfectly understand the limitations of C, even my approach; trying to do something similar just for some other developments in which I am working would be a true nightmare. But this specific implementation is quite C-peculiarities-compatible and I have kept the code as plain and simple as possible. Main main concerns are: as fast as possible (+ as less external resources usage as possible), as intuitive/me-friendly as possible and as problem-free as possible (= regularly repeating equivalent patterns, relying on local variables, etc.).
The biggest issue with your approach is that it assumes that you personally are infallible. You might be good, but you aren't that good. And the impact of screwing it up is high.
I am certainly not (just look at the numerous errors in a big proportion of my posts here. LOL) and I can make mistakes by using C or any other language. In the specific case of C and, at least for someone with my modern-language background, the main problem is memory (de)allocation and that's why I came up with this friendly-to-me methodology. I can make many errors in this code, but will certainly minimise and quickly locate/fix all the memory-related ones.
I strongly suggest looking at the talloc library
Thanks for the suggestion. I will look at it at some point. In any case, I am almost certain that will not use it in the current implementation as far as it would go against my two main concerns: minimising reliance on external resources and getting properly used to work with C.
Getting the best performance possible was one of my main concerns since the very beginning of this project, that's why I chose C (additionally, I wanted to work on this language which I haven't used much since quite long time ago). As commented to others, relying on C++ under these conditions as a way to slightly minimise the C unfriendliness doesn't make too much sense: firstly, because it will always come at a (performance) cost; and secondly because the way to get comfortable with a language isn't precisely avoiding it. I personally have no problems with the described approach and, as per all the comments so far, I don't see any compelling reason to stop using it/rely on C++
Except in your example, where one of them was a string literal (so const char * and definitely not safe to free) and the other was a heap-allocated char*.
That scenario isn't possible, as far as there is no string literal assignation. Rather than doing stringVar = "string literal", I always do stringVar = AssignStringLiteral_m(NULL, "string literal");. As said, all my code is extremely consistent and inter-compatible.
It may be simpler, but now you're doing a lot of redundant memory allocation, a lot of redundant copying, and tying all consumers of your code to the implementation of your data structure.
I am not sure if you got the idea. Rather than reusing the same variable in various calls; I rely on a temporary variables. The proposed format works fine upto 1 variable reuse. Allocation/deallocating small amounts of memory (= dealing with local variables in any language automatically dealing with memory allocation) doesn't seem an issue.
I doubt that the performance will be better than doing the same thing in a scripting language (probably worse, because most scripting languages have fairly well optimised string implementations), so you're doing manual memory management to get worse performance.
Why? All what I am doing is avoiding writing malloc, string copy, etc. every time and call methods performing those actions. Are you saying that string operations in C are slower than in a scripting language? I don't think that this is even close to being true. Just for your information, I am comparing the preliminary versions of the resulting piece of software against well-established programs (i.e., database management tools like MySQL or PostgreSQL) and it performs notably better in quite a few scenarios; although it is quite difficult to tell for sure what is the most influential aspect (algorithms/data structures or optimised usage of C), a bad language usage wouldn't allow such a situation to happen.
and yet you're willing to use O(n) algorithms and lots of malloc / free calls in places where constant-time algorithms would work with far fewer malloc / free calls and with much better cache usage?
No idea where you are getting all that from what I have written so far. The only weak point of the described approach might be relying on malloc rather than on a quicker string definition, which is also associated with a much lower available space what isn't precisely ideal under my specific conditions (should be able to deal with strings of any size). I might take a further look at all this at a later stage to further optimise its performance; for the time being, my only concern was coming up with an approach allowing me to intuitively maximise the C performance and that seemed a quite acceptable trade-off.
You don't, by any chance, work on Enlightenment do you?
I don't get that reference. If you are really asking me whether I work for a company called Enlightenment, I am not. I am a self-employed and this has been an R&D+practicing-a-bit-C project which is part of my self-promotion. I am always trying to learn/improve, help potential clients to know more about my skills, etc.
What you are saying is also true for any managed-memory language. C++ smart pointers might be an intermediate step between pure C and a language automatically managing all the memory related aspects, but they still represent a (performance) cost. Logically, I would prefer to not worry about memory (de)allocation at all, although I am using C for this development for good reasons: I want that program to be as quick as possible and all the required code is quite simple in the sense of not really needing complex programming resources.
What is the type of stringVariable? If it's char*, then how do I know when it's been stored on the heap and read back that it's dynamically allocated on the heap and so needs freeing?
It is char* and has certainly been stored on the heap because everything is instantiated via malloc. As said, one of my intentions was too create an overall consistent approach usable in any situation. I don't need to worry about different types of strings or any other thing: everything is compatible with everything else and has the same requirements like calling free afterwards.
What are the ownership semantics of the first argument to StringAction_m? Since you're assigning the result to the input variable, I presume that it's taking an owning reference and explicitly destroying it?
When you call StringAction_m, you can choose to instantiate a variable from scratch and not care about anything else by passing the first argument as NULL or else. A descriptive example to understand that second scenario is concatenation (this is precisely where I firstly though about that approach); if you want to concatenate stringVariable2 to stringVariable1, the call stringVariable1 = Concatenate_m(stringVariable1, stringVariable1, stringVariable2); performs the concatenation in a temporary variable, frees stringVar1 and copies that temporary variable to stringVar1 which is then returned.
What happens when you have types that have more complex destruction than a simple free? For example, if you're doing a lot of string processing you probably want some kind of twine abstraction so that you don't end up doing a lot of temporary copies, but now your string data type is a linked list internally and just calling free on the first element will give you a memory leak.
In one of the first versions of that approach, I accounted for more complex scenarios but everything became too buggy and problematic. So, finally I decided to rely on the shown simple structure and, for complex situations, I simply rely on (+ free) temporary variables by calling these methods as many times as required. Once you get used to the format, it is quite intuitive.
TL;DR: It's not a question of what you can do in a language, it's a question of what you can do without thinking.
I am not absolutely defending one language over other one, not here and not anywhere else. Under my specific conditions where performance is a very important aspect, C seems a better option. Again for that specific scenario (quite low-level-ish, where I am mostly relying on quite simple programming structures), the proposed approach seems quite friendly: I have came up with/got used to it relatively quickly.
Slashdot Mirror
You think that movie-like exoskeletons make perfect sense for practical purposes, are physically doable and only a bit far away technologically speaking. I don't agree with any part of that summary for multiple reasons, but I don't see the point of continuing this conversation. Sorry, but I don't like talking too much in so generic terms and have spent already a quite relevant time here. My ideas are exactly the same than when I wrote my first post, guess that yours too and am OK with that.
think of it as an excavator with a different toolset and interface
But what is the point of having a person inside it if he cannot directly perform the moves? Wouldn't be much better to have a remotely-controlled machine? I can understand a setup on these lines in case of having an appearance which might be appealing to some people (e.g., robot fights), but it doesn't seem the most practical approach for almost anything else.
Hard controls problem != physical impossibility
Exerting certain level of force and lifting certain things from certain positions by involving only certain mass is either practically or completely impossible. I didn't mean to just keep the balance, what is already a quite difficult task, but to be in a position to generate certain amount of force while being standing, jumping, moving, etc.
you seem to be confusing technical challenges with limitations of physics.
I don't think so. Again, my comment was mostly focused on their suitability to exert certain force under conditions which make such an event almost impossible. The underlying idea to most of these fantasies is assuming behaviours similar to human/animal muscles by extending the boundaries beyond what is physically possible. Creating a tentacle moving like Dr. Octopus's and being able to lift heavy weights isn't just extremely difficult from a technical point of view, but also almost impossible according to physics.
Even by assuming that you could create/control something on these lines, the final part of the tentacle wouldn't be able to lift almost anything, simply because of not having enough torque. Just think about how much weight a snake could lift with its head. You have to measure the available torque/distance from the last muscle up to the head which is very small. Additionally, the force you can exert in that last muscle is quite low already due to the high effort required to do virtually anything (lots of movements/muscles = lots of small forces which have to be systematically generated). Even simpler: think about beating (or lifting or performing any other action) with the end of a rigid stick vs. a flexible one.
obvious to anybody
That expression has no meaning to me since some time ago. At least, not in internet.
A full exoskeleton, though, which itself provides the leg and spine structure, has no real upper limit on carrying capacity.
As clarified above, if the person's body isn't participating directly, yes, although it would be pretty pointless/uncomfortable. In any case, bear in mind that most of machines can lift so heavy stuff in part thanks to being operated under static/perfectly balanced conditions. Creating a robot walking like a person and lifting anything as a person does would be quite difficult too because of the associated instability. Most of actions performed in a movie like Ironman would be extremely difficult or directly impossible, regardless of the fact of having a person inside or not.
Doctor Octopus, btw, doesn't inherently violate physics
You are kind of right, but only in the cases where he isn't standing on his feet or other part of his body. And even when everything is managed by the tentacles, his body would suffer a relevant amount of stress (something like lifting 1 ton seems also out of picture because of this). Additionally, making these tentacles behave as they do, like snakes with lots of mobility, would be a nightmare of complexity and provoke them to become quite weak. The way to make them a bit stronger would be via some external system, what would notably reduce their flexibility.
I appreciate your process and comfort, but another C++ advantage is that lots of people know C++, whereas it appears that only a very few people (perhaps just you) understand your framework and how to use it. For a one-person project that doesn't need to outlive its maintainer, that's not a problem.
If I am out, all my code comes with me? I like that. LOL. Seriously though, this is really "a one-person project that doesn't need to outlive its maintainer" because its maintainer is the same person than its owner, promoter, developer, etc. = myself. I am using it just as a self-promotion of my real income source (being hired to work on whatever development) and only as a final executable because I will keeping it as private source for the time being. Honestly, I don't think that my methodology is so difficult to understand when its point is precisely to be user friendly for a person with limited C expertise, but I am fine with this not being the case too. As said, I only started this mini-thread and considered the eventuality of releasing an independent library because of thinking that other people might find it helpful. Nobody interested? OK, less publicly-releasing work for me :)
Why useless?
Logically, the driver of whatever machine isn't useless, right the contrary. I meant creating a sci-fi exoskeleton (what this whole sub-thread is about) performing whatever human-like action with a person inside not doing anything. Anyway, I guess that my point is pretty clear already and, if not, I don't care because will not clarify it further.
Just to make sure that we are on the same page: if you create whatever machine able to lift certain weight and put a person freely moving inside without any contact with the structure, it might be OK (extremely uncomfortable and pretty useless though). What I meant was the person's body also participating like what happens with a robotic arm or Spiderman's Doctor Octopus.
Makes no sense
So, physics makes no sense? Or have you found a way to create an action without a reaction?! Please, share your discoveries with all of us! LOL.
A robot suit can easily lift a ton
Because the robot itself is bearing the corresponding reaction and, lately, transmitting it to floor/walls.
More commonly we call them forklifts.
Excellent all that, but again: how the action/reaction balance is supposed to happen and be transmitted across all the given structure to transform moving a lever into actually lifting 1 ton? Do you have even basic physics (mechanics, which is the the branch of physics dealing with this kind of analysis) knowledge to understand what is going on when something lifts something? You have to perform a static analysis where all the forces have to be fully equilibrated at each point of the machine and the person's body in case of the referred impossible exoskeleton.
There is no reason we can't make them with two legs instead of four wheels.
Sure. You can create a machine emulating a person's body if you wish, but better make sure that you rely on steel or other strong enough material to bear all the stress. In people, the reactions are provided by our muscles which have an upper limit, that's why we cannot lift 1 ton or be an active part of a system lifting such a weight.
watching Bjarne Stroustrop's excellent presentations
So, you are suggesting me to get a proper/objective idea about something by watching what the author of one of the alternatives says about his baby? It doesn't sound like a too reliable source. LOL.
I assure you that 90% of the criticism of C++ Here is bogus,
I care pretty much the same about baseless criticism than promotion. I haven't read/cared/made any decision based on what a random person might write here or anywhere else about C++ or any other target of (honestly, no idea why this is the case at all) unreasonable hate/love. I mostly trust myself and my actual experience in whatever, what I might eventually complement with reasonable, empirically-proven ideas, sensible opinions of people who have shown a proper understanding/knowledge in the past and, in general, any further input, but mostly validated via personally confirming whatever statements are true/applicable to my situation.
As explained since the first moment, moving the referred development to C++ is completely out of picture because of not making any sense under my specific conditions; namely: the code being already quite big and performing perfectly and me feeling quite comfortable with C (+ the dealing-with-C peculiarities approach I came up with). Additionally, one of the main reasons why I firstly thought about C despite my limited experience with it (I am a senior programmer with tons of experience in many other languages) was taking this development as an excuse to properly practice my skills on a so peculiar format. Since my first comment in this thread, I let my position completely clear and also what I was exclusively interested in: C programmers sharing their impressions about the approach I came up with, not because of having any problem about it or doubts or wanting to change anything, just out of pure knowledge extension: I am always looking for knowing more, improving further, etc. what has nothing to do with the behaviour which quite a few of you have been showing here (= almost fanatic adhesion to your approach and systematically trying to convince anyone else to do the same than your do mostly via systematic repetitions?! Why? For what? I will never understand these behaviours!). In fact, the main reason why I firstly posted here was to somehow share my quite positive experience and my non-existent problems when dealing with the C peculiarities about which so many people are systematically complaining.
It seems that whatever I ask here (or in similar places) is automatically misinterpreted as a cry for help rather than as part of what any truly knowledgeable person should systematically be doing (are you seriously so blind that think that asking/wondering/always learning more isn't part of what having actual knowledge implies?). Some of you seem quite knowledgeable and some others extremely ignorant, but all of you share the same "I will teach you whatever canned bit" underlying nonsense! Teach me what? I am feeling so confident about my programming background that I have started a really tough development in a language like C, in which I haven't ever done any relevant work! I made that decision on the spot! I didn't do even a slight research about how should I proceed or what was the most recommendable proceeding! I plainly made many mistakes, learned from them and built an extremely-friendly-for-me approach pretty much on the go! Now, I am coding in C almost as intuitively and carelessly as I do in a modern programming language! I know that I can locate/debug those memory problems you are so scare about almost immediately! The piece of software I am developing is quite complex and is expected to have a good performance under very demanding conditions! And I have reached that stage in a few months, by bearing in mind that this is a quite secondary, R&D, in-my-free-time development! Most of you don't seem to be able to properly understand what I am describing and to properly assess its int
C++ compilation might take longer, but it is no where close to necessary that the executable is less quicker than that of C
This statement is as abstract as all the other ones written in previous comments here and even my preliminary assumption of expecting C to be quicker. As said to many other people before: I haven't done any proper benchmarking and, consequently, I am not in a position to absolutely confirm my looking-pretty-evident-to-me assumption. You or anyone else is welcome to do/refer a proper benchmark; otherwise, you can wait for me to do it myself what isn't precisely in my urgent-to-do list. You can also continue talking generically and without providing any kind of tangible support to your words by absolutely confirming/denying whatever concepts you think that make more/less sense, but please don't count me in.
Just in case this isn't clear to everyone and even by forgetting about different aspects highly constraining what/how can be lifted, note that an equivalent resisting force is required to help during the process and keep it up. If you rely on air, you would need to carry a mass of air equivalent to what you would be lifting. That's why the typical robo-exoskeleton shown in movies allowing a random person to lift 1 ton is plainly impossible: that person would have to provide most of the required force reacting to that ton.
As I said before: designing a system where every function frees the first argument, instead of freeing it yourself, is WRONG.
Are you seriously so stupid? Because it is quite clear to me that you are a quite dishonest person whose motivations aren't properly/adequately learning/understanding; no idea about why you do what you do and honestly don't care. But, on top of that and your evident lack of knowledge, you seem particularly stupid! Apparently, my previous comment was still too complicated for you. Unfortunately, I don't have any puppets with me at the moment, but I will try a still clearer version:
1. Go back to the sample code which I wrote yesterday to try to address your "internal world".
2. In LoopNoFunction, copy the var1 set (up to the first free(var0)) 10 times. Change all the variable names such that they remain unique; you can try with var3, var4, var5, etc. Do the same with LoopFunction.
3. Now, you can redo the "experiment" in my post above and confirm that everything continues working/not if you remove/not any intermediate free.
4. What have you learned now? That you can call that function as many times as you wish without caring about freeing the variable you are using (BTW, if it was an array, the freeing process would have been more complex than just calling free). Without the function, you would have to write as many free as times you re-malloc the variable. Additionally, if you miss any of them you might provoke a serious problem. So, rather than always calling free (or a method to perform the more complex freeing actions on an array) before calling that function, you can include that free inside the function itself! What implies both a lower number of irrelevant writing and a safer approach (= you will never forget about that free).
You should bear in mind that this is just a very simple example helping you to understand what others understood immediately and without any additional help. The final goal is to always call whatever method without caring about malloc/pre-freeing malloced variables. A more descriptive example I wrote in a previous post: var1 = concatenate(var1, var1, var2); which performs the concatenation in a local variable, frees var1 (if required), mallocs it and copy that temporary variable to var1 which is returned; everything in 1 line what cannot be accomplished right away in any other way (you would have to rely on a temporary variable). What this approach does is accepting the underlying C/mallocing-freeing reality and simplifying its usage. I have been using this methodology for a while with a big number of different methods and it is extremely intuitive and error-free. Modesty apart, I came up with this approach (as more comprehensively described in other comments) within the first month of using C (for the first time in the last quite a few years; never for an important development) for a quite demanding implementation, got used to it and now (a few months later), I feel almost as comfortable with that format as with the more modern programming languages on which I usually rely: I almost make no mistakes and immediately debug the few I do. I will certainly keep further evolving/optimising it, but it already represents a quite good first version of what I intended to do: an intuitive way to easily deal with C for someone whose experience is mainly focused on managed-memory/modern programming languages. Anyway, sorry again for the lack of puppets and for having used so many words; and hopefully I will not talk to you ever again, at least, not before you evolve into a person (if you get there at all).
I see. I will try a version more adapted to your "peculiarities". Just follow the instructions below as well as you can, if you don't know how to do one of the steps, don't worry, because you tried and this is all what matters: someone, somewhere might eventually (and probably undeservedly) love you (I guess).
1. Open your C compiler/IDE (if you need help on this, go to Youtube, type C compilation and watch the first video with puppets which you can find).
2. Paste this code into the main file.
3. Call LoopNoFunction() from the start up method, compile/execute and confirm that runs without any issue.
4. Open your system memory log (CTRL+ALT+DEL on Windows or console+a program like htop on Linux), remove the first free(var0); in LoopNoFunction(), compile/run and be ready to terminate the execution as soon as possible (the memory usage will go up quite quickly!). This is why you have to release an allocated variable before reallocating it again!
5. Now test LoopFunction() and confirm that it works fine like in step 3. Why? Because that function frees the variable every time. How can it do such a thing? Because it takes as a first argument the variable to be freed/returned! Magical, don't you think!
LOOOOOOOOOOOOOOOOOOOOOOOOL.
That's false, though.
Although it seems quite safe assuming that the reality language1 vs. language1+more-things-on-top is associated with the first language being quicker, I cannot tell it for sure because I have never done a proper benchmark. So, it is extremely likely (according to basic objective common sense) that C is faster than C++ in these scenarios, but I cannot tell it for sure: I am honest person with a bit self-respect and professionalism who will never say that something is in some way for sure without having actually confirmed it. As said in other comments, I will do some serious benchmarking when possible; meanwhile, I will be happy with an application notably faster than other existing approaches. Also, feel free to back your absolute statement with something tangible.
No, I'm winding you up.
OK. Although I honestly don't fully get your behaviour as far as I already said that I was assuming that you were kidding, but you continued anyway in a not particularly funny fashion! It has been something like "You are kidding! - No, I am not! - OK, then let me explain... - Haha, I was actually kidding!". Well, if you are happy and nobody was harmed, I guess that everything is fine; but please never invite me to your comedy show :)
Why the funk is your example function freeing its first argument? And how can you come to the idea that this makes any sense?
OK. I will explain what I see wrong with your behaviour (which curiously haven't happen to any other commentator, but well...). Firstly, the answer to your question is implicit in my first post: the variable which is the first argument has the same name than the one taking the returned value which isn't declared there (= was declared before and perhaps something like a malloc happened). So, just by looking at the code, some people might know the answer, but additionally I expressly said "The first argument of all these methods (stringVariable in the sample) is the output variable" (output variable in that context seems quite evident that refers to the one being returned by the method). So, that first argument isn't exactly an argument in the conventional sense of the world, but the variable to be returned. Even despite all that, you might still have some doubts about that variable having to be freed. How to know that it was malloced before? Because I guess that you know that you have to free all the malloced variables before mallocing them again (this is precisely the reason for that first argument: reusing a variable which was malloced before). A sensible person being in that situation would ask me about that scenario and I would have answered "because all the string variables in that code are always instantiated via malloc". Even though none of the other commentators (all of them with apparently good knowledge about C/C++) had any doubt on this front, you might have missed that issue and asked me. But you didn't ask, you said "the stuff you do is just nonsense. Why the heck would your example function Concatenate_m call "free" on any of its arguments", so you aren't understanding what anyone else does and, on top of that, you don't ask, but attack?! Do you get it already? I don't think so. Do you know why? Because most of our previous 20 something iterations have been exactly like this one. I honestly don't know what is your problem (with me) and I don't care. This will be my last explanation: learn to behave (+ talk only if you know) or be ignored.
Although you seem a quite knowledgeable and sensible person, you are mostly making generic and kind-of-out-of-context references. For example, you are relying on too many generic descriptions (= out-of-context definitions) whose real value is close to zero; you call O(n) something as simple and quick as calling strlen (-> looping through the characters of a single string! One of the fastest things ever) and compare that situation with any other one which you consider that deserves the O(n) label. This is a tremendously inaccurate analysis. Just for your information and out of all the critics you have made to my heap reliance, the only relevant issue is (slight) performance differences which, as said, are partially compensated by my intention of making the whole approach consistent (+ eventually, further optimisable in the future) and string-size-/memory-availability-independent enough. On exchange of that, I get the lightest programming resources (= just pure C), a friendly(-at-least-for-me) environment and the most adaptable/improvable/extensible code which I might further improve/modify in the future, even though it is currently outperforming big names in their field (developed mostly in C++, I think).
I am afraid that this conversation has moved from actually-trying-to-understand/help to the fanatic-like (no offense intended) world, more focused on generic certainties whose reliability in general or under the given conditions is usually none. I am particularly intolerant to said behaviours because I think that they represent pretty much all what is wrong with the software development world: ideally, an objective-correctness/technical field where everything can be easily confirmed/dismissed; practically an extremely faulty sub-world where many people with limited knowledge and not precisely honesty/objectivity in their minds think that can impose whatever egoist interest via group-pressure/repetition. Again, I think that you are a quite knowledgeable person and I am not even completely dismissing some of your points (and will certainly do some tests); but unfortunately you seemed to have misinterpreted my interest about knowing more and going further with me lacking/expecting a canned-knowledge dose. I am grateful for your insights, will certainly welcome any tangible proof of any of your abstract points (I can link a public repository including a descriptive sample of the code I have been commenting if you want) and don't want to offend you, but this has been more than enough abstract talking for me.
You are strongly advised to get a teacher, the stuff you do is just nonsense. Why the heck would your example function Concatenate_m call "free" on any of its arguments?
??!! You can answer posts without caring about the signature all you want (-> this is what you said me the last time we talked), but I cannot refrain myself from remembering you. Out of all the conversations we have had (not sure, but I think that you might have written me over 20 posts), I have only read one sensible enough comment (the previous to the last one). The rest of them are so ridiculous (+ aggressive?!) that I don't even know how to answer them! Make yourself a favour and read what all the other people in this thread have written and compare them with your nonsense!! Seriously, what is wrong with you? Please, learn to behave or ignore me. I will be extremely non-patient with you and, in case of doubt, I will simply not reply you. This is the last time I clarify you nothing.
What I'm getting out of that is that you carefully constructed a string library that needs some conventions to be safe, and doesn't do complicated things because that gets buggy.
Not exactly. I started a quite demanding development by relying on a language in which I have not too much experience (even though I have lots of experience in many C-based languages). As far as I am not used to the C peculiarities, I spent a relevant amount of time at the start in coming up with a friendly framework allowing me to write code more or less as usual; so, I created quite a few string-modifying methods (because this aspect is very important in that development) similar to the ones you can find in many modern languages. Gradually, I realised about the importance of having an easy-to-use methodology to deal with C memory peculiarities, came up with a methodology and adapted those first methods to it. Despite understanding the importance of that initial part, this was logically quite secondary and that's why I didn't want to spend too much time on it (+ needed to actually test the approach to confirm/dismiss it was really allowing me to comfortably write code). In a first moment, I accounted for multiple-time-used variables, but that approach wasn't too friendly (at least, not for me); that's why I finally decided to let it as explained here: just 1-reuse per variable (anything beyond that requires a temporary variable). I have been using this methodology during the last months for that development and I am quite happy with the results. There is a public repository if you want to get a better picture about all this. In fact, I did include a link to it in one of past conversations, not sure if you visited it.
I'm not knocking your achievement
The referred methodology isn't exactly an achievement, but a side-effect of me wanting to work comfortably. My only relevant achievement here is the resulting application (because I am keeping its main code private for the time being) which is still in a very preliminary/beta stage. On the other hand, I am reading lots of people having problems with C and I am so comfortable with that methodology that I have even thought about creating an independent library to be used by anyone interested. I even asked here in a previous thread, but nobody showed any interest.
but you get most or all of that in C++ for free with simpler syntax. With C++, you get a lot of it in template format
As commented to others here and to you in the past, I am very happy with this approach and will continue doing that development in C. Out of curiousity and to confirm/dismiss what honestly aren't more than reasonable assumptions, I might do some serious benchmarking C/C++ to get better insights into their performance differences. I might also test/further optimise my approach to see whether it might be even faster. But all those are now secondary concerns for me as far as the performance so far is excellent and I am very comfortable by doing that development in plain C.
Okay, so the ownership semantics for the second argument (and later ones?) is always that of a non-owning pointer, so you must explicitly free it.
It it seriously not that difficult. You seem to be more interested in looking for problems than in properly understanding what I am explaining! Let me try it again: all the string variables in this code have been instantiated in the same way (i.e., via calling one of the multiple methods, all of them relying on the same basic malloc/free rules) and all of them are expected to be freed right after being used. You can call one of these methods with 10 arguments and it would only care about freeing/not the first one; all the remaining ones are mostly used as constants and, in any case, they will never be freed/allocated/ inside those methods. So, if you do var1 = whateverFunction_m(var1, var2, var3, var4), you would get a properly malloced var1 which has to be freed and other three variables, whose allocation happened at previous points, which will be freed after their last usage, whateverFunction_m doesn't care about any of them. In fact and as far as I am mostly relying on local variables, the "_m" flag is almost irrelevant because all the string (or array) variables declared in a given method have certainly be instantiated via malloc and certainly need to be released before existing the given method. Do I need to make the small effort to write free/call the array freeing method for each allocated variable? Yes. Would I prefer to not worry about anything of this? Yes. Is that a tremendous problem for me? No, at least not after having got used to this methodology. In case of making a mistake, it would be extremely difficult for me to locate a wrong (de)allocation bit? No, I have done it already quite a few times; every time very quickly. Do I expect everyone to like, use and enjoy that approach? No! Does it work for me? Yes. Is everything clear now?
You're still doing the malloc / copy, you're just doing it inside the function.
This is precisely what I meant, sorry for not having phrased it properly.
No, a well-optimised string library in C (such as glib strings) will be faster than wrapping a well-optimised string library in a scripting language. In contrast, you're using a set of API design choices that preclude most of the common string processing optimisations.
Not so sure about that, but as said in a previous comment I wouldn't mind to do some proper tests to confirm these issues. In any case, this development is going quite well for me so far + have lots of over-work and will look into all this at other point.
Your design, using raw C strings, prevents you from storing a length separately (so you keep needing O(n) strlen calls), prevents you from implicitly sharing large strings (so you need O(n) copies) and prevents you from deferring copying using the twine optimisation (so you need more O(n) copies). It's such a case study in bad design that Raymond Chen wrote a blog about how not to do string processing 20 years ago describing it.
Well, perhaps I should also take a look at this part too. Two comments though: I am getting the length at allocation and almost never call strlen at a later point; I prefer to sacrifice a bit on exchange of overall consistency/ease of use (a bit which might remove at a later point via over-optimisation of a properly working code).
the performance of an interpreted scripting language
As far as you keep making that pointless comparison, I will also highlight that some of the referred methods perform (logically, slightly different versions of) actions delivered by in-built C methods and that I did some preliminary comparisons where both these versions were proven to have a similar performance. I have also to do much more testing on this front, again at a later point. If that future tests prove that my versions are appreciably slower, I certainly will consider to somehow modify my approach.
Try some benchmarking with various optimization flags (people usually settle on -02 as default optimization level) and see which is better for your needs.
I am a bit saturated with work and that specific development is already way behind schedule, but your suggestion is quite reasonable. I will do a proper benchmarking at some point to confirm my preliminary assumptions.
Having multiple copies of your string pointer, possibly storing one or more of them in a struct and knowing when the free should be called.
I rely every time on the same proceeding: new malloc (indirectly via call to any of those methods). Most of my code is based on local variables and, for global ones, I had created specific populate/free methods (BTW, there are also methods to properly free arrays). As commented to others, I perfectly understand the limitations of C, even my approach; trying to do something similar just for some other developments in which I am working would be a true nightmare. But this specific implementation is quite C-peculiarities-compatible and I have kept the code as plain and simple as possible. Main main concerns are: as fast as possible (+ as less external resources usage as possible), as intuitive/me-friendly as possible and as problem-free as possible (= regularly repeating equivalent patterns, relying on local variables, etc.).
The biggest issue with your approach is that it assumes that you personally are infallible. You might be good, but you aren't that good. And the impact of screwing it up is high.
I am certainly not (just look at the numerous errors in a big proportion of my posts here. LOL) and I can make mistakes by using C or any other language. In the specific case of C and, at least for someone with my modern-language background, the main problem is memory (de)allocation and that's why I came up with this friendly-to-me methodology. I can make many errors in this code, but will certainly minimise and quickly locate/fix all the memory-related ones.
I strongly suggest looking at the talloc library
Thanks for the suggestion. I will look at it at some point. In any case, I am almost certain that will not use it in the current implementation as far as it would go against my two main concerns: minimising reliance on external resources and getting properly used to work with C.
Getting the best performance possible was one of my main concerns since the very beginning of this project, that's why I chose C (additionally, I wanted to work on this language which I haven't used much since quite long time ago). As commented to others, relying on C++ under these conditions as a way to slightly minimise the C unfriendliness doesn't make too much sense: firstly, because it will always come at a (performance) cost; and secondly because the way to get comfortable with a language isn't precisely avoiding it. I personally have no problems with the described approach and, as per all the comments so far, I don't see any compelling reason to stop using it/rely on C++
Except in your example, where one of them was a string literal (so const char * and definitely not safe to free) and the other was a heap-allocated char*.
That scenario isn't possible, as far as there is no string literal assignation. Rather than doing stringVar = "string literal", I always do stringVar = AssignStringLiteral_m(NULL, "string literal");. As said, all my code is extremely consistent and inter-compatible.
It may be simpler, but now you're doing a lot of redundant memory allocation, a lot of redundant copying, and tying all consumers of your code to the implementation of your data structure.
I am not sure if you got the idea. Rather than reusing the same variable in various calls; I rely on a temporary variables. The proposed format works fine upto 1 variable reuse. Allocation/deallocating small amounts of memory (= dealing with local variables in any language automatically dealing with memory allocation) doesn't seem an issue.
I doubt that the performance will be better than doing the same thing in a scripting language (probably worse, because most scripting languages have fairly well optimised string implementations), so you're doing manual memory management to get worse performance.
Why? All what I am doing is avoiding writing malloc, string copy, etc. every time and call methods performing those actions. Are you saying that string operations in C are slower than in a scripting language? I don't think that this is even close to being true. Just for your information, I am comparing the preliminary versions of the resulting piece of software against well-established programs (i.e., database management tools like MySQL or PostgreSQL) and it performs notably better in quite a few scenarios; although it is quite difficult to tell for sure what is the most influential aspect (algorithms/data structures or optimised usage of C), a bad language usage wouldn't allow such a situation to happen.
and yet you're willing to use O(n) algorithms and lots of malloc / free calls in places where constant-time algorithms would work with far fewer malloc / free calls and with much better cache usage?
No idea where you are getting all that from what I have written so far. The only weak point of the described approach might be relying on malloc rather than on a quicker string definition, which is also associated with a much lower available space what isn't precisely ideal under my specific conditions (should be able to deal with strings of any size). I might take a further look at all this at a later stage to further optimise its performance; for the time being, my only concern was coming up with an approach allowing me to intuitively maximise the C performance and that seemed a quite acceptable trade-off.
You don't, by any chance, work on Enlightenment do you?
I don't get that reference. If you are really asking me whether I work for a company called Enlightenment, I am not. I am a self-employed and this has been an R&D+practicing-a-bit-C project which is part of my self-promotion. I am always trying to learn/improve, help potential clients to know more about my skills, etc.
What you are saying is also true for any managed-memory language. C++ smart pointers might be an intermediate step between pure C and a language automatically managing all the memory related aspects, but they still represent a (performance) cost. Logically, I would prefer to not worry about memory (de)allocation at all, although I am using C for this development for good reasons: I want that program to be as quick as possible and all the required code is quite simple in the sense of not really needing complex programming resources.
What is the type of stringVariable? If it's char*, then how do I know when it's been stored on the heap and read back that it's dynamically allocated on the heap and so needs freeing?
It is char* and has certainly been stored on the heap because everything is instantiated via malloc. As said, one of my intentions was too create an overall consistent approach usable in any situation. I don't need to worry about different types of strings or any other thing: everything is compatible with everything else and has the same requirements like calling free afterwards.
What are the ownership semantics of the first argument to StringAction_m? Since you're assigning the result to the input variable, I presume that it's taking an owning reference and explicitly destroying it?
When you call StringAction_m, you can choose to instantiate a variable from scratch and not care about anything else by passing the first argument as NULL or else. A descriptive example to understand that second scenario is concatenation (this is precisely where I firstly though about that approach); if you want to concatenate stringVariable2 to stringVariable1, the call stringVariable1 = Concatenate_m(stringVariable1, stringVariable1, stringVariable2); performs the concatenation in a temporary variable, frees stringVar1 and copies that temporary variable to stringVar1 which is then returned.
What happens when you have types that have more complex destruction than a simple free? For example, if you're doing a lot of string processing you probably want some kind of twine abstraction so that you don't end up doing a lot of temporary copies, but now your string data type is a linked list internally and just calling free on the first element will give you a memory leak.
In one of the first versions of that approach, I accounted for more complex scenarios but everything became too buggy and problematic. So, finally I decided to rely on the shown simple structure and, for complex situations, I simply rely on (+ free) temporary variables by calling these methods as many times as required. Once you get used to the format, it is quite intuitive.
TL;DR: It's not a question of what you can do in a language, it's a question of what you can do without thinking.
I am not absolutely defending one language over other one, not here and not anywhere else. Under my specific conditions where performance is a very important aspect, C seems a better option. Again for that specific scenario (quite low-level-ish, where I am mostly relying on quite simple programming structures), the proposed approach seems quite friendly: I have came up with/got used to it relatively quickly.