Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #74622 > unrolled thread

Memory and error management approaches

Back to article view | Back to comp.lang.c

Contents

  Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:17 +0100
    Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:25 +1300
      Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:36 +0100
        Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:41 +1300
          Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 11:05 +0100
            Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:15 +0000
              Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 20:31 +0100
            Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:48 +1300
              Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:17 -0800
                Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:29 +1300
                  Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:48 -0800
              Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 22:31 +0100
                Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:02 +1300
                  Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 15:21 -0800
                Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-03 17:24 -0800
                  Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-04 14:38 +1300
                    Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-04 10:48 -0800
                      Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-04 11:28 -0800
                      Re: Memory and error management approaches James Kuyper <jameskuyper@verizon.net> - 2015-11-04 14:54 -0500
                        Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-06 07:50 +0000
                          Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-06 11:40 -0800
                            Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-07 09:38 +1300
                            Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-06 20:55 +0000
                              Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 02:23 -0800
                                Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-07 11:29 +0000
                                  Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 04:18 -0800
                                    Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 05:41 -0800
                                      Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 06:27 -0800
                                    Re: Memory and error management approaches Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-11-07 18:20 +0100
                                      Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 10:28 -0800
                                        Re: Memory and error management approaches gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-07 19:01 +0000
                                Re: Memory and error management approaches raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:14 +0000
                                Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-10 21:13 +0000
                      Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 19:26 +0000
                  Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:25 -0800
                  Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-06 10:05 +0100
      Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 02:15 -0800
        Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:01 +0000
          Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:05 -0800
            Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 17:18 +0000
              Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 09:27 -0800
                Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 23:02 +0000
                Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 12:07 +1300
                  Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 15:23 -0800
              Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 10:28 -0800
        Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:34 +1300
          Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 14:05 -0800
            Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:27 +1300
              Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:15 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#75168

Gareth Owen <gwowen@gmail.com> wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> I will argue that point - it is not "just" syntactic sugar - it's
>> extremely valuable syntactic sugar which renders inaccurate your claim
>> that it "works just as well in C as in C++". That syntactic sugar makes
>> it work a whole lot better in C++ than in C.
> 
> I completely agree.  The key to RAII is not that Resource Acquistion Is
> Initialization but its converse -- End-of-Life Is *Automatic* Resource
> Release.

If this were the key to RAII, then you wouldn't care whether acquisition
happens in constructors. You could have a dozen objects on the stack, and
initialize things whenever and where ever you wanted, scattered across
various functions and methods. The _only_ thing that would matter is that
all objects are collectable via automatic destructors.

> You can fake the former easily in C ("no lazy initialisation") - the
> converse is much much harder.  To release resources in C but you *have*
> to do it all by hand (or use a GC, if the only resource you're
> interested in is memory), which is absolutely not "works just as well in
> C" unless you have unlimited programmers, unlimited patience or
> unlimited time.

In the presence of exceptions the value of automatic destructors is
clear--they're absolutely essential to the coherency of the language. But
RAII is more than automatic destructors as a solution to exceptions. A
strict RAII discipline also tends to minimize the places where exceptions
might occur, making control flow easier to reason about. This is why the
methodology emphasizes constructors.

My point wrt C is that by following the pattern, in the majority of error or
similarly exceptional cases the only local state you need to destroy
explicitly is single object reference.

	error:
		foo_destroy(fp);
		return error;

Even if you're explicitly destroying several objects it's just as simple.
This is because most objects can follow simple hierarchical ownership rules.
And while the above is verbose, it's not even remotely complex. RAII
_minimizes_ the complexity, often times dramatically. It's not about
minimizing SLoC or boiler plate so much as it is minimizing control flow
paths and number of states.

For example, one of the biggest problems in managing errors is _testing_
error paths. But by following an RAII discipline--suitably adjusted for C,
such as permitting destructors to take NULL pointers--the overlap between
error paths and normal program flow will be much greater, because they both
rely on the same program sequence--the same destructor--to unwind state.

