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

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

Learning C as an existing programmer

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

Contents

  Learning C as an existing programmer rammy <nospam@nospam.com> - 2012-06-24 21:52 +0000
    Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-25 10:26 +1200
      Re: Learning C as an existing programmer "Charles Richmond" <numerist@aquaporin4.com> - 2012-06-24 18:28 -0500
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:05 -0600
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:10 -0600
          Re: Learning C as an existing programmer Weland <weland@faeroes.freeshell.org> - 2012-06-25 08:20 +0000
            Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-07-02 01:46 -0600
        Re: Learning C as an existing programmer Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-06-25 20:37 +0000
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 16:51 -0400
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-25 14:25 -0700
            Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:50 -0500
            Re: Learning C as an existing programmer William Ahern <william@wilbur.25thandClement.com> - 2012-06-25 16:52 -0700
          Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:49 -0500
          Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:09 -0700
      Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:55 -0600
      Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 13:26 -0700
        Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 17:07 -0400
        Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 14:56 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 18:29 -0400
          Re: Learning C as an existing programmer pete <pfiland@mindspring.com> - 2012-06-25 18:56 -0400
            Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:21 -0700
              Re: Learning C as an existing programmer Robert Wessel <robertwessel2@yahoo.com> - 2012-06-26 02:56 -0500
              Re: Learning C as an existing programmer Ike Naar <ike@sverige.freeshell.org> - 2012-06-26 08:10 +0000
          Re: Learning C as an existing programmer "J. J. Farrell" <jjf@bcs.org.uk> - 2012-06-26 07:06 +0100
        Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:18 -0700
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-26 00:23 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-26 06:47 -0400
    Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 01:21 +0100
    Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:54 -0600
    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 09:19 +0200
      Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:15 +0100
        Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:30 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:43 +0100
            Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:55 +0200
        Re: Learning C as an existing programmer Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-25 10:38 +0000
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 13:05 +0100
        Re: Learning C as an existing programmer Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-06-25 10:56 +0000
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 13:34 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 12:43 +0100
            Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 15:16 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
                Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:07 +0200
                  Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-26 12:05 +0100
                    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 14:28 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
      Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-25 18:21 -0700
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:03 +0200
    Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-25 00:50 -0700
      Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 11:50 +0100
        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-25 04:32 -0700
          Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 14:25 +0100
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 02:38 -0700
              Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:13 +0200
                Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:15 +0200
                Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-26 23:08 +1200
              Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-27 01:55 +0100
                Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-26 18:43 -0700
          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:27 -0700
            Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-26 00:18 -0700
              Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 04:02 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 05:54 -0700
                Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 07:22 -0700
                  Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-28 04:28 -0700
                    Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 10:07 -0700
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-02 08:57 -0700
                        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-07-03 03:26 -0700
                          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:28 -0700
                        Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 18:16 -0700
                          Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 04:51 -0700
                            Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-07 16:48 +0100
                              Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:07 -0700
                            Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 12:27 -0700
                Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:01 +0100
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:13 -0700
                    Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-07 19:35 +0100
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 11:52 -0700
                      Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 19:40 -0700
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 03:03 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:34 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:40 -0700
              Re: Learning C as an existing programmer Gareth Owen <gwowen@gmail.com> - 2012-06-27 07:16 +0100
                Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-27 06:48 -0400
              Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 09:18 +0200
                Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-28 02:02 -0700
                  Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 12:19 +0200
            Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:00 +0100
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 15:56 -0700
                Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:18 -0700
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 11:56 -0700

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

#22681

David Brown wrote:

> So that's a "yes" in answer to my first question?

No, the rest, as I've said, is just noise.  Fanboyism only leads people to 
look at every problem as being a nail to try to justify using their 
particular brand of hammer.


Rui Maciel

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

#22770

On 25/06/2012 15:39, Rui Maciel wrote:
> David Brown wrote:
>
>> So that's a "yes" in answer to my first question?
>
> No, the rest, as I've said, is just noise.  Fanboyism only leads people to
> look at every problem as being a nail to try to justify using their
> particular brand of hammer.
>

