«

"Curt" <> wrote in message
news:Xns93C068443E718suppmcrcom@63.223.5.254...
> int main( int argn, char *argv[] )

This isn't wrong but I recommend that you stick to the standard argc versus
argn. On the other hand, you're not using any command line arguments passed
in the first place.

> {
> for( volatile int i=0; i<constantA ; i++ );
> for( volatile int j=0; j<constantB ; j++ );
>
> return 0;
> }
>
>

Karl Heinz Buchegger <> wrote in
news::

>
>
> Jingz wrote:
>>
>> [...]
>>
>> Thank you for your response.
>>
>> >
>> >> const int constantA = 10;
>> >> static const int constantB = 20;
>> >>
>> >> int main( int argn, char *argv[] )
>> >> {
>> >> for( volatile int i=0; i<constantA ; i++ ); for( volatile int
>> >> j=0; j<constantB ; j++ );
>> >>
>> >> return 0;
>> >> }
>> >> }
>> > Why are you using volatile for a local variable?
>> >
>>
>> Because the original responders wanted to tell me how smart they were
>> about proper c++ rather than answer the obvious question in a
>> meaningful way. So I composed an equally trivial example that would
>> force code generation.
>
> But that loops still does no work other then consuming CPU time.
> An optimizer might drop them.
>

Correct, but using 'volatile' compels the compiler to encode as written.
The point of the example has nothign to do with how the constantA/B is used
other than the fact that their address is never taken.

-Curt

On Tue, 22 Jul 2003 13:49:30 GMT, Curt <>
wrote:

>If this is the complete program (ie, the address of the const is never
>taken, only its value used) is it likely the compiler will allocate ram for
>constantA or constantB? Or simply substitute the values in (as would be
>required if I used the hideous, evil, much-abused #define
>
>-----------
>
>const int constantA = 10;
>static const int constantB = 20;

static is superfluous above - namespace scope consts are static by
default. Perhaps you want:

extern const int constantC = 30;

>
>void main()
>{
> for( int i=0; i<constantA ; i++ );
> for( int j=0; j<constantB ; j++ );
>}

Even a stupid compiler should manage to avoid allocating any static
storage for the constants, unless they are declared extern, in which
case only compilers with whole program optimization will be able to
eliminate the storage.

Tom

"Fao, Sean" <-WANT-NO-SPAM> wrote in
news:hMtTa.3$:

>
> "Curt" <> wrote in message
> news:Xns93C068443E718suppmcrcom@63.223.5.254...
>> int main( int argn, char *argv[] )
>
> This isn't wrong but I recommend that you stick to the standard argc
> versus argn. On the other hand, you're not using any command line
> arguments passed in the first place.
>

I tend to think of is as "args - number" and "args - values" and have seen
argn and argc (count, I presume) both used.

-Curt

"Curt" <> wrote...
> "Fao, Sean" <-WANT-NO-SPAM> wrote in
> news:hMtTa.3$:
>
> >
> > "Curt" <> wrote in message
> > news:Xns93C068443E718suppmcrcom@63.223.5.254...
> >> int main( int argn, char *argv[] )
> >
> > This isn't wrong but I recommend that you stick to the standard argc
> > versus argn. On the other hand, you're not using any command line
> > arguments passed in the first place.
> >
>
> I tend to think of is as "args - number" and "args - values" and have seen
> argn and argc (count, I presume) both used.

It absolutely doesn't matter how you name them. Convention to
name the first argument 'argc' and the second 'argv' is just that,
a convention.

Victor

"Peter van Merkerk" <> wrote in
news:bfkbpi$fj9r0$:

>>
>> Microsoft thinks defined like "BOOL" and "WORD" make sense, so I'm
>> not quite sure invoking problems with their source code is credible.
>
> The Microsoft Windows API is written for C compilers somewhere in the
> eighties, they could not use C++ features. The choices they made do

Yes I remember, they were wrong then and are wrong now, but chose not to
bite the bullet and re-architect when 16-bit os's were basically dead-ended
on the desktop. I said so at the time, but no one listened to me then
either

Having said that, for all the bashing, Microsoft does have some truly
brilliant programmers cranking out code, its too bad it get tainted by the
other things they do.

>> I have
>> indeed never seen a sane define collide in the manner you suggest
>> happens "all the time" but if we're going to assume insane
>> programmers then you can prety much claim anything you choose.
>
> What you say may make sense for small projects, but with large
> complicated projects the rules change. Problems that might seem
> accademic in one context, may become a very real problems in another
> context. For example if you use multiple 3rd party libraries or work
> on a large projects, name clashes are not all that uncommon. I'm not
> making this up, I'm speaking from personal experience. The usual
> workaround for these problems is using a prefix for macro names. But
> what if two 3rd party libraries have name clashes? In that case you
> are in deep **** I can tell you. Sure you can modify the header files.
> But that means maintaining your own version of that header file. Every
> time a new version of the library is released you will have to do the
> modifications again. This can become quite a headache, and therefore
> one should be extremely reluctant to do so.

Having worked on both, I think you are overgeneralizing. A large project
that has those kinds of collisions is mismanaged and has other problems.
However working with 3rd party libraries I can believe it. I have had some
experience with graphics and XML libraries in this regard, and almost
always wrap that functionality using our established coding standards. I
would be curious to see an example where such a wrapper would not solve the
name collision.

-Curt

Karl Heinz Buchegger <> wrote in
news::

>
>
> Jingz wrote:
>>
>> On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:
>>
>> > "Jingz" <> wrote...
>> >> [...]
>> >> In terms of "the tone I've taken" I have been factual [..]
>> >
>> > Which part in your "inheritance obscures functionality at best"
>> > tirade is factual?
>> >
>>
>> A call to someFunct(); that is not found in the implementation/header
>> file of the class you are on, is either global or (more probobly, in
>> a well-formed project, an inherited class)
>>
>> In order to understand that program you must now track down which
>> class its in, and in the case of multiple inheritance this can become
>> quite annoying. Of course in a codebase you are very famliar with, or
>> perhaps one you wrote yourself, this is not a big deal; in a large
>> project or in maintaining a new set of code it becomes a very big
>> deal. It also, I believe, fits a reasonable definition of
>> "obscuring".
>
> Right. And?
> That's why we are professinoals and get paid for it. If every teeny
> weeny newbie could do that we wouldn't earn our money. Building a
> rocket technically isn't very distinct from buildind a bicycle. You
> use the same tools. And yet building a rocket is incredible more
> complex then building a bike and one needs to take care of much more
> things. That's why rocket engineers earn much more money, they know
> how to do it and more importantly: they can do it.
>
>

I do agree that professionals get payed to do the job they are experts
in. Now please do not take this as personal criticism, but I firmly
believe in dumbing everything down as much as possible, so the brain-
cycles can be spent on the really difficult problems. Put too simply- if
its tedious and difficult to cut and paste text, then thats less effort
and time you can spend concentrating on the content of that text.

I prefer structures to be simple and straightforward, so the task they
are performing becomes the focus.

I will be the first to admit this may be the result of the type of work I
do, which is enormous, high-bandwidth databases, bare-metal embedded
work, and gui interfaces to them. In deference to that, I am always
looking to learn new things and not a day goes by that I don't learn
something interesting about the programming art. Its wonderful being part
of such a bottomless industry, in terms of knowledge and new experiences.

-Curt

"Curt" <> wrote in message news:Xns93C191DC2DAE7suppmcrcom@63.223.5.254...

> I should have mentioned this in the original post, but the application is
> that the const is being defined in a header file that is included in many
> translation units, and I want to make sure a new copy is not created for
> each time it is used (as would be the case using a #define) but prefer to
> use the namespace/typsafety of 'const int'.

Even in header files, consts at namespace scope are static.

On Wed, 23 Jul 2003 18:21:28 GMT, Curt <>
wrote:

>>>const int constantA = 10;
>>>static const int constantB = 20;
>>
>> static is superfluous above - namespace scope consts are static by
>> default. Perhaps you want:
>>
>> extern const int constantC = 30;
>>
>
>Thank you for your response.
>
>I should have mentioned this in the original post, but the application is
>that the const is being defined in a header file that is included in many
>translation units, and I want to make sure a new copy is not created for
>each time it is used (as would be the case using a #define) but prefer to
>use the namespace/typsafety of 'const int'.

In a header it is still static - each translation unit sees a
"different" const variable (that happens to have the same name and
value) and each translation unit can be considered separately. The
advantage of static is that the compiler doesn't have to work out that
you aren't taking the address of the const in any translation unit,
but only in the current translation unit.

Finally, one thing to be aware of is that some compilers may allocate
storage for a const if you pass it by reference in that translation
unit (to a non-inline function perhaps?) in addition to if you take
its address.

Tom

Karl Heinz Buchegger wrote:
>
> ???
> There seems to be a misconception of what volatile really does.
> In the above, volatile doesn't do, what you seem to think it does.

Apologies.
It was my fault. A few seconds after hitting 'send', I realized what you
are aming at. And it will work. You are right and I was wrong.

One more time: Apologies.

--
Karl Heinz Buchegger