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

Groups > comp.lang.c++ > #19026 > unrolled thread

C/C++ question about dynamic "static struct"

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

Contents

  C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-17 06:49 -0300
    Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-17 13:08 +0200
      Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:19 -0400
      Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-17 15:19 +0000
      Re: C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-17 18:47 -0300
        Re: C/C++ question about dynamic "static struct" Ike Naar <ike@iceland.freeshell.org> - 2012-10-17 22:46 +0000
          Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:13 +0000
        Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 18:58 -0400
          Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-18 09:55 +0200
            Re: C/C++ question about dynamic "static struct" jacob navia <jacob@spamsink.net> - 2012-10-18 10:13 +0200
              Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 08:23 +0000
                Re: C/C++ question about dynamic "static struct" jacob navia <jacob@spamsink.net> - 2012-10-18 11:17 +0200
                  Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 23:37 +1300
                  Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-18 15:35 +0100
                    Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-19 11:40 -0700
              Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 21:45 +1300
              Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-18 15:03 +0100
            Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-18 07:18 -0400
              Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-18 17:43 +0200
            Re: C/C++ question about dynamic "static struct" William Ahern <william@wilbur.25thandClement.com> - 2012-10-18 13:52 -0700
              Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-19 21:34 +1300
              Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-19 11:03 +0200
                Re: C/C++ question about dynamic "static struct" "BartC" <bc@freeuk.com> - 2012-10-20 14:03 +0100
              Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:27 +0000
                Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-19 13:43 +0200
                  Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 12:46 +0000
                    Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-19 10:14 -0700
                    Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-19 14:53 -0500
                      Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-19 13:52 -0700
                        Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-19 14:13 -0700
                        Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:24 +0000
                          Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-20 11:47 +1300
                      Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:22 +0000
                Re: C/C++ question about dynamic "static struct" William Ahern <william@wilbur.25thandClement.com> - 2012-10-19 11:21 -0700
                  Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:29 +0000
                    Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 18:53 -0400
                      Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-20 12:13 +1300
                        Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-20 05:55 +0000
                          Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-20 13:24 +0200
                            Re: C/C++ question about dynamic "static struct" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 12:54 +0100
                            Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:45 -0700
                              Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:20 +1300
                              Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-20 22:28 +0200
                              Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:05 +0000
                                Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:23 -0500
                                  Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:32 +0000
                                    Re: C/C++ question about dynamic "static struct" "BartC" <bc@freeuk.com> - 2012-10-21 11:56 +0100
                                    Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 12:54 -0500
                                      Re: C/C++ question about dynamic "static struct" ptyxs <kerloch@gmail.com> - 2012-10-22 13:43 +0200
                                        Re: C/C++ question about dynamic "static struct" gwowen <gwowen@gmail.com> - 2012-10-26 03:37 -0700
                                          Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-26 07:33 -0500
                                    Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:14 -0700
                                Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:08 -0700
                          Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-20 13:44 -0500
                            Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:09 +1300
                              Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-20 22:31 +0200
                              Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:11 -0500
                                Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 20:28 +1300
                                  Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:40 +0000
                                  Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:31 -0500
                                    Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:41 +1300
                                      Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 16:24 -0500
                                        Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-21 15:05 -0700
                                        Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 07:52 +0000
                                          Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-22 14:02 -0500
                                            Re: C/C++ question about dynamic "static struct" gwowen <gwowen@gmail.com> - 2012-10-26 03:41 -0700
                                              Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-26 07:53 -0500
                                                Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-26 09:51 -0400
                                                  Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-26 13:48 -0400
                                                Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-26 07:35 -0700
                                                  Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-26 18:42 -0500
                                                    Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 04:21 -0700
                                                      Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-27 05:04 -0700
                                                      Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 08:06 -0500
                                                        Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 06:50 -0700
                                                          Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 11:13 -0500
                                                            Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 12:02 -0700
                                                              Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 15:46 -0500
                                                                Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 20:24 -0700
                                                      Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-27 20:11 +0200
                                                Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:43 -0700
                                                  Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 13:52 -0500
                                                  Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 14:40 -0500
                                        Re: C/C++ question about dynamic "static struct" google@ianshome.com - 2012-10-23 12:03 -0700
                                Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:35 -0700
                                  Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 14:24 -0500
                                Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:36 -0700
                            Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:08 +0000
                              Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:51 -0500
                                Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 21:09 +1300
                                Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 12:16 +0100
                            Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 11:55 +0100
                              Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:47 -0500
                                Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:46 +1300
                                Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 03:02 +0100
                                Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:04 +0000
                              Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-21 18:54 +0000
                                Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:49 +1300
                                  Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-21 20:07 +0000
                                    Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-21 13:53 -0700
                                    Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 09:54 +1300
                                    Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 02:41 +0100
                                      Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-22 06:12 +0000
                                      Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-22 20:52 +0000
                                        Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-22 16:30 -0700
                                          Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-23 11:22 +0200
                                            Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-23 16:58 +0000
                                Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 02:22 +0100
                            Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:30 -0700
                        Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-20 09:06 -0400
                          Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-20 07:43 -0700
                          Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:11 +0000
                            Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 11:56 +0100
                            Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-21 07:43 -0400
                              Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-21 10:36 -0700
                              Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:13 +0000
                                Re: C/C++ question about dynamic "static struct" Steve Thompson <stevet810@gmail.com> - 2012-10-22 15:08 +0000
                                Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-22 14:42 -0400
                          Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 10:12 +0100
                    Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-20 13:24 -0500
                      Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:16 +0000
                        Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:57 -0500
                          Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:17 +0000
                Re: C/C++ question about dynamic "static struct" Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-20 22:41 +0200
                  Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-21 01:04 +0200
                  Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:23 +0000
              Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-21 19:33 +0000
                Re: C/C++ question about dynamic "static struct" Greg Martin <greg@softsprocket.com> - 2012-10-21 13:20 -0700
                  Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-23 15:44 +0000
                    Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-23 20:01 +0200
                      Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-24 12:01 +0200
                        Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-24 20:31 +0200
            Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:13 -0700
              Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:25 +0000
                Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:54 -0700
            Re: C/C++ question about dynamic "static struct" Old Wolf <oldwolf@inspire.net.nz> - 2012-11-11 14:58 -0800
              Re: C/C++ question about dynamic "static struct" gof@somewhere.invalid (Adam Wysocki) - 2012-11-12 10:33 +0000
        Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 12:19 +1300
      Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:06 +0000
        Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-18 11:36 +0200
          Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:28 +0000
            Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-19 12:07 +0200
              Re: C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-19 08:03 -0300
                Re: C/C++ question about dynamic "static struct" Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-20 07:14 +0200
            Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 06:58 -0400
    Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:29 -0400
    Re: C/C++ question about dynamic "static struct" Richard Damon <news.x.richarddamon@xoxy.net> - 2012-10-17 08:35 -0400
      Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:49 -0400
      Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:10 +0000
        Re: C/C++ question about dynamic "static struct" Keith Thompson <kst-u@mib.org> - 2012-10-18 12:11 -0700
          Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:30 +0000
            Re: C/C++ question about dynamic "static struct" Keith Thompson <kst-u@mib.org> - 2012-10-19 03:05 -0700
            Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 07:37 -0400

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#19176