I agree - that's why I am suggesting the OP looks at alternatives that 
might be a better choice overall, rather than following the "only C is 
fast enough" fanboyism.

But until the OP actually posts back with more information or opinions, 
this argument is not going to help anyone.

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

#22779

David Brown wrote:

> I agree - that's why I am suggesting the OP looks at alternatives that
> might be a better choice overall, rather than following the "only C is
> fast enough" fanboyism.

If you read the thread you will notice two things.  

The first one is that no one, besides yourself in this post, said that "only 
C is fast enough" or any similar nonsense.  I don't know why you felt the 
need to invent this, particularly in reply to a post where C was explicitly 
mentioned on par with fortran in this criteria.

The second thing is that four completely different tools were mentioned as 
being appropriate for numerical analysis applications: Fortran, C, Matlab 
and Octave.  It's silly to throw accusations of fanboyism based on a 
suggestion of four different and competing tools.  It's even sillier when 
you do that to try to defend your pet tool.


Rui Maciel

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

#22787

On 26/06/2012 13:05, Rui Maciel wrote:
> David Brown wrote:
>
>> I agree - that's why I am suggesting the OP looks at alternatives that
>> might be a better choice overall, rather than following the "only C is
>> fast enough" fanboyism.
>
> If you read the thread you will notice two things.
>
> The first one is that no one, besides yourself in this post, said that "only
> C is fast enough" or any similar nonsense.  I don't know why you felt the
> need to invent this, particularly in reply to a post where C was explicitly
> mentioned on par with fortran in this criteria.
>
> The second thing is that four completely different tools were mentioned as
> being appropriate for numerical analysis applications: Fortran, C, Matlab
> and Octave.  It's silly to throw accusations of fanboyism based on a
> suggestion of four different and competing tools.  It's even sillier when
> you do that to try to defend your pet tool.
>
>
> Rui Maciel
>

I'm sorry if I've been reading too much into your posts, or 
misinterpreting them.  And yes, I missed your point about Fortran and C 
being on a par.

My reaction is really about your claim:

> And numerical analysis boils down to details of programming, as the main
> purpose is to squeese as much computational juice out of a computer as
> possible.  You don't get that by simply toying with algorithms.

In fact, it is by "toying with algorithms" that you get major 
improvements in speed (or accuracy).  I'm sure you know this.

You then dismissed Python as "still not an adequate option" - I don't 
see any reason here other than that you think Python is too slow to be 
useful for numerical analysis.  And since Python is, in fact, perfectly 
usable for "playing around with algorithms", and has very fast libraries 
(NumPy etc.) for number crunching, I have to assume your dismissal here 
is based on ignorance.

I'll agree that it was silly to accuse you of "C fanboyism" - and I 
apologise.  But I think it was equally silly of /you/ to accuse /me/ of 
fanboyism in the first place - I have only ever offered Python as an 
alternative suggestion for the OP to look at.

SciPy and NumPy are very popular by people doing numerical analysis and 
other scientific work who want something more than 
Octave/Matlab/Scilab/etc., but don't want to bother with C (or Fortran 
or C++).  If the OP falls into this category, then he should look at 
Python as one of his options.

