why does this work with Visual C++ 2005?

[Lynn McGuire]

Why does this work with Visual C++ 2005?

char buffer [10000];
void * test5 = & buffer;

I would think the compiler would give an error
on "& buffer", because "buffer" is the memory
address of the first element in the array, and
you can't get a memory address of a memory
address, there is no such thing. Note that
test5 and buffer do point to the same memory
address in the VC++ debugger after execution of
that line of code.

We do get a compiler error on:

char * test3 = & buffer;

And the following code compiles correctly:

char * test4 = & buffer [0];

The only thing i can think is the compiler
treats "& buffer" as "& buffer [0]" in the
void * case, assuming that is what the
programmer wanted.

Thanks,
Lynn

[Victor Bazarov]

On 9/30/2013 7:45 PM, Lynn McGuire wrote:
> Why does this work with Visual C++ 2005?
>
> char buffer [10000];
> void * test5 = & buffer;
>
> I would think the compiler would give an error
> on "& buffer", because "buffer" is the memory
> address of the first element in the array, and
> you can't get a memory address of a memory
> address, there is no such thing.

The name of an array *decays* into a pointer to the first element of
that array in any expression *except* &<name>, where it's the address of
the entire array. Try wrapping a template around it to find out the
type of it.

> Note that
> test5 and buffer do point to the same memory
> address in the VC++ debugger after execution of
> that line of code.

Yes, the address of the array is the same as the address of its first
element, the only thing is different is the *type* of that pointer.

Consider

char (*pb)[10000] = &buffer;

what's the type of 'pb'? Now, change the size either in the 'buffer'
declaration or here, do you get an error?

> We do get a compiler error on:
>
> char * test3 = & buffer;
>
> And the following code compiles correctly:
>
> char * test4 = & buffer [0];
>
> The only thing i can think is the compiler
> treats "& buffer" as "& buffer [0]" in the
> void * case, assuming that is what the
> programmer wanted.

Incorrect. See above.

V
--
I do not respond to top-posted replies, please don't ask

[K. Frank]

Hi Victor!

On Monday, September 30, 2013 8:53:26 PM UTC-4, Victor Bazarov wrote:
> On 9/30/2013 7:45 PM, Lynn McGuire wrote:
>
> The name of an array *decays* into a pointer to the first element of
> that array in any expression *except* &<name>, where it's the address of
> the entire array. Try wrapping a template around it to find out the
> type of it.
>

>> ...

>
> Yes, the address of the array is the same as the address of its first
> element, the only thing is different is the *type* of that pointer.
>
> Consider
>
> char (*pb)[10000] = &buffer;
>
> what's the type of 'pb'? Now, change the size either in the 'buffer'
> declaration or here, do you get an error?

> ...
>
> V

Thank you for the nice explanation.

I have a follow-up question:

I do understand that this behavior is (in part)
legacy behavior from the early days of c (maintained,
at least in part, for backward compatibility).

But if we were redesigning c++ from scratch today,
would this behavior make any sense? (Let me ask
this question under the assumption that our new c++
still supports raw arrays, and possibly supports
pointer decay.)

What, for example, would be the clearest way to
explain this to a new student of c++? I, supposedly,
actually know this stuff, and I have a hard time
keeping it straight off the top of my head.

Is this purely a wart on c++ due to backward compatibility
and the long history of c/c++? Or does it actually
make sense (at least in part) when viewed through
modern eyes?


Thanks.


K. Frank

[Gareth Owen]

"K. Frank" <kfran...@gmail.com> writes:

> Is this purely a wart on c++ due to backward compatibility and the
> long history of c/c++? Or does it actually make sense (at least in
> part) when viewed through modern eyes?

I think its a wart. I totally understand the decisions that were made,
but it'd be nice to see the deprecated in favour of std::array. I think
the C++ committees lack of interest in C99 VLAs suggest they're not keen
on them anyway (VLAs are worse, having no way to recover from OOM).

I hate almost all of C's array handling, especially the way the

typedef char typedefed_array_type[10];

breaks the type system in subtle ways. For example:

void fun(typedefed_array_type x)
{
typedefed_array_type y;

assert(sizeof(x) == sizeof(y));
}

Any type that triggers that assert is wartier than a warthog with HPV.

[James Kanze]

On Tuesday, 1 October 2013 01:53:26 UTC+1, Victor Bazarov wrote:
> On 9/30/2013 7:45 PM, Lynn McGuire wrote:

> > Why does this work with Visual C++ 2005?

> > char buffer [10000];
> > void * test5 = & buffer;