On 10/22/12 07:31, Les Cargill wrote:
> Ian Collins wrote:
>> On 10/21/12 20:11, Les Cargill wrote:
>>> Ian Collins wrote:
>>>>
>>>> C simply can't do RAII,
>>>
>>> Not in the specific manner Stoustrup used it, but it's
>>> perfectly easy to achieve the same goal.
>>
>> I'm sorry, but it isn't. RAII is one C++ feature that C can't do.
>>
>
> I respectfully submit that you haven't thought
> that though. I won't bore you with the sea stories...
> but it's been done...

I certainly have thought it through.  Please provide an example of RAII 
in C.

-- 
Ian Collins

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

#19183

Ian Collins wrote:
> On 10/22/12 07:31, Les Cargill wrote:
>> Ian Collins wrote:
>>> On 10/21/12 20:11, Les Cargill wrote:
>>>> Ian Collins wrote:
>>>>>
>>>>> C simply can't do RAII,
>>>>
>>>> Not in the specific manner Stoustrup used it, but it's
>>>> perfectly easy to achieve the same goal.
>>>
>>> I'm sorry, but it isn't. RAII is one C++ feature that C can't do.
>>>
>>
>> I respectfully submit that you haven't thought
>> that though. I won't bore you with the sea stories...
>> but it's been done...
>
> I certainly have thought it through.  Please provide an example of RAII
> in C.
>

So we're talking RAII as modulo exceptions - unless longjmp() is alos an 
exception...

So you *haven't* thought about it, then? It's not exactly rocket
surgery. I am just enumerating my assumptions in responding to your 
post, not *accusing* you of anything.

Essentially replace malloc()/free() with something that tracks 
allocation and provides instrumentation about the state of the heap.
This is much simpler than it sounds...

Given all the rash about it, I am surprised 'C' doesn't offer this 
natively, and that there were never commercial products of the same
stripe.

There's this:
http://www.duckware.com/bugfreec/chapter5.html

Very slanted towards some variant of Windows style, but
it should give you the general idea.


--
Les Cargill

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

#19185

On Monday, 22 October 2012 00:25:11 UTC+3, Les Cargill  wrote:
> Ian Collins wrote:
> > On 10/22/12 07:31, Les Cargill wrote:
> >> I respectfully submit that you haven't thought
> >> that though. I won't bore you with the sea stories...
> >> but it's been done...
> >
> > I certainly have thought it through.  Please provide an example of RAII
> > in C.
> >
<snip>
> There's this:
> http://www.duckware.com/bugfreec/chapter5.html

That is not RAII idiom. That is plan for safer memory manager. RAII is 
actually very simple.

RAII means that all resources allocated are always bound to objects that own 
them. Either the object frees the resource (with explicit code) during its
duration, transfers the ownership of resource (with explicit code) to some
other object with some other duration or it frees it (automatically, no code)
at end of its own duration. So no resource can leak (no memory, network socket
or file handle).

RAII works on fact that in C++ certain code (a destructor) is ran automatically
when object's duration ends. This is not case with C and so can not be
done with C.

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

#19193

In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
> Essentially replace malloc()/free() with something that tracks 
> allocation and provides instrumentation about the state of the heap.
> This is much simpler than it sounds...

You are confusing RAII with gargabe collection.

RAII is not the same thing as GC, and RAII is useful for a lot of other
things besides memory management.

Besides, what you are talking about above is *not* something that the
standard C programming language offers, so you can hardly argue that C
offers RAII.

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

#19202

Juha Nieminen wrote:
> In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
>> Essentially replace malloc()/free() with something that tracks
>> allocation and provides instrumentation about the state of the heap.
>> This is much simpler than it sounds...
>
> You are confusing RAII with gargabe collection.
>

It's not actually garbage collection, either...

> RAII is not the same thing as GC, and RAII is useful for a lot of other
> things besides memory management.
>
> Besides, what you are talking about above is *not* something that the
> standard C programming language offers, so you can hardly argue that C
> offers RAII.
>


Fair enough; I'm not sure what you were driving at then. It's fully
possible for 'C' programs to leave no widowed
resources, memory or otherwise. It's not even that difficult.

--
Les Cargill

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

#19245

On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:

> Fair enough; I'm not sure what you were driving at then. It's fully
> possible for 'C' programs to leave no widowed
> resources, memory or otherwise.

No-one has suggested otherwise.  But that's not what RAII is.  RAII is
mapping resource acquisition/release to object lifetime, and thus
using the *automatic* object construction/destruction semantics of the
language to ensure correct resource management.

C doesn't have meaningful automatic, deterministic construction/
destruction of non-trivial objects, so you can't do RAII (as it is
understood) in pure C.

> It's not even that difficult.

Well, there we'll have to differ.

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

#19250

gwowen wrote:
> On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:
>
>> Fair enough; I'm not sure what you were driving at then. It's fully
>> possible for 'C' programs to leave no widowed
>> resources, memory or otherwise.
>
> No-one has suggested otherwise.  But that's not what RAII is.  RAII is
> mapping resource acquisition/release to object lifetime, and thus
> using the *automatic* object construction/destruction semantics of the
> language to ensure correct resource management.
>

