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-21-2012
Juha Nieminen wrote:
> In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
>>> Just the standard library alone makes life so much
>>> easier (no matter if you are just making a quick 50-line test program
>>> or a large 50k-line serious project.)

>>
>> Or you get an old version of STL that's buggy and there's an observed
>> problem that takes up to a *year* ( off and on - not continuous
>> pushing ) to resolve.

>
> When C programmers have to resort to problems that might have been
> relevant 20 years ago in order to make their case, I think that
> demonstrates quite well that they don't have any *actual* argument.
>


This was much, much more recent than that. People are
*still running* 20 year old STL implementations...

"So why don't you upgrade?" My very question. The answer
was interesting.

>> Also, I once had a ... data structure that I built with a need
>> for associativity ( think arrays indexed by strings ) where it
>> was twice the code* and half the performance to use STL than
>> bash something out in 'C'. Oh, if STL had only had "foreach"
>> from the start....

>
> "The standard library cannot be used for this", is a rather weak
> argument for why the standard library is not useful.


It's an explicit demonstration of the *dis*utility of it. Dunno
about you, but I don't get to point to that and say "abandon
hope", I have to go fix it.

> The standard
> library does not offer *everything*. So what? What it does offer
> is in practice very useful.
>


It *can* be. What we're arguing about is whether or not
language features enable bad practice, and that's not
going to be settled in one thread.

--
Les Cargill
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-21-2012
On Thu, 2012-10-18, William Ahern wrote:
> In comp.lang.c Stuart <(E-Mail Removed)> wrote:
>> On 10/18/12 James Kuyper wrote:
>> [snip]
>> > I'm primarily a C programmer, so I may be
>> > missing out some elegant C++ way of doing that, but the following
>> > inelegant (and untested) code should do the job:

>> [snip]

>
>> 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? My guess is your
>> line of work includes either device drivers, embedded devices, kernel code
>> or something else that forces you to write C instead of C++. In all these
>> years I have never met someone who used C instead of C++ unless he was
>> forced to do so.

>
> Well, you have now. I've worked in several shops (both small and billion
> dollar companies) which were C only by choice. The consensus was that the
> cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.


I've worked in those places too. Unlike you I believe they are
misguided, but I agree they exist and aren't unusual.

> I'm guessing that you come from a Windows background and/or graduated
> college in the past 3 or 4 years. That's usually how it goes, IME. C++
> didn't make waves in the Unix world until a few years ago, and then it took
> off with Google and Apple**, especially when they picked up their college
> recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly
> universities which dumped SUN--or never had the history to begin with. Which
> isn't a slight, just an observation about the peculiarities of C++ culture.


I get the feeling (which may be incorrect) that you justify discarding
C++ by trying to associate it with Microsoft, and anti-Unix nonsense
in general. Since I'm pro-Unix myself that annoys me.

There are /different/ C++ cultures, just like there are different C
cultures. For me C++ fits very well into Unix programming[1]. It's
just like Unix programming in C, only with better tools such as the
standard containers, RAII and so on. I don't know what they do in the
Windows world ... seems to be most have spent many years down the
Java/.NET route until very recently.

/Jorgen

[1] One perhaps surprising reason is the Unix APIs are C API. That way
I'm not tied to someone's antiquated ideas about how an
object-oriented interface should work. Sure, C APIs can feel
primitive at times -- but at least a decent number of people know
how do design them properly!

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      10-21-2012
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
 
Reply With Quote
 
Greg Martin
Guest
Posts: n/a
 
      10-21-2012
On 12-10-21 12:33 PM, Jorgen Grahn wrote:
> On Thu, 2012-10-18, William Ahern wrote:
>> In comp.lang.c Stuart <(E-Mail Removed)> wrote:
>>> On 10/18/12 James Kuyper wrote:
>>> [snip]
>>>> I'm primarily a C programmer, so I may be
>>>> missing out some elegant C++ way of doing that, but the following
>>>> inelegant (and untested) code should do the job:
>>> [snip]

>>
>>> 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? My guess is your
>>> line of work includes either device drivers, embedded devices, kernel code
>>> or something else that forces you to write C instead of C++. In all these
>>> years I have never met someone who used C instead of C++ unless he was
>>> forced to do so.

>>
>> Well, you have now. I've worked in several shops (both small and billion
>> dollar companies) which were C only by choice. The consensus was that the
>> cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.