For the record, I have never used SciPy myself - and I have only brief 
experience with NumPy (though I've used Python quite a lot).  It is not 
my "pet tool" - it is a tool I know a little about, and which I think is 
likely to be useful to the OP - hence I recommend he looks at it.

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

#22682

David Brown wrote:

> So that's a "yes" in answer to my first question?

No, the rest, as I've said, is just noise.  Fanboyism only leads people to 
look at every problem as being a nail to try to justify using their 
particular brand of hammer.


Rui Maciel

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

#22743

David Brown於 2012年6月25日星期一UTC+8下午3時19分38秒寫道：
> On 24/06/2012 23:52, rammy wrote:
> > Hi
> >
> > I need to learn C for numerical analysis as part of my Masters research.
> >
> > I already have quite a lot of experience with BASIC (my progression was GW
> > BASIC -> QBASIC -> Visual BASIC -> VB.net) so I want to find an
> > introductory book on "C for BASIC programmers".
> >
> > I looked through the campus bookstore and didn't really find anything.
> > Can you recommend some learning materials that will leverage my existing
> > programming knowledge?
> >
> > Thanks in advance!
> >
> 
> Do you have to use C?  There are other languages that might be a better 
> choice - Python with SciPy / NumPy comes to mind - then you can 
> concentrate more on the numerical analysis, and less on the details of 
> programming.

Well, the list, the dictionary, and the long integer types
and related operations  are all built in  basic types in Python.

Python is a higher level language. 

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

#22769

On 26/06/2012 03:21, 88888 Dihedral wrote:
> David Brown於 2012年6月25日星期一UTC+8下午3時19分38秒寫道：
>> On 24/06/2012 23:52, rammy wrote:
>>> Hi
>>>
>>> I need to learn C for numerical analysis as part of my Masters research.
>>>
>>> I already have quite a lot of experience with BASIC (my progression was GW
>>> BASIC -> QBASIC -> Visual BASIC -> VB.net) so I want to find an
>>> introductory book on "C for BASIC programmers".
>>>
>>> I looked through the campus bookstore and didn't really find anything.
>>> Can you recommend some learning materials that will leverage my existing
>>> programming knowledge?
>>>
>>> Thanks in advance!
>>>
>>
>> Do you have to use C?  There are other languages that might be a better
>> choice - Python with SciPy / NumPy comes to mind - then you can
>> concentrate more on the numerical analysis, and less on the details of
>> programming.
>
> Well, the list, the dictionary, and the long integer types
> and related operations  are all built in  basic types in Python.
>
> Python is a higher level language.
>

That's exactly the point.  Being a higher level language, it's easier to 
work with these concepts - which makes it faster to work with when you 
are "playing around" or "experimenting".  I can't say I do a lot of 
numerical analysis - certainly not at the masters level.  But when I do 
it, I'll use Python first to play about with the ideas, test algorithms, 
generate tables of coefficients, etc.  The result will typically then be 
re-implemented in C for the final product.

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

#22658

בתאריך יום ראשון, 24 ביוני 2012 22:52:37 UTC+1, מאת rammy:
> Hi
> 
> I need to learn C for numerical analysis as part of my Masters research.
> 
> I already have quite a lot of experience with BASIC (my progression was GW 
> BASIC -> QBASIC -> Visual BASIC -> VB.net) so I want to find an 
> introductory book on "C for BASIC programmers".
> 
Everything works in C more or less as you would expect, with a few exceptions.

Types are strict. So a variable must be either a double-precison float, or a single precision float, or an integer, and so on. There's not much intelligent mixing of types.

You declare structures to create compound types,a nd this is used heavily.

Strings are just arrays of chars.

Virtually everything is a function. C itself just does logic. There's no real difference between a built-in fucntiona nd one you write yourself. So there's no print statement, instead you call a function.


Pointers are the heart of C, and the thing that C does rather differently to other languages. Pointers are essentially raw memory addresses, Peek and Poke in old-fashioned Basic. Basically a C program consists of passing about pointers, and reading and writing to them, doing calculations and moving data about in memory.

malloc() is very heavily used. Usually you won't know the length of an array at compile time. So you malloc() a block of memory to use for the array. Also you often use malloc() to create structures like trees and linked lists. 

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

#22670

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Pointers are the heart of C, and the thing that C does rather
> differently to other languages. Pointers are essentially raw memory
> addresses, Peek and Poke in old-fashioned Basic.

That's not a helpful thing to say to someone new to C.  You don't have
to go into details but C's pointers, crucially, have a type.  The type
is used to give a more useful meaning to the operations done on them,
just like the type a variables are used to determine the meaning of
operations like / (integer or floating division).  C pointer operations
will be baffling if they are seen as raw addresses.

<snip>
> malloc() is very heavily used. Usually you won't know the length of an
> array at compile time. So you malloc() a block of memory to use for
> the array.

Unless you can use "modern" C with its flexible arrays.  They don't
behave exactly like malloced storage does, but they are often more
appropriate for numerical programs.

<snip>
-- 
Ben.

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

#22674

On Jun 25, 11:50 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> > malloc() is very heavily used. Usually you won't know the length of an
> > array at compile time. So you malloc() a block of memory to use for
> > the array.
>
> Unless you can use "modern" C with its flexible arrays.  They don't
> behave exactly like malloced storage does, but they are often more
> appropriate for numerical programs.

Really? Only if they're (i) of bounded size or (ii) of trivially small
size. Otherwise you're just asking for horrible, undetectable stack
overflow bugs, because VLAs have no failure mechanism.

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

#22679

gwowen <gwowen@gmail.com> writes:

> On Jun 25, 11:50 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> > malloc() is very heavily used. Usually you won't know the length of an
>> > array at compile time. So you malloc() a block of memory to use for
>> > the array.
>>
>> Unless you can use "modern" C with its flexible arrays.  They don't
>> behave exactly like malloced storage does, but they are often more
>> appropriate for numerical programs.
>
> Really? Only if they're (i) of bounded size or (ii) of trivially small
> size. Otherwise you're just asking for horrible, undetectable stack
> overflow bugs, because VLAs have no failure mechanism.

Yes, really, but there are several of parts to the answer.

First, I accept that there are systems where you can't rely on them, but
I'd expect more from a modern system.  I can set a stack size if the
default is too small (I can even set it to "unlimited") and I get a
run-time error if my arrays are too large.

Secondly, your characterisation of the size is, err... provocative.  All
arrays (malloced or otherwise) are of bounded size so (i) is a red
herring.  To say that they can only be what you consider trivially small
does not matter if trivially small is big enough.  The phrase you use,
however, is clearly designed to suggest that they are pointless but
that's not been my (limited) experience.

Thirdly, C99's variably modified arrays are useful even if you don't
give all (or some) of your arrays automatic storage.  The ability they
offer to specify the size of dimensions other than the "last" can be
very helpful.

-- 
Ben.

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

#22771

On Jun 25, 2:25 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> Secondly, your characterisation of the size is, err... provocative.

No.  I mean "trivially small" in the sense that "it really doesn't
matter how many of these you have, something else will blow up first,
so don't worry about it."

> All arrays (malloced or otherwise) are of bounded size so (i) is a red
> herring.

They're not bounded at compile time, or at the time you set the stack-
size. Arrays are  often dependent on the input size, and often non-
linearly so (say calculating a Gram matrix).  If you don't know the
input size in advance, and it might be large, VLAs are a non-starter.

Again, VLAs are fine if and only if,
i) if you, or your library user, knows the maximum input size in
advance,

