jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) writes:

| I wrote
| |std::vector<>s are contiguous (in practice, will be required by the
| |the next TC).
| | In contrast, if I write
| |  vector<vector<double> > mat(10000,10000)
| | all the array elements will *not* occupy a single contiguous piece of
| | memory of size 1e8*sizeof(double), and the subscripting law (*) will
| | *not* hold.  (I give an example below.)
| |
| | Thus a vector-of-vectors of this type is *not* storage-compatible with
| | a 2-dimensional array in (say) a Fortran program, so  mat  cannot be
| | shared with (say) a Fortran program in any useful way.  (Making a
| | separate copy doesn't count as "sharing" in this context: it's generally
| | prohibitively inefficient in applications where large N-dimensional
| | matrices are important.)
|
| In article <m3u2bdziwl.fsf@merlin.codesourcery.com>,
| Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
| >I have always considered this as a terrible idea and a terrible
| >construct, and always prefered a plain 1-dimensional array.
| [[...]]
| >My point is that you can have the same effect with
| >
| > std::vector<double> array(10000 * 10000);
| >
| [[...]]
| >
| >I thought you would have understood the idiom I was referring to --
| >which consists in taking taking a 1-dimensional array and using classes
| >to maintain the illusion of higher dimensional array.  That idiom is in
| >the standard library and is called the valarray library.
|
| Yes, this certainly works, indeed I routinely do it myself.  Of course,
| once one has done this, there's essentially no distinction between the
| nicely-wrapped-up
|   std::vector<double> array(10000 * 10000);
| and the nicely-wrapped-up
|  double *array = new double[10000 * 10000];
| since in both cases only the N-dimensional array class(es) see the raw
| storage block.

My point here being that there is no need to track which pointer
to delete, when and such; that might be a non negligible win depending
on the problem at hand.

| But the key problems come in providing the N-dimensional indexing
| semantics:  valarray itself doesn't quite do this, rather it's a primitive
|  (minimally documented in standard C++ books like Stroustrup's
|  3rd edition, Meyers, Lippman & Lajoie, etc)
| out of which N-dimensional indexing can be built.

They are part of the valarray library -- that is why I was talking of
the valarray library.

