Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C/C++ question about dynamic "static struct"

Reply
Thread Tools

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

 
 
Les Cargill
Guest
Posts: n/a
 
      10-27-2012
Nick Keighley wrote:
> On Oct 26, 1:53 pm, Les Cargill <(E-Mail Removed)> wrote:
>> gwowen wrote:
>>> On Oct 22, 8:02 pm, Les Cargill <(E-Mail Removed)> 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.

>
> do you assume memory is allocated in a stack-like manner? Because that
> simply wouldn't work on the systems I'm thinking about. Mobile radio
> calls don't appear and disappear in a stack-like manner.
>


No, I don't assume that. Dynamic circuit creation/deletion usually
means you have state per circuit. It's possible to have a "global"
list of this state with instrumentation against that list
to track whether or not widowed circuits exist.

RAII would also solve this in a less "global" manner.

>>> 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()"?).

>
> way too late in most of the programs I've encountered. These systems
> are supposed to run "forever". Cleaning up all the crap on exit is no
> good in a program that isn't supposed to exit!
>


I am using "atexit()" metaphorically. There exist frames of context,
and at the bottom of each frame ( when the frame goes away ), it
cleans up all the things it allocated.

This is still not "stack" stuff, because it's not LIFO.

>> 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
 
Reply With Quote
 
 
 
 
ImpalerCore
Guest
Posts: n/a
 
      10-27-2012
On Oct 27, 12:13*pm, Paavo Helde <(E-Mail Removed)> wrote:
> ImpalerCore <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>
> > 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.
 
Reply With Quote
 
 
 
 
Les Cargill
Guest
Posts: n/a
 
      10-27-2012
Nick Keighley wrote:
> On Oct 21, 8:11 am, Les Cargill <(E-Mail Removed)> wrote:
>> Ian Collins wrote:

<snip>
>>
>> 'Course, I'm the sort who would use a state machine to manage an
>> overly onerous memory allocation problem - and in C++ - so...

>
> in the systems I've used there all sorts of things that are
> dynamically allocated- there are "events" (internal messages), TCP/IP
> packets, timers and all sorts of application specific thingies (calls,
> targets, alarms, equipment allocations, maps etc. etc.). I hard to see
> how you can avoid dynamically allocating things except in the most
> hard real time systems.
>


TCP/IP is inherently dynamic, but it's a well trod service.

The rest? You simply have an "auction" with yourself - "I will
allow no more than 50 simultaneous events, 20 targets, 100
mappings", then you get the worst-case numbers and test it.
This includes developing ... generators that prove
all the constraints and will make you a script which you
can use to convince yourself you've exhaustively tested it.

State machines seem to be relegated to FPGA development
and the hardest of hard real-time but IMO, they're especially
useful in applications development.

--
Les Cargill


 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-27-2012
Nick Keighley wrote:
> On Oct 26, 1:53 pm, Les Cargill <(E-Mail Removed)> wrote:
>> gwowen wrote:
>>> On Oct 22, 8:02 pm, Les Cargill <(E-Mail Removed)> 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.

>
> do you assume memory is allocated in a stack-like manner? Because that
> simply wouldn't work on the systems I'm thinking about. Mobile radio
> calls don't appear and disappear in a stack-like manner.
>


No, something else. More an.... accounting system that's relatively
transparent that allows you to more easily estimate the state of the heap.

>>> 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()"?).

>
> way too late in most of the programs I've encountered. These systems
> are supposed to run "forever". Cleaning up all the crap on exit is no
> good in a program that isn't supposed to exit!
>


So make your own "exit()" equivalent...

This being said, *culturally*, RAII is probably a better solution
because it's better known.

>> 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
 
Reply With Quote
 
ImpalerCore
Guest
Posts: n/a
 
      10-28-2012
On Oct 27, 4:46*pm, Paavo Helde <(E-Mail Removed)> wrote:
> ImpalerCore <(E-Mail Removed)> wrote innews:(E-Mail Removed):
> > On Oct 27, 12:13*pm, Paavo Helde <(E-Mail Removed)> wrote:
> >> ImpalerCore <(E-Mail Removed)> wrote
> >> innews:906d2617-80f6-408e-bcf2-2ad

> > (E-Mail Removed):

>
> >> > 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.
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      11-11-2012
On Oct 18, 8:55*pm, Stuart <(E-Mail Removed)> wrote:
> I'm intrigued. I have never ever met someone who described himself as a
> C programmer. May I ask what kind of business you are in?


I describe myself as a C programmer too, and am
available to field questions

I write application code for payment terminals. You have to
use the toolset that the hardware vendor provides for
developing code that can interface with its OS, typically
this is some arcane modification of C with fairly stringent
memory requirements.



 
Reply With Quote
 
Adam Wysocki
Guest
Posts: n/a
 
      11-12-2012
In comp.lang.c Old Wolf <(E-Mail Removed)> wrote:

> I write application code for payment terminals.


What vendor and platform?

--
Gof
http://www.chmurka.net/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Array question - How dynamic is dynamic? Ruby Student Ruby 4 04-09-2009 12:59 PM
Dynamic control on aspx page, dynamic location Chris Thunell ASP .Net 3 07-21-2004 04:52 PM
VPN between 2 Cisco routers (1 static, 1 dynamic) with access from stat --> dynamic over ISDN Hans-Peter Walter Cisco 3 01-21-2004 02:12 PM
Does Pix or cisco router support dynamic-to-dynamic IPSec VPN? c Cisco 2 01-13-2004 01:53 AM
Re: Dynamic Table with Dynamic LinkButtons Rick Glos ASP .Net 0 07-08-2003 01:09 PM



Advertisments