Precisely because C doesn't have automatic destructors the _worth_ of
following an RAII discipline can be _greater_ in C. If I give a $100 each to
a millionaire and a pauper, to whom is that $100 worth more? The pauper. In
a very meaningful sense, the payoff of RAII can be greater in C because it's
relative poor in terms of high-level constructs. The marginal benefit can be
greater.

I realize from a C++ programmer's perspective my assertion is probably a
"WTF?" moment. It's provocative. But you have to admit that, at a minimum,
even outlining the ways that RAII _doesn't_ work in C is a useful mental
exercise for improving the design of C applications.

[toc] | [prev] | [next] | [standalone]

#75181

william@wilbur.25thandClement.com wrote:
> Gareth Owen <gwowen@gmail.com> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> I will argue that point - it is not "just" syntactic sugar - it's
>>> extremely valuable syntactic sugar which renders inaccurate your claim
>>> that it "works just as well in C as in C++". That syntactic sugar makes
>>> it work a whole lot better in C++ than in C.
>>
>> I completely agree.  The key to RAII is not that Resource Acquistion Is
>> Initialization but its converse -- End-of-Life Is *Automatic* Resource
>> Release.
>
> If this were the key to RAII, then you wouldn't care whether acquisition
> happens in constructors. You could have a dozen objects on the stack, and
> initialize things whenever and where ever you wanted, scattered across
> various functions and methods. The _only_ thing that would matter is that
> all objects are collectable via automatic destructors.

What leads you to that conclusion?  At least in the context of C++, 
acquisition does not usually happen in a constructor, unless you 
consider passing the resource as a parameter to the constructor as 
acquisition?

Objects are often created as required, the key is that they are released 
in reverse order at the end of their "life".

>> You can fake the former easily in C ("no lazy initialisation") - the
>> converse is much much harder.  To release resources in C but you *have*
>> to do it all by hand (or use a GC, if the only resource you're
>> interested in is memory), which is absolutely not "works just as well in
>> C" unless you have unlimited programmers, unlimited patience or
>> unlimited time.
>
> In the presence of exceptions the value of automatic destructors is
> clear--they're absolutely essential to the coherency of the language. But
> RAII is more than automatic destructors as a solution to exceptions. A
> strict RAII discipline also tends to minimize the places where exceptions
> might occur, making control flow easier to reason about. This is why the
> methodology emphasizes constructors.

It is also key to the clean and safe use of early returns, which is 
where it would be beneficial to C if C had some form of automatic 
destructors.  RAII removes the last, all be it poor, justification for 
using goto!

> My point wrt C is that by following the pattern, in the majority of error or
> similarly exceptional cases the only local state you need to destroy
> explicitly is single object reference.
>
> 	error:
> 		foo_destroy(fp);
> 		return error;

I think that label alone disproves "works just as well in C"!

> Even if you're explicitly destroying several objects it's just as simple.
> This is because most objects can follow simple hierarchical ownership rules.
> And while the above is verbose, it's not even remotely complex. RAII
> _minimizes_ the complexity, often times dramatically. It's not about
> minimizing SLoC or boiler plate so much as it is minimizing control flow
> paths and number of states.
>
> For example, one of the biggest problems in managing errors is _testing_
> error paths. But by following an RAII discipline--suitably adjusted for C,
> such as permitting destructors to take NULL pointers--the overlap between
> error paths and normal program flow will be much greater, because they both
> rely on the same program sequence--the same destructor--to unwind state.
>
> Precisely because C doesn't have automatic destructors the _worth_ of
> following an RAII discipline can be _greater_ in C. If I give a $100 each to
> a millionaire and a pauper, to whom is that $100 worth more? The pauper. In
> a very meaningful sense, the payoff of RAII can be greater in C because it's
> relative poor in terms of high-level constructs. The marginal benefit can be
> greater.
>
> I realize from a C++ programmer's perspective my assertion is probably a
> "WTF?" moment. It's provocative. But you have to admit that, at a minimum,
> even outlining the ways that RAII _doesn't_ work in C is a useful mental
> exercise for improving the design of C applications.