>
> I've worked in those places too. Unlike you I believe they are
> misguided, but I agree they exist and aren't unusual.
>


What seems to be the real irony here is that it isn't 1992, though I'm
getting a decided deja vu, but 2012 when this conversation should be
taking place between C++ zealots and C# adherents (or maybe Java,
Python, Ruby, erlang programmers et al).

I have worked on large scale projects in both C++ and C and prefer C
however misguided you may feel that makes me. On the other hand there
are projects for which I prefer to use other languages. C++ isn't on my
goto list, pun intended.

Horse for courses I guess. I'm quite fond of erlang for instance though
I don't believe you should learn it as I'm sure you can accomplish what
you need to do in C++, however, there are a whole lot of things it does
very well and with a fraction of the effort required by C++. Still, I
don't suppose the sky will fall in on comp.lang.c++ any more then it has
on comp.lang.c.


 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-21-2012
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
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ Les Cargill <(E-Mail Removed)> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ James Kuyper <(E-Mail Removed)> wrote:
> In any event, your summary of my argument dropped the key point - that
> the greater complexity of C++ provides more temptations for incompetent
> programmers to generate overly complex code than C does.


My experience makes me disagree with the the last part. I would say that
the limiting "simplicity" of C causes many incompetent programmers to
create horrible code (much of which is caused *because* C is so archaic.)

Many C advocates argue that the "simplicity" of the language somehow
induces people to make straightforward, clear, simple and efficient
implementations. That's not what I see at all. Instead, what I see
quite often is really complicated code with tons of implied coding
conventions (that exist solely to address things like memory management
issues), and which is quite frankly horribly designed. Just take almost
any C project out there and study its source code. You'll easily find
400+ LOC functions (with little to no comments), that use lots of
repetition and/or are really obfuscated, oftentimes riddled with gotos,
and so on and so forth. They often also suffer from inefficiency because
the programmer did a "straightforward" job at implementing the task at
hand.

I'm not saying that *every* C program out there is like that. I'm saying
that quite a significant portion of them are. There's nothing in C that
would somehow induce or encourage people to make good code.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
>> When C programmers have to resort to problems that might have been
>> relevant 20 years ago in order to make their case, I think that
>> demonstrates quite well that they don't have any *actual* argument.

>
> This was much, much more recent than that. People are
> *still running* 20 year old STL implementations...


And this affects me how, exactly? Why should *I* care? Why should I choose
C over C++ if some people are still running 20 year old STL implementations?

>> "The standard library cannot be used for this", is a rather weak
>> argument for why the standard library is not useful.

>
> It's an explicit demonstration of the *dis*utility of it. Dunno
> about you, but I don't get to point to that and say "abandon
> hope", I have to go fix it.


I don't understand that at all. Since the standard library does not
offer a solution for every single problem in existence, it's not
useful? That's like one of the craziest arguments I have ever heard,
even from a C advocate (and that's saying quite a lot; believe me,
I have seen quite crazy stuff.)
 
Reply With Quote
 
ptyxs
Guest
Posts: n/a
 
      10-22-2012
Le 21/10/2012 19:54, Les Cargill a écrit :
To badly
> paraphrase Voltaire, "hell is other people's code*." The more of
> it there is, the more bugs there are.
>

You probably meant 'to paraphrase Jean-Paul Sartre'...
Voltaire has nothing to do with that sentence...
Ptyxs



 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-22-2012
On 10/22/2012 04:13 AM, Juha Nieminen wrote:
> In comp.lang.c++ James Kuyper <(E-Mail Removed)> wrote:
>> In any event, your summary of my argument dropped the key point - that
>> the greater complexity of C++ provides more temptations for incompetent
>> programmers to generate overly complex code than C does.

>
> My experience makes me disagree with the the last part. I would say that
> the limiting "simplicity" of C causes many incompetent programmers to
> create horrible code (much of which is caused *because* C is so archaic.


I've seen incompetent C programmers produce horrible code, and I've seen
incompetent C++ programmers produce horrible code; except for the
comments I've already made about the matter (see below), I haven't
notice much difference between the two different types of horribleness.

From my previous message:
>> Of course, that
>> doesn't prevent them from producing bad C code, but the bad C++ code
>> that I've seen has been much more complex to untangle than the bad C
>> code I've fixed.


So our experiences have been quit different. There's not much more
useful that can be said about that.
 
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