> > I would think the compiler would give an error
> > on "& buffer", because "buffer" is the memory
> > address of the first element in the array, and
> > you can't get a memory address of a memory
> > address, there is no such thing.

> The name of an array *decays* into a pointer to the first element of
> that array in any expression *except* &<name>,

Or when it's the argument of sizeof, or when it's binding to
a reference parameter, or when it's an argument of typeid, or...

And of course, by "decays", you mean that there is an implicit
conversion which is used. Which in fact has nothing to do with
the fact that the expression is the name of an array, but only
with the fact that the type of the expression is an array type.
(The name of an array always has an array type, but there are
many other ways of obtaining an array type.)

> where it's the address of
> the entire array.

Just to be clear: the name of an array is never an address: it
has an array type. And when you take the address of an array
type, you get a pointer to an array (and *not* a pointer to the
first element, which you would get if the implicit conversion
took place).

> Try wrapping a template around it to find out the
> type of it.

Just doing "typeid(&buffer).name()" should be enough.

> > Note that
> > test5 and buffer do point to the same memory
> > address in the VC++ debugger after execution of
> > that line of code.

> Yes, the address of the array is the same as the address of its first
> element, the only thing is different is the *type* of that pointer.

All data pointers convert implicitly to void*, and once it's
a void*, there's no trace of what the original type was.

> Consider

> char (*pb)[10000] = &buffer;

> what's the type of 'pb'? Now, change the size either in the 'buffer'
> declaration or here, do you get an error?

> > We do get a compiler error on:

> > char * test3 = & buffer;

> > And the following code compiles correctly:

> > char * test4 = & buffer [0];

> > The only thing i can think is the compiler
> > treats "& buffer" as "& buffer [0]" in the
> > void * case, assuming that is what the
> > programmer wanted.

Why would one think that? The only reasonable thing to think is
that &buffer is a pointer (the & operator always results in
a pointer type), but not a char*.

--
James

[James Kanze]

On Tuesday, 1 October 2013 02:18:55 UTC+1, K. Frank wrote:
> I have a follow-up question:
>
> I do understand that this behavior is (in part)
> legacy behavior from the early days of c (maintained,
> at least in part, for backward compatibility).

> But if we were redesigning c++ from scratch today,
> would this behavior make any sense?

No. When the first C++ standard was being developed, there was
a fairly large consensus that C style arrays were broken, and
there was some discussion early on as to whether to fix them,
and if so, how. In the end, it was felt that anything that
would fix them would have to go so far that it would
unacceptably break C compatibility, and that the library could
provide alternatives with the correct behavior.

> (Let me ask
> this question under the assumption that our new c++
> still supports raw arrays, and possibly supports
> pointer decay.)

> What, for example, would be the clearest way to
> explain this to a new student of c++? I, supposedly,
> actually know this stuff, and I have a hard time
> keeping it straight off the top of my head.

You don't explain it to a new student of C++. Using C style
arrays is an advanced topic, which you probably won't enter into
until you're discussing issues like order of initialization of
static variables, or optimization techniques.

> Is this purely a wart on c++ due to backward compatibility
> and the long history of c/c++? Or does it actually
> make sense (at least in part) when viewed through
> modern eyes?

It makes sense in the sense that C++ is designed to allow
calling C interfaces directly. Other than that...

--
James

[James Kanze]

On Tuesday, 1 October 2013 07:03:22 UTC+1, gwowen wrote:
> "K. Frank" <kfran...@gmail.com> writes:

> > Is this purely a wart on c++ due to backward compatibility and the
> > long history of c/c++? Or does it actually make sense (at least in
> > part) when viewed through modern eyes?

> I think its a wart. I totally understand the decisions that were made,
> but it'd be nice to see the deprecated in favour of std::array.

Except that std::array doesn't replace it in its main uses. You
can't pass an `std::array` to a C interface (you need to take
the address of it's first element explicitly), and you can't get
the compiler to calculate its dimensions from the number of
initializers.

> I think the C++ committees lack of interest in C99 VLAs
> suggest they're not keen on them anyway (VLAs are worse,
> having no way to recover from OOM).

> I hate almost all of C's array handling, especially the way the

> typedef char typedefed_array_type[10];

> breaks the type system in subtle ways.

Array types are broken in C. That's well known. But for
historical reasons, it's something we have to live with.

> For example:

> void fun(typedefed_array_type x)
> {
> typedefed_array_type y;

> assert(sizeof(x) == sizeof(y));
> }

> Any type that triggers that assert is wartier than a warthog with HPV.