ii) you're happy doing the worst-case stack calculation by hand and
setting a sufficient stacksize [or, better, leave this to your users!]
(good luck if you're doing an adaptive / multiscale grid solver)

iii) you don't mind undefined behaviour if someone get that
calculation wrong...

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

#22773

Le 26/06/12 11:38, gwowen a écrit :
> On Jun 25, 2:25 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> Secondly, your characterisation of the size is, err... provocative.
>
> No.  I mean "trivially small" in the sense that "it really doesn't
> matter how many of these you have, something else will blow up first,
> so don't worry about it."
>
>> All arrays (malloced or otherwise) are of bounded size so (i) is a red
>> herring.
>
> They're not bounded at compile time, or at the time you set the stack-
> size. Arrays are  often dependent on the input size, and often non-
> linearly so (say calculating a Gram matrix).  If you don't know the
> input size in advance, and it might be large, VLAs are a non-starter.
>
> Again, VLAs are fine if and only if,
> i) if you, or your library user, knows the maximum input size in
> advance,
>
> ii) you're happy doing the worst-case stack calculation by hand and
> setting a sufficient stacksize [or, better, leave this to your users!]
> (good luck if you're doing an adaptive / multiscale grid solver)
>
> iii) you don't mind undefined behaviour if someone get that
> calculation wrong...
>


Look, when you do:

int fn(void)
{
	double table[4096];
}