Ach! Burry McDonald is nae true Scotsman :)

I still suspect that some of that contains distinctions  without
differences. But I like the working definition you gave - "mapping
construction/deconstruction to object lifetimes." That's
clearer than what I'd seen before.

maybe I'll get the privilege of actually *learning* RAII ( through
doing a project with it ) rather than  reading about it. Otherwise,
it's like pronouncing a word you've only read...

> C doesn't have meaningful automatic, deterministic construction/
> destruction of non-trivial objects, so you can't do RAII (as it is
> understood) in pure C.
>
>> It's not even that difficult.
>
> Well, there we'll have to differ.
>

Well, you have to *cheat* :) ( Ever use "atexit()"?).

The thing I was talking about really isn't GC, and it really
isn't ( apparently ) RAII. Got the thing(s) shipped, though.

It's probably closer to mark()/release().

--
Les Cargill

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

#19253

On 10/26/2012 08:53 AM, Les Cargill wrote:
> gwowen wrote:
>> On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:
...
> I still suspect that some of that contains distinctions  without
> differences. But I like the working definition you gave - "mapping
> construction/deconstruction to object lifetimes." That's
> clearer than what I'd seen before.
...
>> C doesn't have meaningful automatic, deterministic construction/
>> destruction of non-trivial objects, so you can't do RAII (as it is
>> understood) in pure C.
>>
>>> It's not even that difficult.
>>
>> Well, there we'll have to differ.
>>
> 
> Well, you have to *cheat* :) ( Ever use "atexit()"?).

Using an exit handler to deallocate a resource corresponds to RAII only
for objects whose lifetime ends precisely at the time the exit handler
is executed. That could only be objects with automatic storage duration
that are free()d inside the exit handler. All other objects have a
lifetime that ends too soon or too late to qualify as RAII. RAII is
often used for objects with lifetimes that could end long before the end
of the entire program.
-- 
James Kuyper

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

#19261

On 10/26/2012 09:51 AM, James Kuyper wrote:
...
> ... That could only be objects with automatic storage duration

automatic => allocated

> that are free()d inside the exit handler. ...

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

#19254

On Oct 26, 8:53 am, Les Cargill <lcargil...@comcast.com> wrote:
> gwowen wrote:
> > On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:
>
> >> Fair enough; I'm not sure what you were driving at then. It's fully
> >> possible for 'C' programs to leave no widowed
> >> resources, memory or otherwise.
>
> > No-one has suggested otherwise.  But that's not what RAII is.  RAII is
> > mapping resource acquisition/release to object lifetime, and thus
> > using the *automatic* object construction/destruction semantics of the
> > language to ensure correct resource management.
>
> Ach! Burry McDonald is nae true Scotsman :)
>
> I still suspect that some of that contains distinctions  without
> differences. But I like the working definition you gave - "mapping
> construction/deconstruction to object lifetimes." That's
> clearer than what I'd seen before.
>
> maybe I'll get the privilege of actually *learning* RAII ( through
> doing a project with it ) rather than  reading about it. Otherwise,
> it's like pronouncing a word you've only read...
>
> > C doesn't have meaningful automatic, deterministic construction/
> > destruction of non-trivial objects, so you can't do RAII (as it is
> > understood) in pure C.
>
> >> It's not even that difficult.
>
> > Well, there we'll have to differ.
>
> Well, you have to *cheat* :) ( Ever use "atexit()"?).
>
> The thing I was talking about really isn't GC, and it really
> isn't ( apparently ) RAII. Got the thing(s) shipped, though.
>
> It's probably closer to mark()/release().

One option to do RAII in C in a limited sense is to reserve a buffer
of automatic storage within a function, and then direct allocations to
use that buffer.  Typically these region allocators are simple linear
bump the pointer schemes with no individual object deallocation, so
one has to tune the buffer size to the expected input.  There's
commonly a reset that "frees" all the objects at once.  You have to
take care of the alignment yourself, either manually using 'alignof
(type)' or 'ALIGN_MAX', but at the end of the function, the automatic
storage goes away and you can skip any deallocation that you would
have had to do.

It can be useful in functions that build some kind of precomputed
state that you want to optimize for smaller problems, but default back
to the standard allocator for bigger ones.  An example could be
building a partial match table for string searching using the Knuth-
Morris-Pratt algorithm, or the matrix used to compute the Levenshtein
distance.  Since automatic allocation is typically fast (bumping the
stack pointer) when compared to what happens internally using 'malloc'
and friends, it's possible to leverage automatic storage to squeeze
out a little more performance out of your allocations in these kinds
of algorithms.

Best regards,
John D.

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

#19263

ImpalerCore <jadill33@gmail.com> wrote in news:fb6dea90-99b9-4ac5-88b0-
24aafbea2e93@ez26g2000vbb.googlegroups.com:

> 
> One option to do RAII in C in a limited sense is to reserve a buffer
> of automatic storage within a function, and then direct allocations to
> use that buffer. 

This again assumes RAII is only about releasing memory. If this was the 
case, one could just add a Boehm garbage collector to the program and 
forget about all those issues. In reality, RAII in C++ is equivalently 
important for mutex unlocking, file handle closing, ending the sandclock 
mode of the mouse cursor, etc, etc. 

> Typically these region allocators are simple linear
> bump the pointer schemes with no individual object deallocation, so
> one has to tune the buffer size to the expected input.  There's
> commonly a reset that "frees" all the objects at once.  You have to
> take care of the alignment yourself, either manually using 'alignof
> (type)' or 'ALIGN_MAX', but at the end of the function, the automatic
> storage goes away and you can skip any deallocation that you would
> have had to do.

For stack allocations there is the alloca() function, and also C99 VLA-s, 
no need to reinvent the wheel. Or is this something different you are 
talking about?

A general problem with using variable amounts of stack memory is that the 
total amount of the stack space is quite small and implementation-
dependent and a stack overflow yields UB without any standard detection 
or interception means. So writing a robust program with variable-size 
stack allocations is pretty hard. 


