why does this work with Visual C++ 2005?

L

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
 
V

Victor Bazarov

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
 
K

K. Frank

Hi Victor!

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
 
J

James Kanze

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.
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.
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*.
 
J

James Kanze

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...
 
J

James Kanze

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.)
 
Ö

Öö Tiib

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.
 
L

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.

where it's the said:
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

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
 
J

James Kanze

"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.
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.
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.
 
K

K. Frank

Hello Victor and Öö!

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.



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

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. ;)
 
A

alf.p.steinbach

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 costof 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;
}

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?
 
W

woodbrian77

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
 
A

alf.p.steinbach

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)
 
W

woodbrian77

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 annoyingmultitude 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.
 
W

woodbrian77

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.
 
G

Geoff

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.
 
G

Geoff

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.

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.
 
R

Rosario1903

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top