I see your point above, but I don't agree that is shows RAII works just 
as well in C.  Yes it has benefits, but only as subset of the benefits 
in C++.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#75183

On Fri, 2015-11-06, <william@wilbur.25thandClement.com> wrote:
...
> In the presence of exceptions the value of automatic destructors is
> clear--they're absolutely essential to the coherency of the language. But
> RAII is more than automatic destructors as a solution to exceptions. A
> strict RAII discipline also tends to minimize the places where exceptions
> might occur, making control flow easier to reason about. This is why the
> methodology emphasizes constructors.
>
> My point wrt C is that by following the pattern, in the majority of error or
> similarly exceptional cases the only local state you need to destroy
> explicitly is single object reference.
>
> 	error:
> 		foo_destroy(fp);
> 		return error;
>
> Even if you're explicitly destroying several objects it's just as simple.
> This is because most objects can follow simple hierarchical ownership rules.
> And while the above is verbose, it's not even remotely complex. RAII
> _minimizes_ the complexity, often times dramatically. It's not about
> minimizing SLoC or boiler plate so much as it is minimizing control flow
> paths and number of states.

To me, this is clearly not RAII.  RAII is not something you apply at
ten, a hundred or a thousand places where a certain type is used: it's
something you do /once/, in the definition of the type itself.

But that's something I feel because of my C++ experience; I have never
seen a good definition of RAII (which doesn't mean there isn't one).