There is no failure indication if there wasn't any more stack space for 
allocating 4096 doubles.

VLA's are the same.

Conclusion:

Be careful with the stack.

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

#22774

Le 26/06/12 12:13, jacob navia a écrit :
>
> Conclusion:
>
> Be careful with the stack.


Excuse me. Of course I know that C "has no stack", and that the standard 
doesn't mention the word stack, etc.

So we can spare us that discussion again :-)

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

#22780

On 06/26/12 10:13 PM, jacob navia wrote:
> Le 26/06/12 11:38, gwowen a écrit :
>> On Jun 25, 2:25 pm, Ben Bacarisse<ben.use...@bsb.me.uk>  wrote:
>>
>>> Secondly, your characterisation of the size is, err... provocative.
>>
>> No.  I mean "trivially small" in the sense that "it really doesn't
>> matter how many of these you have, something else will blow up first,
>> so don't worry about it."
>>
>>> All arrays (malloced or otherwise) are of bounded size so (i) is a red
>>> herring.
>>
>> They're not bounded at compile time, or at the time you set the stack-
>> size. Arrays are  often dependent on the input size, and often non-
>> linearly so (say calculating a Gram matrix).  If you don't know the
>> input size in advance, and it might be large, VLAs are a non-starter.
>>
>> Again, VLAs are fine if and only if,
>> i) if you, or your library user, knows the maximum input size in
>> advance,
>>
>> ii) you're happy doing the worst-case stack calculation by hand and
>> setting a sufficient stacksize [or, better, leave this to your users!]
>> (good luck if you're doing an adaptive / multiscale grid solver)
>>
>> iii) you don't mind undefined behaviour if someone get that
>> calculation wrong...
>
> Look, when you do:
>
> int fn(void)
> {
> 	double table[4096];
> }
>
> There is no failure indication if there wasn't any more stack space for
> allocating 4096 doubles.

But you can do a static analysis (unless recursion is in the frame) of 
stack use with fixed size allocations.  I've been through that pain a 
few times on embedded systems.

> VLA's are the same.

Not really, they do open another can of worms.

> Conclusion:
>
> Be careful with the stack.

Quite!

-- 
Ian Collins

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

#22842

gwowen <gwowen@gmail.com> writes:

> On Jun 25, 2:25 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> Secondly, your characterisation of the size is, err... provocative.
>
> No.  I mean "trivially small" in the sense that "it really doesn't
> matter how many of these you have, something else will blow up first,
> so don't worry about it."

I don't know what this means.  Sounds like more polemic, but maybe there
is a significant point here.

>> All arrays (malloced or otherwise) are of bounded size so (i) is a red
>> herring.
>
> They're not bounded at compile time, or at the time you set the stack-
> size. Arrays are  often dependent on the input size, and often non-
> linearly so (say calculating a Gram matrix).  If you don't know the
> input size in advance, and it might be large, VLAs are a non-starter.

So by "not bounded" you meant that the size is not known at compile
time.  That's the essence of VLAs.  This criticism is that VLAs are
a non-starter because they are VLAs.

> Again, VLAs are fine if and only if,
> i) if you, or your library user, knows the maximum input size in
> advance,
>
> ii) you're happy doing the worst-case stack calculation by hand and
> setting a sufficient stacksize [or, better, leave this to your users!]
> (good luck if you're doing an adaptive / multiscale grid solver)

Straw man.  Who said anything about doing an adaptive / multiscale grid
solver with stack-allocated VLAs?

> iii) you don't mind undefined behaviour if someone get that
> calculation wrong...

Do you do ii) and accept iii) for all your programs, because they apply
in the absence of VLAs?  I don't.  Most of the time I just assume that I
don't run out of stack and that if I do my system will let me know.
There are cases when the same rough and ready approach works with VLAs.

-- 
Ben.

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

#22843