Cheers
Paavo

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

#19264

On Oct 26, 7:42 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> ImpalerCore <jadil...@gmail.com> wrote in news:fb6dea90-99b9-4ac5-88b0-
> 24aafbea2...@ez26g2000vbb.googlegroups.com:
>
>
>
> > One option to do RAII in C in a limited sense is to reserve a buffer
> > of automatic storage within a function, and then direct allocations to
> > use that buffer.
>
> This again assumes RAII is only about releasing memory. If this was the
> case, one could just add a Boehm garbage collector to the program and
> forget about all those issues. In reality, RAII in C++ is equivalently
> important for mutex unlocking, file handle closing, ending the sandclock
> mode of the mouse cursor, etc, etc.

Originally RAII was designed to handle memory cleanup in the presence
of exceptions, as it's pretty much a necessity to write exception safe
code in C++.  I would say that when people saw how good RAII was in
memory cleanup that it was applied to other resource cleanup as well.
Hence the phrase "limited sense", as C does not provide language
support of anything resembling destructors.

> > Typically these region allocators are simple linear
> > bump the pointer schemes with no individual object deallocation, so
> > one has to tune the buffer size to the expected input.  There's
> > commonly a reset that "frees" all the objects at once.  You have to
> > take care of the alignment yourself, either manually using 'alignof
> > (type)' or 'ALIGN_MAX', but at the end of the function, the automatic
> > storage goes away and you can skip any deallocation that you would
> > have had to do.
>
> For stack allocations there is the alloca() function, and also C99 VLA-s,
> no need to reinvent the wheel. Or is this something different you are
> talking about?
>
> A general problem with using variable amounts of stack memory is that the
> total amount of the stack space is quite small and implementation-
> dependent and a stack overflow yields UB without any standard detection
> or interception means. So writing a robust program with variable-size
> stack allocations is pretty hard.

The difference is that this mechanism is a "fixed" stack allocation.
One issue is that alloca is not standard, and C99 VLAs do not apply to
C90 environments, which limit the scope of environments they can be
applied.  While the 'region' technique has the same recursion issues
that alloca and C99 VLAs have, the stack size reserved to an algorithm
that needs to allocate memory is fixed.  That means that passing big
input doesn't result in a big alloca or VLA resize that blows up the
stack.

Here's an excerpt from my region allocator.

\code
struct c_region
{
  /*! \brief The start of the memory buffer. */
  unsigned char* start;

  /*! \brief The end of the memory buffer. */
  unsigned char* end;

  /*! \brief The next available address to allocate from in the
region. */
  unsigned char* current;
};

void c_region_initialize( struct c_region* region, void* buffer,
size_t size )
{
  c_return_if_fail( region != NULL );
  c_return_if_fail( buffer != NULL );

  region->start = buffer;
  region->end = (unsigned char*)buffer + size;
  region->current = buffer;

  C_REGION_INVARIANT( region );
}

void* c_region_allocate( struct c_region* region,
                         size_t size,
                         size_t alignment )
{
  unsigned char* aligned_p;

  c_return_value_if_fail( region != NULL, NULL );
  C_REGION_INVARIANT( region );

  size = size == 0 ? 1 : size;
  alignment = alignment == 0 ?
                ALIGN_MAX :
                c_round_up_to_power_of_two( alignment );
  c_assert( c_is_power_of_two( alignment ) );

  aligned_p = c_align_up( region->current, alignment );
  c_assert( c_is_aligned_ptr( aligned_p, alignment ) );

  /* To determine whether the region has enough space, one must
     factor in the alignment padding as well as the object size. */
  if ( aligned_p + size > region->end ) {
    return NULL;
  }

  region->current = aligned_p + size;

  C_REGION_INVARIANT( region );

  return aligned_p;
}
\endcode

\code
int c_levenshtein( const char* s1, const char* s2 )
{
  int distance;

  int m, n;
  int* proximity_matrix;
  struct c_region pm_region;
  unsigned char pm_workspace[256];
  bool c_malloc_used = false;

  c_return_value_if_fail( s1 != NULL, -1 );
  c_return_value_if_fail( s2 != NULL, -1 );

  m = strlen( s1 );
  n = strlen( s2 );

  /* If one of the strings is empty "", the edit distance is equal
     to the length of the non-empty string. */
  if ( m == 0 || n == 0 ) {
    return m + n;
  }

  c_region_initialize( &pm_region, pm_workspace, sizeof
pm_workspace );
  proximity_matrix = c_region_allocate( &pm_region,
                                        sizeof (int) * (m+1) * (n+1),
                                        alignof (int) );
  if ( proximity_matrix == NULL )
  {
    proximity_matrix = c_malloc( sizeof (int) * (m+1) * (n+1) );
    c_malloc_used = true;
  }

  if ( proximity_matrix )
  {
    ++m;
    ++n;

    gc_compute_levenshtein_matrix( s1, s2, &m, &n, proximity_matrix );
    distance = proximity_matrix[m*n-1];

    if ( c_malloc_used ) {
      c_free( proximity_matrix );
    }
  }
  else {
    distance = -1;
  }

  return distance;
}
\endcode

The key point to take away from this example is that the size of the
stack used is independent of the size of s1 and s2.  While alloca and
VLAs are convenient, they lend themself to a programming style where
it's easy to blow the stack in the presence of a big string.  In my
case, I structure the stack allocation so that if it exceeds the
maximum amount I reserved for it (the size of pm_workspace), I return
*NULL*.  Adjusting the amount of stack space reserved for
'c_levenshtein' is done by changing the size of 'pm_workspace',
eliminating any manual code to delineate allocations between an alloca
or VLA and malloc; the logic is built into the c_region interface.

One can also leverage a static buffer in the same manner, although one
needs to manually reset the c_region after finished with the workspace
memory.

I hope that adequately explains the benefit of going to the trouble of
using a region allocator.

Best regards,
John D.

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

#19265