(I was goint to point to https://en.wikipedia.org/wiki/RAII as another
text that is confused about all that -- people who liked various
languages were eager to slap the "RAII approved!" label on them. But
the article seems to have been cleaned up in recent years: today it
only mentions C++, Ada, and some minor languages.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#75242

On Friday, November 6, 2015 at 8:55:08 PM UTC, Jorgen Grahn wrote:
>
> But that's something I feel because of my C++ experience; I have never
> seen a good definition of RAII (which doesn't mean there isn't one).
> 
It's not that it can't be defined.

Resource allocation occurs only in constructors, which are only called 
when named variables are initialised.

It's that it's desperately hard to actually keep to the idea.
You're loading a text from disk. OK, fine, you can write a constructor
that loads the file. You then want to go through each line. OK,
we can define a string called line, and initialise it with
string line = text.readline(i);

Now we want to add "by Fred" to the end of the text.
But we cant do that. We can't write a routine that allows us to
append a line to the text, because that would involve acquiring a 
resource (if only space for an extra char *), and we can only do
that in constructors that are triggered when a names object comes
into scope.
What we can do is

Text book = loadtextfile("Fred's book");
Text signedbook = book.appendline("by Fred");

But I don't think anyone actually programs like that. It gets even harder
when you want to add a list of lines in response, say, to user input.

[toc] | [prev] | [next] | [standalone]

#75247

On Sat, 2015-11-07, Malcolm McLean wrote:
> On Friday, November 6, 2015 at 8:55:08 PM UTC, Jorgen Grahn wrote:
>>
>> But that's something I feel because of my C++ experience; I have never
>> seen a good definition of RAII (which doesn't mean there isn't one).
>> 
> It's not that it can't be defined.

> Resource allocation occurs only in constructors, which are only called 
> when named variables are initialised.

If we're talking C++, that's not at all true.  As a trivial example,

   std::cout << Foo("Hello, world!\n");

Typical C++ code uses such objects a lot.

> It's that it's desperately hard to actually keep to the idea.
> You're loading a text from disk. OK, fine, you can write a constructor
> that loads the file. You then want to go through each line. OK,
> we can define a string called line, and initialise it with
> string line = text.readline(i);
>
> Now we want to add "by Fred" to the end of the text.
> But we cant do that. We can't write a routine that allows us to
> append a line to the text, because that would involve acquiring a 
> resource (if only space for an extra char *), and we can only do
> that in constructors that are triggered when a names object comes
> into scope.
> What we can do is
>
> Text book = loadtextfile("Fred's book");
> Text signedbook = book.appendline("by Fred");
>
> But I don't think anyone actually programs like that. It gets even harder
> when you want to add a list of lines in response, say, to user input.

I don't see what any of that has to do with RAII, at all.
I suspect we have different definitions ...

RAII doesn't mean that every object is immutable, if that's what where
your reasoning is going.  That's a powerful idea, but it belongs more
in the domain of functional programming.

If I attempt making my own definition without googling, it's that:

- every object has a well-defined lifetime (like in C)
- every object has a type (like in C)
- you can arrange in the definition of its type so that
  code is run when the object's lifetime ends
- thus, that you can make each object the owner of resources, which
  it will own for as long as it's alive, and which will be released
  when its (well-defined) lifetime ends.

That definition can probably be improved by bringing in the concept of
invariants, but I'm too lazy to do that.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#75249

On Saturday, November 7, 2015 at 11:29:51 AM UTC, Jorgen Grahn wrote:
> On Sat, 2015-11-07, Malcolm McLean wrote:
> > On Friday, November 6, 2015 at 8:55:08 PM UTC, Jorgen Grahn wrote:
> >>
> >> But that's something I feel because of my C++ experience; I have never
> >> seen a good definition of RAII (which doesn't mean there isn't one).
> >> 
> > It's not that it can't be defined.
> 
> > Resource allocation occurs only in constructors, which are only called 
> > when named variables are initialised.
> 
> If we're talking C++, that's not at all true.  As a trivial example,
> 
>    std::cout << Foo("Hello, world!\n");
> 
> Typical C++ code uses such objects a lot.
> 
So it's not RAII. 
And in reality it's a bit dangerous

std::cout << Foo("Verdict of court martial to be implemented") 
<< Foo("Only if authorised by HM personally")

What happens is the second call fails to allocate resources
and throws an exception? 
>
> RAII doesn't mean that every object is immutable, if that's what where
> your reasoning is going.  That's a powerful idea, but it belongs more
> in the domain of functional programming.
>
No, it means no manipulations are allowed that require resources.
For simple types, there's often a sharp distinction. For more complex
objects, effectively they're immutable apart from a few state flags
and the like. We can shorten a string but not append to it, in
reality it's easier to say strings are immutable.
>
> If I attempt making my own definition without googling, it's that:
> 
> - every object has a well-defined lifetime (like in C)
> - every object has a type (like in C)
> - you can arrange in the definition of its type so that
>   code is run when the object's lifetime ends
> - thus, that you can make each object the owner of resources, which
>   it will own for as long as it's alive, and which will be released
>   when its (well-defined) lifetime ends.
> 
> That definition can probably be improved by bringing in the concept of
> invariants, but I'm too lazy to do that.
>
That's all reasonable and saying more or less the same thing.

[toc] | [prev] | [next] | [standalone]

#75259

Malcom wrote:
So it's not RAII. 
And in reality it's a bit dangerous 

std::cout << Foo("Verdict of court martial to be implemented") 
<< Foo("Only if authorised by HM personally") 

What happens is the second call fails to allocate resources 
and throws an exception?
-----
It print the error object
if the stdout is ok print
"error object"

[toc] | [prev] | [next] | [standalone]

#75260

On Saturday, November 7, 2015 at 2:41:35 PM UTC+1, asetof...@gmail.com wrote:
> Malcom wrote:
> So it's not RAII. 
> And in reality it's a bit dangerous 
> 
> std::cout << Foo("Verdict of court martial to be implemented") 
> << Foo("Only if authorised by HM personally") 
> 
> What happens is the second call fails to allocate resources 
> and throws an exception?
> -----
> It print the error object
> if the stdout is ok print

> "error object"
I would like to have written "Malcolm "
and that exception never has to be rise 
it has only print in case of memory not sufficient:
"Print Error Object "
Because the object is not create for memory reason.

-----------
Error object is defined:
If some error occur in creation or change one object
the result is the error object
If one function or operator is applied to error object 
the result will be error object

[toc] | [prev] | [next] | [standalone]

#75271

On 07.11.15 13:18, Malcolm McLean wrote:
> On Saturday, November 7, 2015 at 11:29:51 AM UTC, Jorgen Grahn wrote:
>> On Sat, 2015-11-07, Malcolm McLean wrote:
>>> On Friday, November 6, 2015 at 8:55:08 PM UTC, Jorgen Grahn wrote:
>>>>
>>>> But that's something I feel because of my C++ experience; I have never

Can somebody point me to a C newsgroup?
I dont like or use C++.
Thank you.

[toc] | [prev] | [next] | [standalone]

#75281

On Saturday, November 7, 2015 at 5:21:27 PM UTC, Sjouke Burry wrote:
> On 07.11.15 13:18, Malcolm McLean wrote:
>  
> Can somebody point me to a C newsgroup?
> I dont like or use C++.
> 
We sometimes gossip about the neighbours here.

[toc] | [prev] | [next] | [standalone]

#75282

In article <d7ec3a46-371d-4e65-961a-3e664dcf6388@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Saturday, November 7, 2015 at 5:21:27 PM UTC, Sjouke Burry wrote:
>> On 07.11.15 13:18, Malcolm McLean wrote:
>>  
>> Can somebody point me to a C newsgroup?
>> I dont like or use C++.
>> 
>We sometimes gossip about the neighbours here.

The rule is that if a newbie (or anyone not in the clique) mentions C++,
they get slammed.

Different rules apply, of course, to clique members.

-- 
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

[toc] | [prev] | [next] | [standalone]

#75591

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Friday, November 6, 2015 at 8:55:08 PM UTC, Jorgen Grahn wrote:
> >
> > But that's something I feel because of my C++ experience; I have never
> > seen a good definition of RAII (which doesn't mean there isn't one).
> > 
> It's not that it can't be defined.
> 
> Resource allocation occurs only in constructors, which are only called 
> when named variables are initialised.
> 
> It's that it's desperately hard to actually keep to the idea.

Yes, that's generally the problem with C++: it only solves half the
problem, and then claims that the entire problem is solved and C++ has
invented the solution. (And then blames C for not inventing it in the
first place, but that's another matter.)

Magic wands have no place in programming, but C++ is all magic wands.

Richard

[toc] | [prev] | [next] | [standalone]

#75676

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> It's not that it can't be defined.
>
> Resource allocation occurs only in constructors, which are only called 
> when named variables are initialised.

Malcolm, not for the first time, you are talking absolute claptrap.

[snip claptrap-piled-upon-claptrap].

void foo(void)
{
  std::vector rvec; // no resources allocated
  for(int i = 0;i < 10;++i) rvec.push_back(rand()); // add resources 

  return;  // And ... resources automatically deallocated! RAII!
}

[toc] | [prev] | [next] | [standalone]

#75669

On Wed, 2015-11-04, <william@wilbur.25thandClement.com> wrote:
> Ian Collins <ian-news@hotmail.com> wrote:
>> william@wilbur.25thandClement.com wrote:
>>>
>>> [1] RAII as a discipline works just as well in C as in C++. Despite lacking
>>> automatic destructors, the absolute benefit might be even greater in C
>>> because memory management can be more burdensome, or at least verbose.
>> 
>> Could you expand on that statement?
>> 
>
> RAII was formalized as a method for ensuring object state consistency--or
> rather minimizing the times and places that state is inconsistent--in order
> to mitigate problems with exceptions. Because if an exception occurs when an

[long snip]

> I realize that RAII has a much more technical meaning, especially in the
> context of C++.

I think it's a mistake to make it mean anything else, like you're
trying to do above.  Despite my complaints about how I don't know a
formal definition elsewhere in the thread, "RAII" /is/ a term coined
by Stroustrup for a mechanism in C++, and possibly other languages.

You're writing about ways to deal with resources and lifetimes in C,
and that's an important topic.  But it still doesn't make it RAII.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#74794

On Wednesday, November 4, 2015 at 1:30:17 AM UTC, wil...@wilbur.25thandclement.com wrote:
>
> A few criticisms:
> 
> 1) The more sophisticated the allocator, the more complex it is. 
> Ultimately you're just substituting one general purpose allocator 
> for another. Modern system allocators already implement pools and 
> other strategies. They're not all buddy allocators.
> 
> 4) Custom allocators--for improving performance or code quality--are 
> best when targeted at specific parts of your application. E.g. using 
> a simple object stack/bump allocator for a parser, or a slab allocator 
> for object construction. In these situations, the implementation is 
> often trivial, and can provide benefits beyond what more general 
> libraries offer. By looking at third-party libraries, you're already
> conceding that your approach is not focused on your immediate problems.
> 
Two common situations are that you need lots of allocations of small fixed size, or all the allocations and deallocations can be done in reverse
order (or there are no deallocations until algorithm termination).

