«

Ian Collins <ian-> wrote:

> Flash Gordon wrote:
> > I don't need the complexities introduced by some of your design
> > decisions, such as your decision to make it so generic (I know exactly
> > what I need, and it will never need to swap to being a tree or hash or
> > whatever). I've got something far simpler which was debugged years ago
> > which has everything needed for what it is used for.
>
> I don't know whether Jacob will achieve this (within the bounds of
> standard C), but being generic is one of the reasons behind the C++ STL.
> The beauty of the STL design is most users never see the complexity
> behind this, they just use the containers "as is".

IMO, that is the beauty of STL for C++ users, and the danger for C
users. I _want_ to know how complex a container I use is. I want no
surprises. That's why I use C, and not Java or C++.

Richard

Ian Collins <ian-> wrote:

> Tom St Denis wrote:
> > On Jan 7, 12:19 pm, Marco <prenom_no...@yahoo.com> wrote:
> >> Totally agree - if not written in standard C (unfortunately that still
> >> means C90 today) then most folks just won't want it
> >
> > Nothing wrong with C90. Only thing I borrow from C99 is long long. I
> > think that VLA and mid-block declarations are bad coding practice.
>
> While VLAs have their obvious problems, I don't see how you can object
> to something that shortens and clarifies code (mixed declarations and code).

I object because IME it doesn't clarify the code. Oh, it _could_ be used
to define an object just before the code to which it logically belongs,
but IME if nearly always _is_ used in the thought process "Oh, damn, I
need another total counter! Better declare it right here, where I first
thought of it".
That's also why I do _not_ object to the specific case of for-loop local
declarations: because in that case, it is impossible to put the
declaration in a random place somewhere hidden inside the rest of the
code. It's always, guaranteed, right where it belongs.

Richard

Richard Bos wrote:
> Ian Collins <ian-> wrote:
>
>> Flash Gordon wrote:
>>> I don't need the complexities introduced by some of your design
>>> decisions, such as your decision to make it so generic (I know exactly
>>> what I need, and it will never need to swap to being a tree or hash or
>>> whatever). I've got something far simpler which was debugged years ago
>>> which has everything needed for what it is used for.
>> I don't know whether Jacob will achieve this (within the bounds of
>> standard C), but being generic is one of the reasons behind the C++ STL.
>> The beauty of the STL design is most users never see the complexity
>> behind this, they just use the containers "as is".
>
> IMO, that is the beauty of STL for C++ users, and the danger for C
> users. I _want_ to know how complex a container I use is. I want no
> surprises. That's why I use C, and not Java or C++.

The complexity of the standard C++ containers is defined in the language
standard, so there wont be any surprises.

--
Ian Collins

Richard Bos wrote:
> Ian Collins <ian-> wrote:
>
>> Tom St Denis wrote:
>>> On Jan 7, 12:19 pm, Marco <prenom_no...@yahoo.com> wrote:
>>>> Totally agree - if not written in standard C (unfortunately that still
>>>> means C90 today) then most folks just won't want it
>>> Nothing wrong with C90. Only thing I borrow from C99 is long long. I
>>> think that VLA and mid-block declarations are bad coding practice.
>> While VLAs have their obvious problems, I don't see how you can object
>> to something that shortens and clarifies code (mixed declarations and code).
>
> I object because IME it doesn't clarify the code. Oh, it _could_ be used
> to define an object just before the code to which it logically belongs,
> but IME if nearly always _is_ used in the thought process "Oh, damn, I
> need another total counter! Better declare it right here, where I first
> thought of it".

A common use case (at least for me) is for intermediate values of
complex expressions. A trivial example being:

const int systemPower = busVoltage(someBus) * loadCurrent(someBus);

Such values are naturally const, so they can't really be declared before
they are initialised.

--
Ian Collins

On Sat, 09 Jan 2010 13:57:44 GMT, "bartc" <> wrote:
<snip>
> Functions already have a local namespace.
>
> How big are your functions that you need to have multiple namespaces inside
> them!
>
C calls a function body, or other block, or a translation-unit ~=
source file, 'scope' (in each case excluding any contained scope
which re-declares aka shadows the identifier). 'namespace' means
something else, namely one of: tags; members per struct/union;
labels per function; or all other 'ordinary' identifiers per scope.
<OT> and in C++ namespace is something else again. </>
Macronames preempt (all) the other namespaces.

> (I believe C allows you at least 1e50 distinct identifiers within one
> namespace, and that's without even making use of case sensitivity.)
>
Do you mean 'allow' as in an implementation must provide (and a
portable progam may use) or an implementation _may_ provide?

5.2.4.1 specifies some 'minimum maximums', amounts an implementation
must provide (although formally only in 'one program' which may well
not be any program you want) including the following with
C89value/C99value :

- 127/511 identifiers with block scope [per] block

- 31/127 parameters [per] function

- 511/4095 file-scope identifiers per t.u.

- 127/1023 members of a struct or union; members of an enumeration are
ordinary identifiers in the containing scope, and I don't see anything
about the number of tags per scope or t.u.

The only obvious maximum maximum (!) is the number of distinct
identifiers using the specified (C89) or basic (C99) character set
of length up to 31 (C89) or 63 (C99) less keywords (negligible).
The former of these is in the general area of 1e55, and may be what
you were thinking of, but a program containing that many identifiers
could not be recorded in the universe. Possibly something like the old
BASIC CHAIN$ applied to universes would help -- but not any of us,
since we wouldn't exist when (if ever) the answer (42?) is produced.

> Presumably you can also do this:
>
> for(int i=0; i<LIMIT1;i++)
> for(int i=0; i<LIMIT2;i++)
> for(int i=0; i<LIMIT3;i++) int a=i+i+i;
>
> Very neat.

Indeed you can, although it's mostly useless, even if you (try to)
make the body less trivial.