On Saturday, 27 October 2012 14:21:17 UTC+3, ImpalerCore  wrote:
> On Oct 26, 7:42 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> > This again assumes RAII is only about releasing memory. If this was the
> > case, one could just add a Boehm garbage collector to the program and
> > forget about all those issues. In reality, RAII in C++ is equivalently
> > important for mutex unlocking, file handle closing, ending the sandclock
> > mode of the mouse cursor, etc, etc.
> 
> Originally RAII was designed to handle memory cleanup in the presence
> of exceptions, as it's pretty much a necessity to write exception safe
> code in C++.  I would say that when people saw how good RAII was in
> memory cleanup that it was applied to other resource cleanup as well.
> Hence the phrase "limited sense", as C does not provide language
> support of anything resembling destructors.

RAII idiom was invented by Bjarne Stroustrup. It means "Resource
Acquisition Is Initialisation". He personally named it so originally.
The name is complex to crasp. You should not think that he however
originally meant "Memory Acquisition Is Initialization". Looking his 
faq it seems that he knows very well what "resource" is:
http://www.stroustrup.com/glossary.html#Gresource

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

#19273

ImpalerCore <jadill33@gmail.com> wrote in
news:3e400603-4923-4655-b4b2-d870dbed1f65@o30g2000vbu.googlegroups.com: 

> On Oct 26, 7:42 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> ImpalerCore <jadil...@gmail.com> wrote in
>> news:fb6dea90-99b9-4ac5-88b0- 
>> 24aafbea2...@ez26g2000vbb.googlegroups.com: 
>>
>>
>>
>> > One option to do RAII in C in a limited sense is to reserve a
>> > buffer of automatic storage within a function, and then direct
>> > allocations to use that buffer.
>>
>> This again assumes RAII is only about releasing memory. If this was
>> the case, one could just add a Boehm garbage collector to the program
>> and forget about all those issues. In reality, RAII in C++ is
>> equivalently important for mutex unlocking, file handle closing,
>> ending the sandclock mode of the mouse cursor, etc, etc.
> 
> Originally RAII was designed to handle memory cleanup in the presence
> of exceptions, as it's pretty much a necessity to write exception safe
> code in C++.  

Just curious, do you have any links to support this? Exception safe code 
needs to clean up all resources anyway, not only memory. My google-fu 
only produced wordings containing the general term "resources", including 
Stroustrup himself (http://www.velocityreviews.com/forums/t688168-who-
invented-deterministic-construction-destruction.html). 


> I would say that when people saw how good RAII was in
> memory cleanup that it was applied to other resource cleanup as well.
> Hence the phrase "limited sense", as C does not provide language
> support of anything resembling destructors.

BTW, I just noticed a gcc extension doing something almost exactly like 
this (a "cleanup" attribute): 
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#GCC_e
xtensions_for_C

>>
>> For stack allocations there is the alloca() function, and also C99
>> VLA-s, no need to reinvent the wheel. Or is this something different
>> you are talking about?
>>
>> A general problem with using variable amounts of stack memory is that
>> the total amount of the stack space is quite small and
>> implementation- dependent and a stack overflow yields UB without any
>> standard detection or interception means. So writing a robust program
>> with variable-size stack allocations is pretty hard.
> 
> The difference is that this mechanism is a "fixed" stack allocation.
> One issue is that alloca is not standard, and C99 VLAs do not apply to
> C90 environments, which limit the scope of environments they can be
> applied.  While the 'region' technique has the same recursion issues
> that alloca and C99 VLAs have, the stack size reserved to an algorithm
> that needs to allocate memory is fixed.  That means that passing big
> input doesn't result in a big alloca or VLA resize that blows up the
> stack.

[snipped lengthy example code of fixed-pool-size stack allocator scheme]

> The key point to take away from this example is that the size of the
> stack used is independent of the size of s1 and s2.  While alloca and
> VLAs are convenient, they lend themself to a programming style where
> it's easy to blow the stack in the presence of a big string.  

OK, I can see now how this scheme can be indeed useful for more reliable 
stack-based allocations. In this sense it reminds me the short string 
optimization techniques used by some C++ implementations. There, if the 
string is shorter than a given threshold, it is stored directly inside 
the string object (which is often a local variable on stack). Only larger 
strings require a dynamic memory allocation. This mechanism is fully 
encapsulated of course, as is customary in C++, so that the class users 
do not have to know or care about such implementation details.

Regards
Paavo

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

#19274

On Oct 27, 9:06 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> ImpalerCore <jadil...@gmail.com> wrote innews:3e400603-4923-4655-b4b2-d870dbed1f65@o30g2000vbu.googlegroups.com:
> > On Oct 26, 7:42 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >> ImpalerCore <jadil...@gmail.com> wrote in
> >> news:fb6dea90-99b9-4ac5-88b0-
> >> 24aafbea2...@ez26g2000vbb.googlegroups.com:
>
> >> > One option to do RAII in C in a limited sense is to reserve a
> >> > buffer of automatic storage within a function, and then direct
> >> > allocations to use that buffer.
>
> >> This again assumes RAII is only about releasing memory. If this was
> >> the case, one could just add a Boehm garbage collector to the program
> >> and forget about all those issues. In reality, RAII in C++ is
> >> equivalently important for mutex unlocking, file handle closing,
> >> ending the sandclock mode of the mouse cursor, etc, etc.
>
> > Originally RAII was designed to handle memory cleanup in the presence
> > of exceptions, as it's pretty much a necessity to write exception safe
> > code in C++.
>
> Just curious, do you have any links to support this? Exception safe code
> needs to clean up all resources anyway, not only memory. My google-fu
> only produced wordings containing the general term "resources", including
> Stroustrup himself (http://www.velocityreviews.com/forums/t688168-who-
> invented-deterministic-construction-destruction.html).

No, just my personal exposure to it in the context of my old C++
college courses, which was explained for the purpose of deallocating
memory.  I'm sure Bjarne designed it for files and other more exotic
constructs.

> > I would say that when people saw how good RAII was in
> > memory cleanup that it was applied to other resource cleanup as well.
> > Hence the phrase "limited sense", as C does not provide language
> > support of anything resembling destructors.
>
> BTW, I just noticed a gcc extension doing something almost exactly like
> this (a "cleanup" attribute):http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#G...
> xtensions_for_C