So you can use a simple linked list of blocks for the first, and a 
simple stack for the second. If you can establish a fairly tight upper
bound, these can resolve to only a few machine instructions. If you 
have to put emergency overflow code in, its a bit more complex, but
not so much so.

But in C it's probably not worth using a library. Just knock the code up.

[toc] | [prev] | [next] | [standalone]

#75055

On 04.11.2015 02:24, william@wilbur.25thandClement.com wrote:
> Morten W. Petersen <morphex@gmail.com> wrote:
[...]
> 4) Custom allocators--for improving performance or code quality--are best
> when targeted at specific parts of your application. E.g. using a simple
> object stack/bump allocator for a parser, or a slab allocator for object
> construction. In these situations, the implementation is often trivial, and
> can provide benefits beyond what more general libraries offer. By looking at
> third-party libraries, you're already conceding that your approach is not
> focused on your immediate problems.
>
>> I can use a memory pool, and destroy it after a longjmp and memory
>> has been handled.
>
> Sure. I use that approach quite often. I've also used longjmp for error
> handling. But I only use these techniques in particular subcomponents, where
> the cost+benefit is maximized, and the implementation doesn't leak outside
> the interface.

Well, approach 4 was what I was thinking about; it would be hard to
handle memory better than the underlying operating system in most
cases.