Ben Bacarisse於 2012年6月27日星期三UTC+8上午8時55分59秒寫道：
> gwowen <gwowen@gmail.com> writes:
> 
> > On Jun 25, 2:25 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >
> >> Secondly, your characterisation of the size is, err... provocative.
> >
> > No.  I mean "trivially small" in the sense that "it really doesn't
> > matter how many of these you have, something else will blow up first,
> > so don't worry about it."
> 
> I don't know what this means.  Sounds like more polemic, but maybe there
> is a significant point here.
> 
> >> All arrays (malloced or otherwise) are of bounded size so (i) is a red
> >> herring.
> >
> > They're not bounded at compile time, or at the time you set the stack-
> > size. Arrays are  often dependent on the input size, and often non-
> > linearly so (say calculating a Gram matrix).  If you don't know the
> > input size in advance, and it might be large, VLAs are a non-starter.
> 
> So by "not bounded" you meant that the size is not known at compile
> time.  That's the essence of VLAs.  This criticism is that VLAs are
> a non-starter because they are VLAs.
> 
> > Again, VLAs are fine if and only if,
> > i) if you, or your library user, knows the maximum input size in
> > advance,
> >
> > ii) you're happy doing the worst-case stack calculation by hand and
> > setting a sufficient stacksize [or, better, leave this to your users!]
> > (good luck if you're doing an adaptive / multiscale grid solver)
> 
> Straw man.  Who said anything about doing an adaptive / multiscale grid
> solver with stack-allocated VLAs?
> 
> > iii) you don't mind undefined behaviour if someone get that
> > calculation wrong...
> 
> Do you do ii) and accept iii) for all your programs, because they apply
> in the absence of VLAs?  I don't.  Most of the time I just assume that I
> don't run out of stack and that if I do my system will let me know.
> There are cases when the same rough and ready approach works with VLAs.
>  
 

In the developement and debugging phase, 
it is very common to use recursion based functions which
use the stack.

But if the function under development is critical, 
then the depth of the stack used should be
tested rigorously to find the bounded depth of the stack in practical 
applications in order that the function  can be rewritten 
as a non-recursive version.

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

#22733

gwowen <gwowen@gmail.com> writes:

> On Jun 25, 11:50 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> > malloc() is very heavily used. Usually you won't know the length of an
>> > array at compile time. So you malloc() a block of memory to use for
>> > the array.
>>
>> Unless you can use "modern" C with its flexible arrays.  They don't
>> behave exactly like malloced storage does, but they are often more
>> appropriate for numerical programs.
>
> Really? Only if they're (i) of bounded size or (ii) of trivially small
> size. Otherwise you're just asking for horrible, undetectable stack
> overflow bugs, because VLAs have no failure mechanism.

What you mean is that VLAs have no portably guaranteed failure
mechanism.  On a particular implementation they may very well
have a well-defined, implementation-supplied, such mechanism.

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

#22758

בתאריך יום שני, 25 ביוני 2012 22:27:02 UTC+1, מאת Tim Rentsch:
> gwowen <gwowen@gmail.com> writes:
> 
> What you mean is that VLAs have no portably guaranteed failure
> mechanism.  On a particular implementation they may very well
> have a well-defined, implementation-supplied, such mechanism.
>
And these days if you're writing C you're probably more likely to be writing components rather than complete programs. A component does know what to do on out of memory -sometimes relying on the OS to kill the process is the best you can do, sometimes its completely unacceptable. 

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

#22778

On Tuesday, June 26, 2012 8:18:56 AM UTC+1, Malcolm McLean wrote:
> בתאריך יום שני, 25 ביוני 2012 22:27:02 UTC+1, מאת Tim Rentsch:
> > gwowen <gwowen@gmail.com> writes:
> > 
> > What you mean is that VLAs have no portably guaranteed failure
> > mechanism.  On a particular implementation they may very well
> > have a well-defined, implementation-supplied, such mechanism.
> >
> And these days if you're writing C you're probably more likely to be writing components rather than complete programs. A component does know what to do on out of memory -sometimes relying on the OS to kill the process is the best you can do, sometimes its completely unacceptable.

ITYM "A component does *not* know what to do on out of memory..."

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

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

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

csiph-web