Sure, if you restrict your code to a compiler toolchain that supports
that extension.  I have a habit of avoiding 'gcc-isms' or other
compiler-isms for library development when I can.

> >> For stack allocations there is the alloca() function, and also C99
> >> VLA-s, no need to reinvent the wheel. Or is this something different
> >> you are talking about?
>
> >> A general problem with using variable amounts of stack memory is that
> >> the total amount of the stack space is quite small and
> >> implementation- dependent and a stack overflow yields UB without any
> >> standard detection or interception means. So writing a robust program
> >> with variable-size stack allocations is pretty hard.
>
> > The difference is that this mechanism is a "fixed" stack allocation.
> > One issue is that alloca is not standard, and C99 VLAs do not apply to
> > C90 environments, which limit the scope of environments they can be
> > applied.  While the 'region' technique has the same recursion issues
> > that alloca and C99 VLAs have, the stack size reserved to an algorithm
> > that needs to allocate memory is fixed.  That means that passing big
> > input doesn't result in a big alloca or VLA resize that blows up the
> > stack.
>
> [snipped lengthy example code of fixed-pool-size stack allocator scheme]
>
> > The key point to take away from this example is that the size of the
> > stack used is independent of the size of s1 and s2.  While alloca and
> > VLAs are convenient, they lend themself to a programming style where
> > it's easy to blow the stack in the presence of a big string.
>
> OK, I can see now how this scheme can be indeed useful for more reliable
> stack-based allocations. In this sense it reminds me the short string
> optimization techniques used by some C++ implementations. There, if the
> string is shorter than a given threshold, it is stored directly inside
> the string object (which is often a local variable on stack). Only larger
> strings require a dynamic memory allocation. This mechanism is fully
> encapsulated of course, as is customary in C++, so that the class users
> do not have to know or care about such implementation details.

Agreed, but I also think the "RAII for memory" is also encapsulated in
'c_levenshtein', unless I misunderstand what you're saying by
"encapsulation".  By that I mean that the c_levenshtein just takes two
strings; there's no c_region being passed as a parameter and the user
can call it whether 'c_levenshtein' used the region or just plain
malloc.

Best regards,
John D.

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

#19275

ImpalerCore <jadill33@gmail.com> wrote in
news:906d2617-80f6-408e-bcf2-2adc990a0e63@p22g2000vby.googlegroups.com: 

> Agreed, but I also think the "RAII for memory" is also encapsulated in
> 'c_levenshtein', unless I misunderstand what you're saying by
> "encapsulation".  By that I mean that the c_levenshtein just takes two
> strings; 

That's true, but the usability of this encapsulation is on a different 
level. To illustrate this, I have never needed to call c_levenshtein() (or 
something equivalent) in my code, but I am making use of std::string every 
day (as well as my home-grown variant class which is also using small-
string optimization).

Encapsulation means I can build my own abstractions, and then build other 
stuff on top of them, ad infinitum. Using abstractions means the upper 
level code is not concerned with lower-level details. In contrast, your 
c_levenshtein() function is containing lower-level code (like setting up 
pm_workspace) which has absolutely nothing to do with the actual purpose of 
this function. I understand this is kind of inevitable in C.

Best regards
Paavo

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

#19281

On Oct 27, 12:13 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> ImpalerCore <jadil...@gmail.com> wrote innews:906d2617-80f6-408e-bcf2-2adc990a0e63@p22g2000vby.googlegroups.com:
>
> > Agreed, but I also think the "RAII for memory" is also encapsulated in
> > 'c_levenshtein', unless I misunderstand what you're saying by
> > "encapsulation".  By that I mean that the c_levenshtein just takes two
> > strings;
>
> That's true, but the usability of this encapsulation is on a different
> level.

Okay, can you enumerate what "levels of encapsulation" you associate
std::string and c_levenshtein?  Are you saying 'class' is a higher
level of encapsulation than 'function'?

> To illustrate this, I have never needed to call c_levenshtein() (or
> something equivalent) in my code

Until you have the need to implement some kind of fuzzy string
matching, which when used to match user input against some kind of
dictionary, implies the potential for a lot of comparisons.

>, but I am making use of std::string every
> day (as well as my home-grown variant class which is also using small-
> string optimization).

Are you trying to point out that 'std::string (high) > char* (low)'?

> Encapsulation means I can build my own abstractions, and then build other
> stuff on top of them, ad infinitum. Using abstractions means the upper
> level code is not concerned with lower-level details. In contrast, your
> c_levenshtein() function is containing lower-level code (like setting up
> pm_workspace) which has absolutely nothing to do with the actual purpose of
> this function. I understand this is kind of inevitable in C.

I'm a bit confused.  Evaluating the levenshtein distance in the
classical method requires a matrix that you have to get memory for
from somewhere.  Even if you have 'int c_levenshtein( const string&
s1, const string& s2 )' or some levenshtein member function, you still
have to provide memory for the matrix; it's not innate to 's1' and
's2'.  I agree that 'pm_workspace' is a kind of small string
optimization for malloc that is not directly related to the algorithm,
but you still need to get the memory from somewhere.  Can you
pseudocode your own version of levenshtein using the std::string
framework, so I can better understand where you're getting the memory
for the matrix from, and classify what parts of the function are
"high" and "low" level?

If you're basically saying C++ > C for encapsulation, I agree with
you.  However, one can still build a C interface to a resizing string
to have a kind of std::string equivalent in functionality, but the
code won't look as pretty, especially to someone accustomed to class
based design.  But that doesn't mean that it can't be done, and that
it wouldn't be useful for someone using C.

Best regards,
John D.

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

#19286

ImpalerCore <jadill33@gmail.com> wrote in
news:fd1e7b35-3d5d-40b4-91b5-92e6b1b66fc2@d17g2000vbv.googlegroups.com: 