That said, I've seen one library that greatly improved the speed
of memory handling of older operating systems.

But the library I referenced earlier could manage memory in a simple
way, it was just one or more pools that had to be taken down on
tear-down, and then streams etc. are passed in and will be taken
care of by the caller.

I think that's a clean, smart and simple approach to it all.

-Morten

[toc] | [prev] | [next] | [standalone]

#74632

On Monday, November 2, 2015 at 9:26:06 AM UTC, Ian Collins wrote:
> Morten W. Petersen wrote:
> 
> > Any thoughts on this?  A while ago someone wrote on comp.lang.c about
> > writing a custom memory manager for performance; is that something that
> > could be coupled with all of this?
> 
> Most of the platforms I'm familiar with provide specialised memory 
> allocator libraries, you shouldn't have to roll yet another one for 
> something as simple as XML parsing.
> 
In an ideal world, that would be good advice. In the reality, it's bad advice.

An XML parser is just a medium-complexity component. But it's likely to handle
huge amounts of memory, certainly it's likely that the programmer cannot control
the size of data file he will be passed, at compile time. It's also likely to want to
split that memory up into a huge number of tiny sections.
So the case for some sort of custom scheme, rather than malloc() . free(), is strong.

But if you use someone else's non-standard scheme, then it's likely to break if
it ships as a binary library to link against, and it's likely to be very difficult to
integrate if it ships as source code, and it could well blow up the complexity
of the parser.
Rolling your own simple but not simplistic scheme is probably the best option.

   