| ...  (It's not at all
| obvious that it's the _right_ primitive for this purpose
|  [most comments about valarray in the object-oriented-numerics
|  mailing list seem to describe it as somewhat of "a solution
|  in search of a problem", and few people report using it]
| but it's certainly _a_ primitive.)

I regularily read the ONN list.  One thing to keep in mind is that
there is a real need for dense array library, and valarray does indeed
provide a solution -- you might want to convince yourself by looking
at the primitives provided by FORTRAN and those existing in the
valarray library; the primitives are there (you might argue that the
`elsewhere' construct is missing but it is not hard to construct using
C++ abstraction mechanisms).

I'm not at all convinced that the valarray library is "a solution in
search of solution."  Slogans are nice, but there are not at all
appropriate for describing technical materials.

I recognize that the numerical library is not well covered in most
textbooks but Bjarne's TC++PL3 is an exception and does a good job.

--
Gabriel Dos Reis, gdr@codesourcery.com
CodeSourcery, LLC  http://www.codesourcery.com
       http://www.codesourcery.com/gcc-compile.shtml

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos Reis wrote:
>> std::vector<>s are contiguous (in practice, will be required by the
>> the next TC).

James Kuyper wrote:
> std::vector<std::vector<T> > can't be implemented in a way that is
> contiguous in the required sense.

>> My point is that you can have the same effect with
>>
>>         std::vector<double> array(10000 * 10000);

> array[2][3] will not work at all, much less retrieve the same element
> as arr[2][3].

Of course, we could always write template classes vector2, vector3,
etc., to provide contiguous N-dimensional runtime-sized arrays.

    template <typename ELEM, int N1>
    class vector1   // A 1-D vector
    {
    public:
        ELEM &  operator [](int i) const;
        ELEM *  value() const;   // Ptr to underlying array
        ...
    };

    template <typename ELEM, int N1, int N2>
    class vector2   // A 2-D vector
    {
    public:
        vector1<ELEM, N1> &  operator [](int i) const;
        ELEM *  value() const;
        ...
    };

    template <typename ELEM, int N1, int N2, int N3>
    class vector3   // A 3-D vector
    {
    public:
        vector2<ELEM, N1, N2> &  operator [](int i) const;
        ELEM *  value() const;
        ...
    };

Then we could do this:

    extern void "fortran"  mul3(double *a, double x);

    void foo(double coeff)
    {
        vector<double, 10, 20, 15>  arr;
                       // A contiguous 3-D vector

        double  x = arr[5][2][3];
                       // Normal N-array syntax
        ...

        mul3(arr.value(), coeff);
                       // Passes a contiguous array of doubles
        ...
    }

Implementation of such classes is left as an exercise for the reader.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I wrote
| Note that <vector> does *not* provide all the functionality of a
| C99 variable length array:  an N-dimensional C99 VLA is (I think?)
| guaranteed to be stored in one contiguous piece of memory, whereas a
| <vector> of <vector>s certainly isn't.

In article <m33dizfim8.fsf@merlin.codesourcery.com>,
Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
>Well, actually an N-dimensional array is just a 1-dimensional array.
>Contiguity is, therefore, not an issue.

No!  On the contrary, contiguity *is* the *key* issue:


If I write
 double arr[10000][10000];
all the array elements will occupy a single contiguous piece of memory
of size 1e8*sizeof(double), with
 &arr[i][j] == &arr[0][0] + 10000*i + j                       (*)
for all valid subscripts i and j.  This means that native C arrays are
storage-compatible with (for example) Fortran arrays.  Thus I can pass
such a C array by reference to/from (say) a Fortran program with only
modest hassles (row- vs column-major index ordering, 0-origin vs
usually-1-origin index semantics).

These statements continue to hold for C99 VLAs:  Given
 void foo(int N, double arr[N][N])
 { /* ... */ }
the function  foo()  can (still) easily pass  arr  by reference to a
Fortran program.


In contrast, if I write
 vector<vector<double> > mat(10000,10000)
all the array elements will *not* occupy a single contiguous piece of
memory of size 1e8*sizeof(double), and the subscripting law (*) will
*not* hold.  (I give an example below.)

Thus a vector-of-vectors of this type is *not* storage-compatible with
a 2-dimensional array in (say) a Fortran program, so  mat  cannot be
shared with (say) a Fortran program in any useful way.  (Making a
separate copy doesn't count as "sharing" in this context: it's generally
prohibitively inefficient in applications where large N-dimensional
matrices are important.)


For this reason (as well as some other efficiency ones which I won't
go into), C-style arrays remain *essential* to many C++ numerical
computing applications, and C99 VLAs will be a *very* valuable addition
to C++.



An example to illustrate contiguity vs non-contiguity:

#include <stdio.h>
#include <vector>
using std::vector;

int main()
{
int arr[5][5];
vector<vector<int> > mat(5,5);

        for (int i = 0 ; i < 5 ; ++i)
        {
                for (int j = 0 ; j < 5 ; ++j)
                {
                printf("i=%d j=%d   array delta = %d   vec delta = %d\n",
                       i, j, &(arr[i][j]) - &(arr[0][0]),
                             &(mat[i][j]) - &(mat[0][0]));
                }
        }

return 0;
}

Using gcc 2.95.2 on a GNU/Linux system, the output of this program is

i=0 j=0   array delta = 0   vec delta = 0
i=0 j=1   array delta = 1   vec delta = 1
i=0 j=2   array delta = 2   vec delta = 2
i=0 j=3   array delta = 3   vec delta = 3
i=0 j=4   array delta = 4   vec delta = 4
i=1 j=0   array delta = 5   vec delta = 6
i=1 j=1   array delta = 6   vec delta = 7
i=1 j=2   array delta = 7   vec delta = 8
i=1 j=3   array delta = 8   vec delta = 9
i=1 j=4   array delta = 9   vec delta = 10
i=2 j=0   array delta = 10   vec delta = 12
i=2 j=1   array delta = 11   vec delta = 13
i=2 j=2   array delta = 12   vec delta = 14
i=2 j=3   array delta = 13   vec delta = 15
i=2 j=4   array delta = 14   vec delta = 16
i=3 j=0   array delta = 15   vec delta = 18
i=3 j=1   array delta = 16   vec delta = 19
i=3 j=2   array delta = 17   vec delta = 20
i=3 j=3   array delta = 18   vec delta = 21
i=3 j=4   array delta = 19   vec delta = 22
i=4 j=0   array delta = 20   vec delta = 24
i=4 j=1   array delta = 21   vec delta = 25
i=4 j=2   array delta = 22   vec delta = 26
i=4 j=3   array delta = 23   vec delta = 27
i=4 j=4   array delta = 24   vec delta = 28

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   Q: Only 5 countries have the death penalty for children.  Which are they?
   A: Iran, Nigeria, Pakistan, Saudi Arabia, United States

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) writes:

| I wrote
| | Note that <vector> does *not* provide all the functionality of a
| | C99 variable length array:  an N-dimensional C99 VLA is (I think?)
| | guaranteed to be stored in one contiguous piece of memory, whereas a
| | <vector> of <vector>s certainly isn't.
|
| In article <m33dizfim8.fsf@merlin.codesourcery.com>,
| Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
| >Well, actually an N-dimensional array is just a 1-dimensional array.
| >Contiguity is, therefore, not an issue.
|
| No!  On the contrary, contiguity *is* the *key* issue:

std::vector<>s are contiguous (in practice, will be required by the
the next TC).

| If I write
|  double arr[10000][10000];
| all the array elements will occupy a single contiguous piece of memory

My point is that you can have the same effect with

 std::vector<double> array(10000 * 10000);

| of size 1e8*sizeof(double), with
|  &arr[i][j] == &arr[0][0] + 10000*i + j                       (*)
| for all valid subscripts i and j.  This means that native C arrays are
| storage-compatible with (for example) Fortran arrays.  Thus I can pass
| such a C array by reference to/from (say) a Fortran program with only
| modest hassles (row- vs column-major index ordering, 0-origin vs
| usually-1-origin index semantics).

And you can't with &array[0] ?

| These statements continue to hold for C99 VLAs:  Given
|  void foo(int N, double arr[N][N])
|  { /* ... */ }
| the function  foo()  can (still) easily pass  arr  by reference to a
| Fortran program.
|
|
| In contrast, if I write
|  vector<vector<double> > mat(10000,10000)

I have always considered this as a terrible idea and a terrible
construct, and always prefered a plain 1-dimensional array.

| all the array elements will *not* occupy a single contiguous piece of
| memory of size 1e8*sizeof(double), and the subscripting law (*) will
| *not* hold.  (I give an example below.)
|
| Thus a vector-of-vectors of this type is *not* storage-compatible with
| a 2-dimensional array in (say) a Fortran program, so  mat  cannot be
| shared with (say) a Fortran program in any useful way.  (Making a
| separate copy doesn't count as "sharing" in this context: it's generally
| prohibitively inefficient in applications where large N-dimensional
| matrices are important.)

I think you missed my point.  When I said

   actually an N-dimensional array is just a 1-dimensional array.

I thought you would have understood the idiom I was referring to --
which consists in taking taking a 1-dimensional array and using classes
to maintain the illusion of higher dimensional array.  That idiom is in
the standard library and is called the valarray library.

--
Gabriel Dos Reis, gdr@codesourcery.com
CodeSourcery, LLC  http://www.codesourcery.com
       http://www.codesourcery.com/gcc-compile.shtml

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I wrote
|std::vector<>s are contiguous (in practice, will be required by the
|the next TC).
| In contrast, if I write
|  vector<vector<double> > mat(10000,10000)
| all the array elements will *not* occupy a single contiguous piece of
| memory of size 1e8*sizeof(double), and the subscripting law (*) will
| *not* hold.  (I give an example below.)
|
| Thus a vector-of-vectors of this type is *not* storage-compatible with
| a 2-dimensional array in (say) a Fortran program, so  mat  cannot be
| shared with (say) a Fortran program in any useful way.  (Making a
| separate copy doesn't count as "sharing" in this context: it's generally
| prohibitively inefficient in applications where large N-dimensional
| matrices are important.)

In article <m3u2bdziwl.fsf@merlin.codesourcery.com>,
Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
>I have always considered this as a terrible idea and a terrible
>construct, and always prefered a plain 1-dimensional array.
[[...]]
>My point is that you can have the same effect with
>
> std::vector<double> array(10000 * 10000);
>
[[...]]
>
>I thought you would have understood the idiom I was referring to --
>which consists in taking taking a 1-dimensional array and using classes
>to maintain the illusion of higher dimensional array.  That idiom is in
>the standard library and is called the valarray library.

Yes, this certainly works, indeed I routinely do it myself.  Of course,
once one has done this, there's essentially no distinction between the
nicely-wrapped-up
  std::vector<double> array(10000 * 10000);
and the nicely-wrapped-up
 double *array = new double[10000 * 10000];
since in both cases only the N-dimensional array class(es) see the raw
storage block.

But the key problems come in providing the N-dimensional indexing
semantics:  valarray itself doesn't quite do this, rather it's a primitive
 (minimally documented in standard C++ books like Stroustrup's
 3rd edition, Meyers, Lippman & Lajoie, etc)
out of which N-dimensional indexing can be built.  (It's not at all
obvious that it's the _right_ primitive for this purpose
 [most comments about valarray in the object-oriented-numerics
 mailing list seem to describe it as somewhat of "a solution
 in search of a problem", and few people report using it]
but it's certainly _a_ primitive.)

Alas,
* By the time you get all the details right, building up N-dimensional
  indexing out of valarray is tricky enough that new programmers shouldn't
  try it.  Indeed, I'd be happier if even moderately-experienced programmers
  didn't try it, either.  And not every project has a more-than-moderately-
  -experienced programmer around...
* Such N-dimensional array classes aren't in the STL or otherwise
  standardized, so each project gets to reinvent the wheel.
* But far worse, each project does indeed reinvent the wheel, and each
  project does it slightly differently, so their wheels aren't compatible.
  The result is that I can't easily pass array objects between functions
  expecting (say) TNT array objects, Blitz++ array objects, LAPACK++ array
  objects, or any of N other library's array classes.

In many ways, the use of N-dimensional arrays in C++ today is a lot like
the use of strings before the STL <string> became ubiquitous (well, almost
ubiquitous, I think Microsoft is still Marching to the Beat of a Different
Drummer):  Each project reinvents the wheel, there are some subtle details
in doing so which make it trickier than one might think, and the result
is N incompatible classes fighting it out for mindshare.

This is, to put it bluntly, a discrace.  The N-dimensional array is as
fundamental to much of numerical computing, as the string is to text
processing, and it's sad that as of late 2000, array support in C++
hasn't yet reached the level which Fortran I had in 1956, or which C99
now has brought to C.  I eagerly await the adoption of C99 VLAs into
the next revision of the C++ standard, as a major step forward in this
direction.

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "The first strike in the American Colonies was in 1776 in Philadelphia,
    when [...] carpenters demanded a 72-hour week." -- Anatole Beck

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos Reis wrote:
>
> jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) writes:
>
> | I wrote
> | | Note that <vector> does *not* provide all the functionality of a
> | | C99 variable length array:  an N-dimensional C99 VLA is (I think?)
> | | guaranteed to be stored in one contiguous piece of memory, whereas a
> | | <vector> of <vector>s certainly isn't.
> |
> | In article <m33dizfim8.fsf@merlin.codesourcery.com>,
> | Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
> | >Well, actually an N-dimensional array is just a 1-dimensional array.
> | >Contiguity is, therefore, not an issue.
> |
> | No!  On the contrary, contiguity *is* the *key* issue:
>
> std::vector<>s are contiguous (in practice, will be required by the
> the next TC).

std::vector<std::vector<T> > can't be implemented in a way that is
contiguous in the required sense.

> | If I write
> |       double arr[10000][10000];
> | all the array elements will occupy a single contiguous piece of memory
>
> My point is that you can have the same effect with
>
>         std::vector<double> array(10000 * 10000);

array[2][3] will not work at all, much less retrieve the same element as
arr[2][3].

...
> | In contrast, if I write
> |       vector<vector<double> > mat(10000,10000)
>
> I have always considered this as a terrible idea and a terrible
> construct, and always prefered a plain 1-dimensional array.

I'd prefer a language which made something like that (not that
particular thing, however) both easy to use and efficient. It does have
one advantage, however: it allows non-rectangular "arrays", which can
occasionally be useful.

...
> I thought you would have understood the idiom I was referring to --
> which consists in taking taking a 1-dimensional array and using classes
> to maintain the illusion of higher dimensional array.

You said that an N-dimensional array IS a 1-dimensional array, not that
an N-dimensional array could be emulated using a 1-dimensional array.

> ... That idiom is in
> the standard library and is called the valarray library.

And it is a clumsy idiom to use, even with valarray.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

| Gabriel Dos Reis wrote:
| >
| > jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) writes:
| >
| > | I wrote
| > | | Note that <vector> does *not* provide all the functionality of a
| > | | C99 variable length array:  an N-dimensional C99 VLA is (I think?)
| > | | guaranteed to be stored in one contiguous piece of memory, whereas a
| > | | <vector> of <vector>s certainly isn't.
| > |
| > | In article <m33dizfim8.fsf@merlin.codesourcery.com>,
| > | Gabriel Dos Reis  <gdr@codesourcery.com> wrote:
| > | >Well, actually an N-dimensional array is just a 1-dimensional array.
| > | >Contiguity is, therefore, not an issue.
| > |
| > | No!  On the contrary, contiguity *is* the *key* issue:
| >
| > std::vector<>s are contiguous (in practice, will be required by the
| > the next TC).
|
| std::vector<std::vector<T> > can't be implemented in a way that is
| contiguous in the required sense.

As I said in the message, std::vector<std::vector<T> > is a terrible
idea that I don't even dream of.

| > | If I write
| > |       double arr[10000][10000];
| > | all the array elements will occupy a single contiguous piece of memory
| >
| > My point is that you can have the same effect with
| >
| >         std::vector<double> array(10000 * 10000);
|
| array[2][3] will not work at all, much less retrieve the same element as
| arr[2][3].

Aha, syntatical considerations.  Yes, it is important.  That is why
you'll make it into a class and overlload operator().

[...]

| > I thought you would have understood the idiom I was referring to --
| > which consists in taking taking a 1-dimensional array and using classes
| > to maintain the illusion of higher dimensional array.
|
| You said that an N-dimensional array IS a 1-dimensional array, not that
| an N-dimensional array could be emulated using a 1-dimensional array.

Well, in my every day numerical computing, that is how I see
N-dimensional array -- and that is how my colleagues perceive it.  But
I forgot I was on comp.std.c++ ;-)

| > ... That idiom is in
| > the standard library and is called the valarray library.
|
| And it is a clumsy idiom to use, even with valarray.

But it does work and is easily generalizable to higher dimension.

--
Gabriel Dos Reis, gdr@codesourcery.com
CodeSourcery, LLC  http://www.codesourcery.com
       http://www.codesourcery.com/gcc-compile.shtml

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8ptvd1$jps$1@nnrp1.deja.com>,  <sirwillard@my-deja.com> wrote:
>In article <8ptokl$jni$1@panix3.panix.com>,
>  comeau@comeaucomputing.com wrote:
>> In article <gGyv5.12299$Xe4.192033@news6-win.server.ntlworld.com>,
>> >So that new additions to the C libray can be added to C++ without
>> >fear of name clashes.
>>
>> Why, did the new additions to the C library clash with the
>> previous C lib?  Why should C++ clash then?  Given that,
>> I wonder if this isn't a solution looking for a problem??
>> ... I'm just not understanding.
>
>clog is a current example, but I suppose the OP was addressing future
>changes as well?  (In case you don't know, clog is a function in C99
>found in math.h, while we know it as an iostream in C++).

I'm not saying that there is no clashes, but I think they
are minimal.

>> >It's a problem that can only get more pronounced with time.
>>
>> How?  Give a current example.  Why would it get worse or more
>> obvious in some way?
>
>The new _Complex type could have clashed with the complex template in
>C++ much worse than it does, but it's another example.

Right, as mentioned at the bottom of the message you're
responding too, I mentioned that there is no clash, at least
not in terms of a name clash.

>That said, "there ain't much we can do here, folks".  _Complex is a
>keyword in C99, and if they'd chosen to name it complex instead we
>simply couldn't have resolved this between the languages.  If the C
>standard defines a macro that clashes (like complex), well, it's going
>to clash and namespaces won't help.

Actually, if I recall, you're allowed to #undef it, and if I'm
not mistaken it's not required (although I may be misthinking
this as it applies to freestanding implementations), so even with
the macro there may be some work arounds.

>I think we've simply reached the point in time when the two languages
>are about to go down divergent paths and there won't be any way to fold
>the differences together in several cases.  In other words, we're going
>to be talking about compatibility instead of backwards compatibility
>from here on out, and there will be places in which the
>languages/libraries simply aren't compatible.

For sure.  Although some things will just be able to be rolled
into C++ with absolutely no problems, others seem to indicate
two seperate paths.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <gGyv5.12299$Xe4.192033@news6-win.server.ntlworld.com>,
Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
[[about C99 variable length arrays]]
>The extra flexibility
>with array sizes - is something some C++ compilers already provide - but is
>it useful to standardise it given we already have that kind of functionality
>from Vector? (maybe you don't want a Vector in some cases and need a genuine
>C array).

Note that <vector> does *not* provide all the functionality of a
C99 variable length array:  an N-dimensional C99 VLA is (I think?)
guaranteed to be stored in one contiguous piece of memory, whereas a
<vector> of <vector>s certainly isn't.
This can be a *big* difference performance-wise and for being able
to pass these critters back and forth to existing software (eg Fortran
libraries) which expects contiguous N-dimensional arrays.  These are
often used in contexts where "make a copy with the other storage layout"
is _not_ a viable option (eg 400 megabyte array when the machine has
512 megabytes of physical memory, etc).

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "There's a new language called C+++.  The only problem is every time
    you try to compile your modem disconnects."  - Richard Beigel


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
>
> In article <8ptvd1$jps$1@nnrp1.deja.com>,  <sirwillard@my-deja.com> wrote:
...
> >That said, "there ain't much we can do here, folks".  _Complex is a
> >keyword in C99, and if they'd chosen to name it complex instead we
> >simply couldn't have resolved this between the languages.  If the C
> >standard defines a macro that clashes (like complex), well, it's going
> >to clash and namespaces won't help.
>
> Actually, if I recall, you're allowed to #undef it, and if I'm
> not mistaken it's not required (although I may be misthinking
> this as it applies to freestanding implementations), so even with
> the macro there may be some work arounds.

A freestanding implementation is not required to support complex types.
However, a hosted one must support the _Complex and _Imaginary keywords.
If you #include <complex.h>, it must #define a macro named "complex" to
be "_Complex", and one named "imaginary" to be "_Imaginary". It must
also #define _Complex_I, _Imaginary_I, and I to be constant expressions
with an imaginary unit value of the appropriate type; it's
implementation-defined whether I expands to _Imaginary_I or _Complex_I.
Unlike most other macros defined in the C99 standard library, you have
explicit permission to #undef 'complex', 'imaginary', and 'I'.

It's complicated, but I think it achieves the intended goal: different
translation units can use 'complex' either as _Complex or as whatever
user-defined substitute for complex that they were using before C99 was
approved. Those translation units can even be linked together, as long
as they don't try to communicate with each other through interfaces
declared as 'complex'.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jthorn@galileo.thp.univie.ac.at (Jonathan Thornburg) writes:

| In article <gGyv5.12299$Xe4.192033@news6-win.server.ntlworld.com>,
| Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
| [[about C99 variable length arrays]]
| >The extra flexibility
| >with array sizes - is something some C++ compilers already provide - but is
| >it useful to standardise it given we already have that kind of functionality
| >from Vector? (maybe you don't want a Vector in some cases and need a genuine
| >C array).
|
| Note that <vector> does *not* provide all the functionality of a
| C99 variable length array:  an N-dimensional C99 VLA is (I think?)
| guaranteed to be stored in one contiguous piece of memory, whereas a
| <vector> of <vector>s certainly isn't.

Well, actually an N-dimensional array is just a 1-dimensional array.
Contiguity is, therefore, not an issue. Furthermore, you can even
define your storage policy (line major or column major) if you were to
cope with foreign languages such as Fortran or FORTRAN.

--
Gabriel Dos Reis, gdr@codesourcery.com
CodeSourcery, LLC  http://www.codesourcery.com
       http://www.codesourcery.com/gcc-compile.shtml

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
> What are reasonable precations to take so as to make C modules
> that use the new [C99] features easily portable to C++ at a later
> date should that be required?

Take a look at my list of incompatibilities between C99 and C++98,
which is almost complete, at:
  http://david.tribble.com/text/cdiffs.htm

This might help.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> It will certainly come up.  Whether anything gets done,
> in whole (no way IMO) or in part (surely parts IMO) is
> another question.

That's pretty much what I thought, but I was wondering if anyone else was
thinking that.

> >I can't help feeling it would have been better
> >if the standard C library lived in a different namespace from the
standard
> >C++ library.
>
> Why?

So that new additions to the C libray can be added to C++ without fear of
name clashes. It's a problem that can only get more pronounced with time.
A rather obvious solution would be not to use facilities that clash withn a
single translation unit, but it's the problem that namespaces are meant to
solve.

Of course there is always the question of "would you even want to have those
features" and I'm not sure about that one. How much compatilibity is useful
and how much will result in a mess? Adding the new complex number facilites
to C++ doesn't really give you anything useful apart from compatibility with
C, I suspect it would be more trouble than it's worth. The extra flexibility
with array sizes - is something some C++ compilers already provide - but is
it useful to standardise it given we already have that kind of functionality
from Vector? (maybe you don't want a Vector in some cases and need a genuine
C array). I expect there will be plenty of discussion to come.

Paul



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <gGyv5.12299$Xe4.192033@news6-win.server.ntlworld.com>,
Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
>Comeau wrote:
>> It will certainly come up.  Whether anything gets done,
>> in whole (no way IMO) or in part (surely parts IMO) is
>> another question.
>
>That's pretty much what I thought, but I was wondering
>if anyone else was thinking that.

I'm certain that there is no requirement on either committee
that I know of to do so.  So it just follows that some parts
will be incorp'd naturally, and the "unnatural" parts won't be.

>> >I can't help feeling it would have been better
>> >if the standard C library lived in a different namespace from the
>> >standard C++ library.
>>
>> Why?
>
>So that new additions to the C libray can be added to C++ without fear of
>name clashes.

Why, did the new additions to the C library clash with the
previous C lib?  Why should C++ clash then?  Given that,
I wonder if this isn't a solution looking for a problem??
... I'm just not understanding.

>It's a problem that can only get more pronounced with time.

How?  Give a current example.  Why would it get worse or more
obvious in some way?

>A rather obvious solution would be not to use facilities that clash withn a
>single translation unit, but it's the problem that namespaces are meant to
>solve.

Exactly what are the clashes that you see?  You imply that this
is just about names, so I'm unclear.

>Of course there is always the question of "would you even want to have those
>features" and I'm not sure about that one.

Right, that'll surely be one of the underlying points raised
in the debate.

>How much compatilibity is useful
>and how much will result in a mess?

Personally, I'm less concerned about a mess that whether
X, Y, or Z is necessary or not.  Clearly though, the possible
mess is an issue.

>Adding the new complex number facilites
>to C++ doesn't really give you anything useful apart from compatibility with
>C, I suspect it would be more trouble than it's worth. The extra flexibility
>with array sizes - is something some C++ compilers already provide - but is
>it useful to standardise it given we already have that kind of functionality
>from Vector? (maybe you don't want a Vector in some cases and need a genuine
>C array). I expect there will be plenty of discussion to come.

Ok, I was wondering whether you meant these things or not.
Then again, these point mostly don't support your original
premise about the C library namespace, at least as I understand
the C99 mods to C89, and seem to be on to other points about
the possible C99 features into C++.  I mean, vector<> and VLAs
can be considered redundant in some ways, but they don't
necessarily clash.  Ditto for complex<> and _Complex
(although there is the issue about the C99 complex macro).
Something such as csin() doesn't seem major, especially since
C does not support function overloading.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8ptokl$jni$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <gGyv5.12299$Xe4.192033@news6-win.server.ntlworld.com>,
> Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
> >Comeau wrote:
> >> >I can't help feeling it would have been better
> >> >if the standard C library lived in a different namespace from the
> >> >standard C++ library.
> >>
> >> Why?
> >
> >So that new additions to the C libray can be added to C++ without
fear of
> >name clashes.
>
> Why, did the new additions to the C library clash with the
> previous C lib?  Why should C++ clash then?  Given that,
> I wonder if this isn't a solution looking for a problem??
> ... I'm just not understanding.

clog is a current example, but I suppose the OP was addressing future
changes as well?  (In case you don't know, clog is a function in C99
found in math.h, while we know it as an iostream in C++).

> >It's a problem that can only get more pronounced with time.
>
> How?  Give a current example.  Why would it get worse or more
> obvious in some way?

The new _Complex type could have clashed with the complex template in
C++ much worse than it does, but it's another example.

That said, "there ain't much we can do here, folks".  _Complex is a
keyword in C99, and if they'd chosen to name it complex instead we
simply couldn't have resolved this between the languages.  If the C
standard defines a macro that clashes (like complex), well, it's going
to clash and namespaces won't help.

I think we've simply reached the point in time when the two languages
are about to go down divergent paths and there won't be any way to fold
the differences together in several cases.  In other words, we're going
to be talking about compatibility instead of backwards compatibility
from here on out, and there will be places in which the
languages/libraries simply aren't compatible.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Are there plans to reconcile some of the differences introduced between C++
and C by the new C standard ? I can't help feeling it would have been better
if the standard C library lived in a different namespace from the standard
C++ library. What are reasonable precations to take so as to make C modules
that use the new features easily portable to C++ at a later date should that
be required?

Thanks

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1Cbv5.10140$Xe4.141592@news6-win.server.ntlworld.com>,
Paul <paul.rigas@LESSSPAM.ntlworld.com> wrote:
>Are there plans to reconcile some of the differences introduced
>between C++ and C by the new C standard ?

It will certainly come up.  Whether anything gets done,
in whole (no way IMO) or in part (surely parts IMO) is
another question.

>I can't help feeling it would have been better
>if the standard C library lived in a different namespace from the standard
>C++ library.

Why?

>What are reasonable precations to take so as to make C modules
>that use the new features easily portable to C++ at a later date
>should that be required?

Well, frankly, C modules that use the new features will need
to be "portable" to C at some later date too! :)  Also, it need
not be a goal that compatibility between the two exists.  I realize
that may sound counter-intuitive, but you need to look at each
features and what their implication are.  Do you have any specific
features in mind?

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]