> On Oct 27, 12:13 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> ImpalerCore <jadil...@gmail.com> wrote
>> innews:906d2617-80f6-408e-bcf2-2ad 
> c990a0e63@p22g2000vby.googlegroups.com:
>>
>> > Agreed, but I also think the "RAII for memory" is also encapsulated
>> > in 'c_levenshtein', unless I misunderstand what you're saying by
>> > "encapsulation".  By that I mean that the c_levenshtein just takes
>> > tw 
> o
>> > strings;
>>
>> That's true, but the usability of this encapsulation is on a
>> different level.
> 
> Okay, can you enumerate what "levels of encapsulation" you associate
> std::string and c_levenshtein?  Are you saying 'class' is a higher
> level of encapsulation than 'function'?

No, I talked about the level of "usability". I just wanted to say that 
the frequency of anyone using c_levenshtein is several magnitudes less 
than anyone using std::string (in C++), just because the c_levenshtein is 
a much more specialized thing. So, if I introduce some optimization like 
small string optimization in std::string, it has several magnitudes more 
impact than introducing it in c_levenshtein (and introducing it in all 
functions similar to c_levenshtein is a lot of work which can be avoided 
by introducing it in std::string instead).

>>, but I am making use of std::string every
>> day (as well as my home-grown variant class which is also using
>> small- string optimization).
> 
> Are you trying to point out that 'std::string (high) > char* (low)'?

Yes, std::string is inevitably using char* so it is higher level. But on 
the other hand, in C++ std::string would be itself pretty much lowest 
level and anything using it would be yet higher level. The fact that the 
C version of c_levenshtein is containing char[] is dragging it to the 
same lower level where std::string resides, where it does not actually 
belong.

> 
>> Encapsulation means I can build my own abstractions, and then build
>> other stuff on top of them, ad infinitum. Using abstractions means
>> the upper level code is not concerned with lower-level details. In
>> contrast, your c_levenshtein() function is containing lower-level
>> code (like setting up pm_workspace) which has absolutely nothing to
>> do with the actual purpose 
> of
>> this function. I understand this is kind of inevitable in C.
> 
> I'm a bit confused.  Evaluating the levenshtein distance in the
> classical method requires a matrix that you have to get memory for
> from somewhere.  Even if you have 'int c_levenshtein( const string&
> s1, const string& s2 )' or some levenshtein member function, you still
> have to provide memory for the matrix; it's not innate to 's1' and
> 's2'.  I agree that 'pm_workspace' is a kind of small string
> optimization for malloc that is not directly related to the algorithm,
> but you still need to get the memory from somewhere.  Can you
> pseudocode your own version of levenshtein using the std::string
> framework, so I can better understand where you're getting the memory
> for the matrix from, and classify what parts of the function are
> "high" and "low" level?

There are no two levels "high" and "low", there is a potentially open-
ended hiearchy of levels. I am very oriented to the actual working code, 
so for me the notions "lower" and "higher" just mean the order of loading 
dynamic-link-libraries into the process space, assuming that each feature 
is implemented in its own dynamic-link library.

And I said the technique just reminded me the short-string optimization 
of C++, not that it would be applicable for this very function. Anyway, 
here is the translation of the levenshtein function into C++:

\code
int c_levenshtein( const std::string& s1, const std:string& s2 )
{
  // note: try-catch is probably unneeded here, it is just to replicate
  // the original function way to report any errors 
  // by returning a non-informative -1 error code.
  try {
    /* If one of the strings is empty "", the edit distance is equal
       to the length of the non-empty string. */
    if (s1.empty() || s2.empty()) {
      return s1.length() + s2.length();
    }
    int m = s1.length()+1;
    int n = s2.length()+1;
    std::vector<int> proximity_matrix(n*m);
    gc_compute_levenshtein_matrix( 
      s1.c_str(), s2.c_str(), &m, &n, &proximity_matrix[0] );
    return proximity_matrix[m*n-1];
  } catch(...) {
    return -1;
  }
}
\endcode

The intermediate array is using std::vector here instead of std::string, 
and I have not heard any implementation of std::vector that is using any 
kind of "small-string" optimization. So this C++ version probably 
involves a dynamic memory allocation even in case of short input strings 
and so probably runs slower than the C version in case of short input 
strings. Getting it faster would involve more work, and I would not be 
convinced this is needed unless the profiler told me that. On the other 
hand, if more work were needed, I could encapsulate it in a class and 
just replace the name std::vector with my class name.

> If you're basically saying C++ > C for encapsulation, I agree with
> you.  

Yeah, I guess this is mostly what I wanted to say.

>. However, one can still build a C interface to a resizing string
> to have a kind of std::string equivalent in functionality, but the
> code won't look as pretty, especially to someone accustomed to class
> based design.  But that doesn't mean that it can't be done, and that
> it wouldn't be useful for someone using C.

Sure, C is Turing complete so one can do anything in it. It just takes 
more care and discipline.

Best regards
Paavo

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

#19305

On Oct 27, 4:46 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> ImpalerCore <jadil...@gmail.com> wrote innews:fd1e7b35-3d5d-40b4-91b5-92e6b1b66fc2@d17g2000vbv.googlegroups.com:
> > On Oct 27, 12:13 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >> ImpalerCore <jadil...@gmail.com> wrote
> >> innews:906d2617-80f6-408e-bcf2-2ad
> > c990a0...@p22g2000vby.googlegroups.com:
>
> >> > Agreed, but I also think the "RAII for memory" is also encapsulated
> >> > in 'c_levenshtein', unless I misunderstand what you're saying by
> >> > "encapsulation".  By that I mean that the c_levenshtein just takes
> >> > tw
> > o
> >> > strings;
>
> >> That's true, but the usability of this encapsulation is on a
> >> different level.
>
> > Okay, can you enumerate what "levels of encapsulation" you associate
> > std::string and c_levenshtein?  Are you saying 'class' is a higher
> > level of encapsulation than 'function'?
>
> No, I talked about the level of "usability". I just wanted to say that
> the frequency of anyone using c_levenshtein is several magnitudes less
> than anyone using std::string (in C++), just because the c_levenshtein is
> a much more specialized thing. So, if I introduce some optimization like
> small string optimization in std::string, it has several magnitudes more
> impact than introducing it in c_levenshtein (and introducing it in all
> functions similar to c_levenshtein is a lot of work which can be avoided
> by introducing it in std::string instead).