[toc] | [prev] | [next] | [standalone]

#74636

On Mon, 2015-11-02, Malcolm McLean wrote:
> On Monday, November 2, 2015 at 9:26:06 AM UTC, Ian Collins wrote:
>> Morten W. Petersen wrote:
>> 
>> > Any thoughts on this?  A while ago someone wrote on comp.lang.c about
>> > writing a custom memory manager for performance; is that something that
>> > could be coupled with all of this?
>> 
>> Most of the platforms I'm familiar with provide specialised memory 
>> allocator libraries, you shouldn't have to roll yet another one for 
>> something as simple as XML parsing.
>> 
> In an ideal world, that would be good advice. In the reality, it's bad advice.
>
> An XML parser is just a medium-complexity component. But it's likely to handle
> huge amounts of memory, certainly it's likely that the programmer cannot control
> the size of data file he will be passed, at compile time. It's also likely to want to
> split that memory up into a huge number of tiny sections.
> So the case for some sort of custom scheme, rather than malloc() . free(), is strong.
>
> But if you use someone else's non-standard scheme, then it's likely to break if
> it ships as a binary library to link against, and it's likely to be very difficult to
> integrate if it ships as source code, and it could well blow up the complexity
> of the parser.
> Rolling your own simple but not simplistic scheme is probably the best option.

Seriously?  malloc() isn't /that/ bad, and an XML parser doesn't have
/that/ unusual requirements.  If that one needs even a third-party
allocator, for what tasks would malloc() suffice?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#74642

On Monday, November 2, 2015 at 12:01:24 PM UTC, Jorgen Grahn wrote:
> On Mon, 2015-11-02, Malcolm McLean wrote:
>
> Seriously?  malloc() isn't /that/ bad, and an XML parser doesn't have
> /that/ unusual requirements.  If that one needs even a third-party
> allocator, for what tasks would malloc() suffice?
> 
A malloc() based parser isn't a bad answer.
But, XML files can contain extremely large data sets that stress the ability of
the machine to process them in main memory, and, typically, the parser
divides the data up into tiny chunks. So a simple approach means lots of small
allocations, which is where malloc() tends to perform at its worst.

However what I was really saying was that, if you do decide to reject malloc(),
provide a little built-in custom allocator instead, rather than create a dependency
on a third party library.

I use malloc() pretty heavily for creating workspace - buffers in which to hold
intermediate images and the like. However when I am creating graphs, I tend
to start thinking of alternatives. Usually, if you solve a problem using a graph,
it's very processor intensive. If the processing invoke a lot of creation and
deletion of nodes, then malloc() will affect performance, you've also got the
problem of needing to handle failure on every call.

[toc] | [prev] | [next] | [standalone]

#74669

On Mon, 2015-11-02, Malcolm McLean wrote:
...

> I use malloc() pretty heavily for creating workspace - buffers in
> which to hold intermediate images and the like. However when I am
> creating graphs, I tend to start thinking of alternatives. Usually,
> if you solve a problem using a graph, it's very processor
> intensive. If the processing invoke a lot of creation and deletion
> of nodes, then malloc() will affect performance,

Well, I would make a serious performance measurement before
considering a different allocator.  And I would factor in the question
"how fast does an XML parser need to be, anyway?" because not
everything that /can/ be optimized /should/ be optimized.

> you've also got the problem of needing to handle failure on every
> call.

That's always a problem in C though, no matter what you replace
malloc with.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web