But you probably wouldn't want to pass an array by value anyway.
And if you use pass by reference:

void
fun( typedefed_array_type const& x )
{
typedefed_array_type y;
assert( sizeof(x) == sizeof(y) );
}

the assert doesn't trigger. (But of course, in most cases,

typedef std::vector<char> typedefed_array_type;

would be far more appropriate. I'm not arguing that C style
arrays are a good thing. Just that we cannot deprecate them
because there is nothing else which does what they do.)

--
James

[Öö Tiib]

On Tuesday, 1 October 2013 04:18:55 UTC+3, K. Frank wrote:
> I do understand that this behavior is (in part)
> legacy behavior from the early days of c (maintained,
> at least in part, for backward compatibility).

C array has very few usages in what it does not decay into pointer so
it is broken. All of it is for legacy compatibility.

> But if we were redesigning c++ from scratch today,
> would this behavior make any sense? (Let me ask
> this question under the assumption that our new c++
> still supports raw arrays, and possibly supports
> pointer decay.)

Maybe. Depends what amount of C code we want to keep compilable with
C++ compiler. Without arrays (especially string literals) the amount
will be rather badly limited.

We can right now modify what we have. perhaps:

template < class T, size_t N > class array;

extend into that:

template < class T, size_t N = init_length()>
class array;

Where init_length() is constexpr size_t count of elements in
aggregate-initializer list or string literal initializer. It would
remove all need for C array. Such init_length() might be useful
elsewhere and make fine addition to language.

> What, for example, would be the clearest way to
> explain this to a new student of c++? I, supposedly,
> actually know this stuff, and I have a hard time
> keeping it straight off the top of my head.

When there is safer and as efficient alternative (like there is for
'malloc()', 'strdup()' etc.) then there is no much need to explain
it at all.

> Is this purely a wart on c++ due to backward compatibility
> and the long history of c/c++? Or does it actually
> make sense (at least in part) when viewed through
> modern eyes?

The pointer makes sort of sense, it is representing memory location of
object and there is need for manipulating memory locations. Its loose
semantics do not make sense, there could be easily more sophisticated
family of memory location types.

Array's eagerness of decaying into pointer makes sort of sense since
it is inefficient to pass it by value. If it did decay into pair of size
and pointer then that would make lot more sense.

[Lynn McGuire]

Thanks!

BTW, this is a subtle bug in the code in a
freeware Win32 tool of mine:
http://www.winsim.com/diskid32/diskid32.html

Lynn

[Gareth Owen]

James Kanze <james...@gmail.com> writes:

> Except that std::array doesn't replace it in its main uses. You can't
> pass an `std::array` to a C interface (you need to take the address of
> it's first element explicitly),

"You can't pass it to a C-interface - except that you can."
The need to explicitly decay to a pointer is a feature, not a bug, and
maps quite nicely onto the operate-on-iterators-not-containers idiom.

(The C decay-to-pointer can, of course, be viewed as expression of this
idiom, albeit one with a horrible warty syntax. And, yes, I do
appreciate the historical reasons why it is what it is. But that
doesn't mean I approve.

The automatic-pointer-decay in function arguments is a syntatic sugar
that confuses more often than it helps. If the function arg is really
a pointer, it is usually better for it to be declared as a pointer.
With 20-20 hindsight, the rule should've been "you can't pass an array
type to a function, you must pass its address explicitly")

> and you can't get the compiler to calculate its dimensions from the
> number of initializers.

Which is a shame, but its hardly insurmountable. And I wouldn't
describe automatic initialiser counting as one of the main uses.

In my experience, given that the automatic sizeof() information gets
lost in any translation unit not containing the initializer, arrays of
user-specified size (often a C macro) are far more common.
(C-strings are the exception, because you can always find the embedded nul).

But yes,

std::array<int,auto> arr = {3,4,5};

would be nice.

[James Kanze]

On Wednesday, 2 October 2013 07:07:58 UTC+1, gwowen wrote:
> James Kanze <james...@gmail.com> writes:

> > Except that std::array doesn't replace it in its main uses. You can't
> > pass an `std::array` to a C interface (you need to take the address of
> > it's first element explicitly),

> "You can't pass it to a C-interface - except that you can."
> The need to explicitly decay to a pointer is a feature, not a bug, and
> maps quite nicely onto the operate-on-iterators-not-containers idiom.

Actually, on rereading the specifications: `std::array<>` has
the `data` functions which are explicit, and exactly what is
needed.

> (The C decay-to-pointer can, of course, be viewed as expression of this
> idiom, albeit one with a horrible warty syntax. And, yes, I do
> appreciate the historical reasons why it is what it is. But that
> doesn't mean I approve.

> The automatic-pointer-decay in function arguments is a syntatic sugar
> that confuses more often than it helps. If the function arg is really
> a pointer, it is usually better for it to be declared as a pointer.
> With 20-20 hindsight, the rule should've been "you can't pass an array
> type to a function, you must pass its address explicitly")

I agree. And I never declare a function with an array argument;
I always use the pointer (the rare times I need it).

On the other hand, how many text books show main as
"int main( int argc, char* argv[] )", rather than
"int main( int argc, char** argv )" (which is the way I write
it). That's even how it is presented in the standard. And that
influences people.

> > and you can't get the compiler to calculate its dimensions from the
> > number of initializers.

> Which is a shame, but its hardly insurmountable. And I wouldn't
> describe automatic initialiser counting as one of the main uses.

It's the major reason I use C style arrays. (And for static
initialization, in pre-C++11 code.)

> In my experience, given that the automatic sizeof() information gets
> lost in any translation unit not containing the initializer, arrays of
> user-specified size (often a C macro) are far more common.
> (C-strings are the exception, because you can always find the embedded nul).

But translation units not containing the initializer don't see
the C style array. It's almost always in the unnamed namespace.
You don't expose things like that to the outside, you provide an
interface which uses them.

I even have a couple of class templates which depends on it:

template< typename MappedType,
typename KeyType = char const* >
struct StaticMap
{
KeyType key;
MappedType value;

class Matcher
{
public:
explicit Matcher(KeyType const& target_key)
: m_Key(target_key)
{
}

bool operator()(StaticMap const& obj) const
{
return m_Key == obj.key;
}

private:
KeyType m_Key;
};

static StaticMap const* find(StaticMap const* begin, StaticMap const* end, KeyType const& value)
{
return std::find_if(begin, end, Matcher(value));
}

template < size_t n >
static StaticMap const* find(StaticMap const (&array)[n], KeyType const& value)
{
StaticMap const* retval = find(begin(array), end(array), value);
return retval == end(array) ? nullptr : retval;
}
};

(With a partial specialization for KeyType = char const*, with
a Matcher and find functions which take std::string.) I use
this a lot for things like mapping strings to enum constants,
for example. (In which case, the actual StaticMap instance, and
the wrapper functions which use it, are machine generated.) And
the mapping works even when called from the constructor of
a static object.

> But yes,

> std::array<int,auto> arr = {3,4,5};

> would be nice.

It's also a nice solution with regards to the syntax. Making it
fit into the language is perhaps another issue, requiring
a special case. (But it's not as if the formal definition of
C++ was lacking special cases. One can argue that we already
have too many, and so we shouldn't introduce another one, but
one could also argue that given that there are so many, what's
one more or less.) Do that, and make main in C++ take a single
"std::vector<std::string> const&" argument, and we really could
do away with C style arrays.

--
James

[K. Frank]

Hello Victor and Öö!

On Tuesday, October 1, 2013 7:36:09 AM UTC-4, James Kanze wrote:
> On Tuesday, 1 October 2013 02:18:55 UTC+1, K. Frank wrote:

> ...

> > What, for example, would be the clearest way to
> > explain this to a new student of c++? I, supposedly,
> > actually know this stuff, and I have a hard time
> > keeping it straight off the top of my head.
>

> You don't explain it to a new student of C++. Using C style
> arrays is an advanced topic, which you probably won't enter into
> until you're discussing issues like order of initialization of
> static variables, or optimization techniques.

On Tuesday, October 1, 2013 8:58:03 AM UTC-4, Öö Tiib wrote:
> On Tuesday, 1 October 2013 04:18:55 UTC+3, K. Frank wrote:

> ...
> > What, for example, would be the clearest way ...

>
> When there is safer and as efficient alternative (like there is for
> 'malloc()', 'strdup()' etc.) then there is no much need to explain
> it at all.

I have to disagree with the notion -- at least in this
real world of ours -- that raw (c-style) arrays are an
advanced topic and need not (shouldn't) be taught to
beginning students.

Raw arrays are ubiquitous (whether we like it or nor),
even in pure c++ code, and I find myself hard pressed
to deem interfacing with common and conventional c code
an advanced topic.

Consider sending that new c++ student of yours off into
this real world of ours:

"Hey, Junior, we need a couple of quick patches to this
simple program of ours:

int main (int argc, char* argv[]) { ... }

Think you can do it?"

"Sorry Boss. I only know basic c++; I haven't studied
that advanced stuff yet."

I'm not trying to make light of the issue or say that
it is easy. I've thought a lot about how one might
teach c++ to a new student so that he becomes able to
work as an apprentice -- but in he real world, rather
than just in a constrained programming sandbox.

But, please, before you argue that the notion of an
apprentice c++ programmer working in the real world
is unrealistic (although please do argue so if you
believe it), consider what such a stance would be
telling someone managing and staffing a new software
project about which languages he should consider (and
rule out) for implementing his project.


Thanks.


K. Frank

[Öö Tiib]

On Thursday, 3 October 2013 20:58:15 UTC+3, K. Frank wrote:
> On Tuesday, October 1, 2013 8:58:03 AM UTC-4, Öö Tiib wrote:
> > On Tuesday, 1 October 2013 04:18:55 UTC+3, K. Frank wrote:
> > ...
> > > What, for example, would be the clearest way ...
> >
> > When there is safer and as efficient alternative (like there is for
> > 'malloc()', 'strdup()' etc.) then there is no much need to explain
> > it at all.
>
> I have to disagree with the notion -- at least in this
> real world of ours -- that raw (c-style) arrays are an
> advanced topic and need not (shouldn't) be taught to
> beginning students.
>
> Raw arrays are ubiquitous (whether we like it or nor),
> even in pure c++ code, and I find myself hard pressed
> to deem interfacing with common and conventional c code
> an advanced topic.

Raw array was difficult to use uniformly with other containers
before C++11 because 'std::begin()' and 'std::end()' were missing.
So even refactoring and replacing it with better performing container
took more changes and was more difficult.

Mostly because of that I started to avoid them in my own code after
first downloaded 'boost::array' and 'boost::scoped_array' and that
happened more than a decade ago.

What I have kept are some cases of static immutable arrays of
immutable elements in my code. That is useful idiom so either C++
array has to be extended with some sort of 'array<N,auto>' or
that idiom has still to be taught under topic of array. Any other
usages of raw arrays I suggest to replace with safer alternative
in peer reviews.

> Consider sending that new c++ student of yours off into
> this real world of ours:
>
> "Hey, Junior, we need a couple of quick patches to this
> simple program of ours:
>
> int main (int argc, char* argv[]) { ... }
>
> Think you can do it?"
>
> "Sorry Boss. I only know basic c++; I haven't studied
> that advanced stuff yet."

The 'char* argv[]' parameter is alternative syntax to declare
'char** argv'.

That is sometimes useful for indicating that the parameter 'argv' is
pointer to sequence of pointers and sometimes unfortunate because
newcomers often think that these two declarations differ somehow and
are confused.

> I'm not trying to make light of the issue or say that
> it is easy. I've thought a lot about how one might
> teach c++ to a new student so that he becomes able to
> work as an apprentice -- but in he real world, rather
> than just in a constrained programming sandbox.

Certainly we have to teach raw pointer (and so pointer to pointer)
for foreseeable future. Too lot of standard library and other
libraries have raw pointers in interface. Pointer to sequence of
elements can be first taught in context of string literal and later
in context of 'std::array' and 'std::vector' that have their
elements in sequence. Interfacing with libraries written in C *is*
advanced topic, we usually have wrappers there (like 'new' is
wrapper around 'malloc').

I repeat, if I can use C++ without raw arrays and my life has been
long time lot simpler without raw arrays then that can be taught
too and is worth to be taught, YMMV.

> But, please, before you argue that the notion of an
> apprentice c++ programmer working in the real world
> is unrealistic (although please do argue so if you
> believe it), consider what such a stance would be
> telling someone managing and staffing a new software
> project about which languages he should consider (and
> rule out) for implementing his project.

If the people leading (managing and staffing) engineering projects have
no access to enough engineering skills for to decide if to use C, Java,
C#, C++ or Objective-C teams for particular projects then the projects
most likely will fail anyway. I am sorry for such company, but what can
I do?

Similarly I can't help such leaders who have not read Fred Brooks "The
Mythical Man-Month: Essays on Software Engineering." (that was written
1975). They inevitably will remake most of the mistakes described in
that book, again, I am sorry, but what can I do? Everybody suggests
that book.

I just choose to do what I can do and not to deal with lost cases. ;)

[alf.p.s...@gmail.com]

On Tuesday, October 1, 2013 1:42:02 PM UTC+2, James Kanze wrote:
>
> Except that std::array doesn't replace it in its main uses. You
> can't pass an `std::array` to a C interface (you need to take
> the address of it's first element explicitly), and you can't get
> the compiler to calculate its dimensions from the number of
> initializers.

The latter is easy enough. However, the most natural notation for that, exemplified by the CPPX_ARRAY_VALUES macro below, causes an internal compiler error with Visual C++ 12 RC. The CPPX_DECLARE_ARRAY macro works with both Visual C++ and g++.

Disclaimer: I just wrote this code off the cuff (with the PP macro stuff mostly lifted from an old posting in comp.lang.c++), so it's not tested more than compiling it and noting that it produces the expected output.

Point: one can easily obtain array dimensions from initalizers, at the cost of using macros. :-)

[code]
#include <algorithm>
#include <array>
#include <initializer_list>
#include <stddef.h>
#include <tuple>
#include <typeinfo>

typedef ptrdiff_t Size;

#define CPPX_INVOKE( macro, args ) macro args

#define PP_ARG_N( \
_1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63,N,...) N

#define PP_RSEQ_N() \
63,62,61,60, \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9,8,7,6,5,4,3,2,1,0

#define PP_NARG_AUX( ... ) CPPX_INVOKE( PP_ARG_N, (__VA_ARGS__) )
#define PP_NARG( ... ) PP_NARG_AUX( __VA_ARGS__, PP_RSEQ_N() )

#define CPPX_DECLARE_ARRAY( name, first_value, ... ) \
std::array<decltype(first_value), 1 + PP_NARG( __VA_ARGS__ )> name = \
{ first_value, __VA_ARGS__ };

namespace cppx {
using std::array;
using std::copy;
using std::initializer_list;

template< Size n, class Item >
auto make_array( initializer_list<Item> values )
-> array<Item, n>
{
array<Item, n> result;
copy( values.begin(), values.end(), result.data() );
return result;
}
} // namespace cppx

#define CPPX_ARRAY_VALUES( first_value, ... ) \
cppx::make_array<1 + PP_NARG( __VA_ARGS__ )>( {first_value, __VA_ARGS__} )

#include <iostream>
auto main()
-> int
{
using namespace std;

CPPX_DECLARE_ARRAY( a, 1, 2, 3, 42 );
for( auto const v : a ) { cout << v << ' '; }
cout << endl;

auto const b = CPPX_ARRAY_VALUES( 10, 20, 30, 42 );
for( auto const v : b ) { cout << v << ' '; }
cout << endl;
}
[/code]

Now I noticed that Google has f**ked up their GG Usenet interface again, with the hierarchical view gone (possibly reflecting earlier bug or sabotage where they arbitrarily dropped references) and with quoted text double-spaced. I have fixed the double-spacing manually in this edit field, but when posting via Google Groups, who knows what the end result will be... :-( So, my apologies for formatting etc., in advance, however it turns out!

Cheers & hth.,

- Alf

PS: Where can one go these days for discussions with competent C++ folks? SO = Herb Schildt + troll zone, Usenet = spammy + also otherwise fouled up by Google Groups. So where? I think the technical content here should attest, to those who don't recognize me, that I'm not trolling. It's a genuine question: where?

[woodb...@gmail.com]

On Saturday, October 5, 2013 2:44:37 PM UTC-5, alf.p.s...@gmail.com wrote:

>
>

Clarity is lost when using asterisks rather than letters.
However, I ask people refrain from swearing here.

>
> Cheers & hth.,
>
> - Alf
>
> PS: Where can one go these days for discussions with competent C++ folks? SO = Herb Schildt + troll zone, Usenet = spammy + also otherwise fouled up by Google Groups. So where? I think the technical content here should attest, to those who don't recognize me, that I'm not trolling. It's a genuine question: where?

Correctional facilities? Sometimes a prisoner
gets inspired to turn his life around. I remember a
Russian guy was arrested a few years ago in the US
for stealing software from the financial firm he worked
for. Maybe he's programming now like never before.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[alf.p.s...@gmail.com]

On Sunday, October 6, 2013 12:25:59 AM UTC+2, woodb...@gmail.com wrote:
>
> Clarity is lost when using asterisks rather than letters.
>

> Brian
> Ebenezer Enterprises - In G-d we trust.

So, you prefer hyphens, not asterisks.

Still, Brian, I hope you have now got folks to try out your libraries. And that's another aspect of this modern lack-of-debating-forums and annoying multitude of mindless tweets problem. Namely, not only discussions, but where does one go these days in order to announce or get some directory of libraries?

- Alf
(as always here, somewhat perplexed)

[Chris Vine]

On Sat, 5 Oct 2013 15:25:59 -0700 (PDT)
woodb...@gmail.com wrote:
> Clarity is lost when using asterisks rather than letters.
> However, I ask people refrain from swearing here.

Bad language may or may not involve swearing, namely the invocation of
a deity for the purposes of providing either attestation, emphasis or
offence. This particular usage did not do that. With your religious
sensibilities I should have thought you would be keen to distinguish
between the two.

Why not call it bad language, and at the same time become a little less
tender about it. Using "heifer dust" instead of shit is just pathetic.

Chris

[woodb...@gmail.com]

On Saturday, October 5, 2013 6:03:24 PM UTC-5, alf.p.s...@gmail.com wrote:
> On Sunday, October 6, 2013 12:25:59 AM UTC+2, woodb...@gmail.com wrote:
>
> >
> > Clarity is lost when using asterisks rather than letters.
>
> >
> > Brian
> > Ebenezer Enterprises - In G-d we trust.
>
> So, you prefer hyphens, not asterisks.
>
>

G-d is shorthand way to say that I'm referring to
God of the Bible.

>
> Still, Brian, I hope you have now got folks to try out your libraries. And that's another aspect of this modern lack-of-debating-forums and annoying multitude of mindless tweets problem. Namely, not only discussions, but where does one go these days in order to announce or get some directory of libraries?
>
>

Thanks. I have one library and some executables.
I'm not sure but the answer may be a number of small
sites. I've wondered the same thing a few times.
I just watched a report about Reddit. I tend to
like the old school forums and haven't gotten on
Facebook, Twitter or some of those so I don't know
of any mindless tweets.

[woodb...@gmail.com]

On Sunday, October 6, 2013 8:50:40 AM UTC-5, Chris Vine wrote:

> Why not call it bad language, and at the same time become a little less
> tender about it.

I'm not sure why it matters calling it swearing or bad language.
If i don't do anything the situation may worsen.

[Leigh Johnston]

Seriously Chris you cannot reason with people who on the one hand
complain about the word "bullshit" but on other are homophobic misogynists.

/Leigh

[Leigh Johnston]

Fuck off you bigoted motherfucker with a face like a cunt.

/Leigh

[woodb...@gmail.com]

Leigh, please don't swear or use sexual slurs here.

[Leigh Johnston]

On 06/10/2013 17:32, woodb...@gmail.com wrote:
> Leigh, please don't swear or use sexual slurs here.

[Geoff]

On Sun, 6 Oct 2013 08:33:20 -0700 (PDT), woodb...@gmail.com wrote:

>G-d is shorthand way to say that I'm referring to
>God of the Bible.

How is that shorthand?
How is it shorter than God?
It's also harder to type.
Is there some prohibition against writing the word God?

The god of the bible is YHWH or Jehovah.
Also the LORD in some versions, deliberately all uppercase.

Refer to Hebrew and Greek translations of the Old Testament for the correct
reference to the god of the bible.

Your G-d shorthand shows a considerable lack of knowledge about the bible
and the name of God and when and how to use it. I also submit that you are
using the name in vain, a sin, when posting it to newsgroups. Knock it off.

[Chris Vine]

What situation? I have no problem with the old English word for
excrement, nor have most people in the real world. It is a piece of
usage which for some reason has become semi-offensive to a strange
branch of provincial mid-Western/US prurience (particularly it appears
amongst the religiously inclined). I also simply can't fathom why for
some reason you think "heifer dust" is acceptable when the more common
English usage is not. I shrug my shoulders. Perhaps you should too.
Other countries, other tastes.

Anyway this is off topic and I am not going to post any more about it.
I was just hoping to encourage you to stop complaining about it on this
newsgroup and so encouraging those who like to provoke you. You
may think you are suffering for righteousness. For others it is boring.

Chris

[Richard Damon]

I sort of hate to get into this bickering, but there IS a historical
basis for the hesitancy to spell out the name of deity. Ancient Hebrew
custom was that an item that contained the name of the deity was
considered at least somewhat holy, and therefore could not be just idly
discarded, but needed to be retired properly. This meant that scribes
would avoid casually using the name of deity, creating paper that would
need to be properly disposed of, especially if it would end up in the
hands of people who might not understand their need to do so.

[Geoff]

It is also very clear in the O.T. that God has no name: When Moses asked,
whom shall I say has sent me, God replied, "I am, that I am. Thou shall
tell them 'I am' has sent thee."

The O.T. religions hold: "The LORD is God and the LORD is One". Also an
indication that God has no name but One and only God knows it.

When Jesus refers to God he says "My Father" or "Our Father". Never a name
and never as a token/talisman like "G-d".

The New Testament declares "Be a Witness unto God in all that you do, for
no one enters the kingdom saying Lord, Lord; but by your actions only shall
you be judged."

This includes bearing false witness by declaring or demonstrating your
godliness when actually demonstrating intolerance, prejudice and hatred
toward others. This is the sin of the Pharisees and the Sadducees that most
angered Jesus in the temple and for which it was destroyed.

The Temple of God is within each person, it is not a building and it is not
for showy displays of religiosity and it is certainly not a place from
which to cast judgment upon the lives of others. If the temple is pure it
will be evident by the actions of that person toward others.

[David Brown]

"God" is a job title, not a name. Writing "God" with a capital "G" is
like writing "The President" with a capital "P" - it refers to the
particular god (or president) of your group of people, but it is still
not a name.

But just as no one would talk about /the/ "President" in an
international group like this without saying which president, of which
country, it is small-minded and assumptive to refer to "God" without
making it clear /which/ god one is talking about.

The guy should change his signature to "Ebenezer Enterprises - in my
particular personal interpretation of the God of the Christian Bible, I
trust". That would be clear, honest, and indisputable.

[Richard Damon]

On 10/6/13 4:14 PM, Geoff wrote:
>
> It is also very clear in the O.T. that God has no name: When Moses asked,
> whom shall I say has sent me, God replied, "I am, that I am. Thou shall
> tell them 'I am' has sent thee."
>
> The O.T. religions hold: "The LORD is God and the LORD is One". Also an
> indication that God has no name but One and only God knows it.
>

The Jews most definitely had a name for the deity. They used may
"naems", thought I suppose you would call them mere title. The one they
considered to be his most holy name was represented by the
Tetragrammaton, which they considered so holy it was not allowed for a
Jew to pronounce the name, but they would instead normally pronounce as
Adonai (the Hebrew word of lord), and in fact when they added the vowel
points to the scriptures, they added the vowels for Adonai to the
Tetragrammaton (which is where the pronunciation Jehovah came from). The
meaning of the Tetragrammaton appears to be something like "He who is",
which would be based on the "Name" he gave to Moses. We have no
indication that this is the Actual name of Deity, but it is what the
Jews thought, which is what matter when looking at the Jewish custom of
not writing out the Holy Name in full idly.

<snip NT argument which has no relation to the Jewish custom>

[Rosario1903]

On Sun, 06 Oct 2013 09:59:07 -0700, Geoff <ge...@invalid.invalid>
wrote:

>On Sun, 6 Oct 2013 08:33:20 -0700 (PDT), woodb...@gmail.com wrote:
>
>>G-d is shorthand way to say that I'm referring to
>>God of the Bible.
>
>How is that shorthand?
>How is it shorter than God?
>It's also harder to type.
>Is there some prohibition against writing the word God?

there is no word can define God... so that word is useless

they think the word of name define all the person too
just one word can not describe God

[Leigh Johnston]

On 07/10/2013 20:29, Rosario1903 wrote:
> On Sun, 06 Oct 2013 09:59:07 -0700, Geoff <ge...@invalid.invalid>
> wrote:
>
>> On Sun, 6 Oct 2013 08:33:20 -0700 (PDT), woodb...@gmail.com wrote:
>>
>>> G-d is shorthand way to say that I'm referring to
>>> God of the Bible.
>>
>> How is that shorthand?
>> How is it shorter than God?
>> It's also harder to type.
>> Is there some prohibition against writing the word God?
>
> there is no word can define God... so that word is useless
>
> they think the word of name define all the person too
> just one word can not describe God

Wrong, I can think of one word that describes God: "bullshit".

/Leigh

[woodb...@gmail.com]

On Monday, October 7, 2013 2:29:40 PM UTC-5, Rosario1903 wrote:
>
> there is no word can define God... so that word is useless
>
> they think the word of name define all the person too
> just one word can not describe God
>

"In the beginning was the Word, and the Word was with G-d,
and the Word was G-d. He was in the beginning with G-d.
All things came into being through Him, and apart from Him
nothing came into being that has come into being. In Him
was life, and the life was the Light of men." John 1:1-4.

Yeshua (aka Jesus) is G-d's Word.

[David Brown]

Do you /really/ think that makes any sort of sense? Or that it explains
/anything/ to other people?

You are a programmer - try to think rationally. All this is saying is
that "Word", with a capital W, is another name or title for God with a
capital G and Him with a capital H.

Or do you think so little of your god that you see this literally - that
"God" - or Jesus - is nothing more than a mere word (albeit a word no
one seems to know)?