Okay, I understand your point now.  But it's a little difficult on the
comp.lang.c side of the cross post to get access to std::string :-)

> >>, but I am making use of std::string every
> >> day (as well as my home-grown variant class which is also using
> >> small- string optimization).
>
> > Are you trying to point out that 'std::string (high) > char* (low)'?
>
> Yes, std::string is inevitably using char* so it is higher level. But on
> the other hand, in C++ std::string would be itself pretty much lowest
> level and anything using it would be yet higher level. The fact that the
> C version of c_levenshtein is containing char[] is dragging it to the
> same lower level where std::string resides, where it does not actually
> belong.

If I understand you correctly, in C++ land, you are claiming that
algorithms like the levenshtein should be parameterized to work on
std::string.  I'd agree with that statement.

But on the comp.lang.c side of things, you have char*, or you have
some to build some kind of struct string with an API to manipulate it.

> >> Encapsulation means I can build my own abstractions, and then build
> >> other stuff on top of them, ad infinitum. Using abstractions means
> >> the upper level code is not concerned with lower-level details. In
> >> contrast, your c_levenshtein() function is containing lower-level
> >> code (like setting up pm_workspace) which has absolutely nothing to
> >> do with the actual purpose
> > of
> >> this function. I understand this is kind of inevitable in C.
>
> > I'm a bit confused.  Evaluating the levenshtein distance in the
> > classical method requires a matrix that you have to get memory for
> > from somewhere.  Even if you have 'int c_levenshtein( const string&
> > s1, const string& s2 )' or some levenshtein member function, you still
> > have to provide memory for the matrix; it's not innate to 's1' and
> > 's2'.  I agree that 'pm_workspace' is a kind of small string
> > optimization for malloc that is not directly related to the algorithm,
> > but you still need to get the memory from somewhere.  Can you
> > pseudocode your own version of levenshtein using the std::string
> > framework, so I can better understand where you're getting the memory
> > for the matrix from, and classify what parts of the function are
> > "high" and "low" level?
>
> There are no two levels "high" and "low", there is a potentially open-
> ended hiearchy of levels. I am very oriented to the actual working code,
> so for me the notions "lower" and "higher" just mean the order of loading
> dynamic-link-libraries into the process space, assuming that each feature
> is implemented in its own dynamic-link library.
>
> And I said the technique just reminded me the short-string optimization
> of C++, not that it would be applicable for this very function. Anyway,
> here is the translation of the levenshtein function into C++:
>
> \code
> int c_levenshtein( const std::string& s1, const std:string& s2 )
> {
>   // note: try-catch is probably unneeded here, it is just to replicate
>   // the original function way to report any errors
>   // by returning a non-informative -1 error code.
>   try {
>     /* If one of the strings is empty "", the edit distance is equal
>        to the length of the non-empty string. */
>     if (s1.empty() || s2.empty()) {
>       return s1.length() + s2.length();
>     }
>     int m = s1.length()+1;
>     int n = s2.length()+1;
>     std::vector<int> proximity_matrix(n*m);
>     gc_compute_levenshtein_matrix(
>       s1.c_str(), s2.c_str(), &m, &n, &proximity_matrix[0] );
>     return proximity_matrix[m*n-1];
>   } catch(...) {
>     return -1;
>   }}
>
> \endcode
>
> The intermediate array is using std::vector here instead of std::string,
> and I have not heard any implementation of std::vector that is using any
> kind of "small-string" optimization. So this C++ version probably
> involves a dynamic memory allocation even in case of short input strings
> and so probably runs slower than the C version in case of short input
> strings.
>
> Getting it faster would involve more work, and I would not be
> convinced this is needed unless the profiler told me that. On the other
> hand, if more work were needed, I could encapsulate it in a class and
> just replace the name std::vector with my class name.

Just from my limited measurements for levenshtein, replacing c_malloc
with c_region for string pairs whose matrix fits into the buffer
reduces the execution time by about 15% on my system.  A little faster
but not really enough to jump up and down about, since levenshtein has
such a limited scope.  I actually just use malloc in my levenshtein
function in my library, since for my application, it's fast enough.

> > If you're basically saying C++ > C for encapsulation, I agree with
> > you.
>
> Yeah, I guess this is mostly what I wanted to say.
>
> >. However, one can still build a C interface to a resizing string
> > to have a kind of std::string equivalent in functionality, but the
> > code won't look as pretty, especially to someone accustomed to class
> > based design.  But that doesn't mean that it can't be done, and that
> > it wouldn't be useful for someone using C.
>
> Sure, C is Turing complete so one can do anything in it. It just takes
> more care and discipline.

Thanks for taking the time to give your perspective.

Best regards,
John D.

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

#19278

Op 27-Oct-12 13:21, ImpalerCore schreef:
> On Oct 26, 7:42 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> ImpalerCore <jadil...@gmail.com> wrote in news:fb6dea90-99b9-4ac5-88b0-
>> 24aafbea2...@ez26g2000vbb.googlegroups.com:
>>
>>> One option to do RAII in C in a limited sense is to reserve a buffer
>>> of automatic storage within a function, and then direct allocations to
>>> use that buffer.
>>
>> This again assumes RAII is only about releasing memory. If this was the
>> case, one could just add a Boehm garbage collector to the program and
>> forget about all those issues. In reality, RAII in C++ is equivalently
>> important for mutex unlocking, file handle closing, ending the sandclock
>> mode of the mouse cursor, etc, etc.
>
> Originally RAII was designed to handle memory cleanup in the presence
> of exceptions, as it's pretty much a necessity to write exception safe
> code in C++.

RAII was already supported (and useful) before C++ supported exceptions. 
Exceptions made RAII in C++ more or less a necessity. There is nothing 
about RAII that makes it specific for releasing memory.

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

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

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

csiph-web