Does this allocate memory?

[Jingz]

Re: Does this allocate memory?

On Tue, 22 Jul 2003 16:28:00 -0400, Victor Bazarov wrote:
[color=blue]
> "Jingz" <e@spam.com> wrote...[color=green]
>> [...]
>> Not to open up another can of worms, but inheritance is probobly my
>> favorite example of a good idea gone bad. Everyone agree is it can be
>> over/mis used, but I will contend that it is almost never a good idea.
>> It obscures functionality at best, at worst is is an absolutely
>> impenatrable series of tracing back multiple-inheritance spaghetti when
>> a call goes bad and needs to be debugged. 'has a' is far superior,
>> necessitating a dereference and obviating that another block of code is
>> being invoked. "is a" is almost never justified.
>>
>>[/color]
> I really would like to see you implement polymorphism without
> inheritance. Or is polymorphism an overrated "touchy-feely OO" as well?
> Would you like to try this discussion in comp.object?
>
> Nobody forces you to use any of the language features. If you think
> that 'const' is bogus, don't use it. Inheritance is no good? Live
> without it. What I don't understand is the need to "content" the
> usability of any feature. Live and let live. Or is the language too
> complex for you with all that "spaghetti" in it? Could it be that you
> just need to make an effort and simply learn it?
>
> I hope you don't see this as "over/mis used" typing.
>
> Victor[/color]

In terms of "the tone I've taken" I have been factual, substantive and
non-confrontational . You on the other hand, seem to want a simple
difference in opinion to be a personal attack against me with fairly rude
and immature innuendo.

-Curt

[Peter van Merkerk]

Re: Does this allocate memory?

"Jingz" <e@spam.com> wrote in message
news:pan.2003.0 7.22.20.38.26.2 43852.12369@spa m.com...[color=blue]
> I know I can't win, you are in quite authoritative company in terms of
> people I've argued with about programming paradigms, and I know anyone
> reading this agrees with you, not me, but I do feel compelled to stick to
> facts.
>
> Microsoft thinks defined like "BOOL" and "WORD" make sense, so I'm not
> quite sure invoking problems with their source code is credible.[/color]

The Microsoft Windows API is written for C compilers somewhere in the
eighties, they could not use C++ features. The choices they made do not
always make sense from a C++ point of view. Besides that Microsoft does not
always make the best possible technical decisions. Short macro names like
"BOOL" and "WORD" are likely to clash. The reason that they don't clash
that often in reality is that most programmers know that those names are
used in <windows.h>, so they use other names.
[color=blue]
> 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.[/color]

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

Namespaces provide a much more elegant and scalable solution for the name
clash problem than prefixes. However preprocessor symbols don't care about
namespaces. Neither prefixes nor namespaces guarantee that you won't have
name clashes, but they do diminish the change you will get one.
[color=blue]
> I certainly agree that c++ promotes code cloarity and maintainability , no
> question about it, but te fact that it can is often used as a cudgel to
> beat code with. Complicated multiple inheritance, templates, and bizzare[/color]
operator[color=blue]
> overloading are automatically easier to maintain? I think not. They CAN
> be, but care must be used, as in all programming.[/color]

I absolutely agree with the last sentence. C++ is a very powerful
programming language; in the right hands wonderful things can be done with
it, but in the wrong hands it is more like letting a monkey play with a gun.
In general I think the designers of the C++ made pragmatic decisions. Most
features in the language are there for a (good) reason, even if they don't
seem make all that much sense at first.

--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

[Jingz]

Re: Does this allocate memory?

On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:
[color=blue]
> "Jingz" <e@spam.com> wrote...[color=green]
>> [...]
>> In terms of "the tone I've taken" I have been factual [..][/color]
>
> Which part in your "inheritanc e obscures functionality at best" tirade
> is factual?
>[/color]

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

Consider now the case of m_3dWidget->someFunc(); by making it a 'has a'
reference, you pinpoint exactly where it is.

-Curt

[Karl Heinz Buchegger]

Re: Does this allocate memory?



Jingz wrote:[color=blue]
>
> [...]
>
> Thank you for your response.
>[color=green]
> >[color=darkred]
> >> 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;
> >> }
> >> }[/color]
> > Why are you using volatile for a local variable?
> >[/color]
>
> 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.[/color]

But that loops still does no work other then consuming CPU time.
An optimizer might drop them.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Karl Heinz Buchegger]

Re: Does this allocate memory?



Jingz wrote:[color=blue]
>
> On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:
>[color=green]
> > "Jingz" <e@spam.com> wrote...[color=darkred]
> >> [...]
> >> In terms of "the tone I've taken" I have been factual [..][/color]
> >
> > Which part in your "inheritanc e obscures functionality at best" tirade
> > is factual?
> >[/color]
>
> 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" .[/color]

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.


--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Fao, Sean]

Re: Does this allocate memory?


"Curt" <cNurOt@nSoPrth AarMc.com> wrote in message
news:Xns93C0684 43E718suppmcrco m@63.223.5.254. ..[color=blue]
> int main( int argn, char *argv[] )[/color]

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.
[color=blue]
> {
> for( volatile int i=0; i<constantA ; i++ );
> for( volatile int j=0; j<constantB ; j++ );
>
> return 0;
> }
>
>[/color]

[Curt]

Re: Does this allocate memory?

Karl Heinz Buchegger <kbuchegg@gasca d.at> wrote in
news:3F1E3F0E.D D4E92D@gascad.a t:
[color=blue]
>
>
> Jingz wrote:[color=green]
>>
>> [...]
>>
>> Thank you for your response.
>>[color=darkred]
>> >
>> >> 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?
>> >[/color]
>>
>> 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.[/color]
>
> But that loops still does no work other then consuming CPU time.
> An optimizer might drop them.
>[/color]

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

[tom_usenet]

Re: Does this allocate memory?

On Tue, 22 Jul 2003 13:49:30 GMT, Curt <cNurOt@nSoPrth AarMc.com>
wrote:
[color=blue]
>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;[/color]

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

extern const int constantC = 30;
[color=blue]
>
>void main()
>{
> for( int i=0; i<constantA ; i++ );
> for( int j=0; j<constantB ; j++ );
>}[/color]

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

[Curt]

Re: Does this allocate memory?

"Fao, Sean" <enceladus311@y ahoo.comI-WANT-NO-SPAM> wrote in
news:hMtTa.3$Y7 3.23521@news.ab s.net:
[color=blue]
>
> "Curt" <cNurOt@nSoPrth AarMc.com> wrote in message
> news:Xns93C0684 43E718suppmcrco m@63.223.5.254. ..[color=green]
>> int main( int argn, char *argv[] )[/color]
>
> 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.
>[/color]

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

-Curt

[Victor Bazarov]

Re: Does this allocate memory?

"Curt" <cNurOt@nSoPrth AarMc.com> wrote...[color=blue]
> "Fao, Sean" <enceladus311@y ahoo.comI-WANT-NO-SPAM> wrote in
> news:hMtTa.3$Y7 3.23521@news.ab s.net:
>[color=green]
> >
> > "Curt" <cNurOt@nSoPrth AarMc.com> wrote in message
> > news:Xns93C0684 43E718suppmcrco m@63.223.5.254. ..[color=darkred]
> >> int main( int argn, char *argv[] )[/color]
> >
> > 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.
> >[/color]
>
> I tend to think of is as "args - number" and "args - values" and have seen
> argn and argc (count, I presume) both used.[/color]

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

[Curt]

Re: Does this allocate memory?

"Peter van Merkerk" <merkerk@deadsp am.com> wrote in
news:bfkbpi$fj9 r0$1@ID-133164.news.uni-berlin.de:
[color=blue][color=green]
>>
>> Microsoft thinks defined like "BOOL" and "WORD" make sense, so I'm
>> not quite sure invoking problems with their source code is credible.[/color]
>
> The Microsoft Windows API is written for C compilers somewhere in the
> eighties, they could not use C++ features. The choices they made do[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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 shit 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.[/color]

Having worked on both, I think you are overgeneralizin g. 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

[Curt]

Re: Does this allocate memory?

Karl Heinz Buchegger <kbuchegg@gasca d.at> wrote in
news:3F1E4149.6 224C176@gascad. at:
[color=blue]
>
>
> Jingz wrote:[color=green]
>>
>> On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:
>>[color=darkred]
>> > "Jingz" <e@spam.com> wrote...
>> >> [...]
>> >> In terms of "the tone I've taken" I have been factual [..]
>> >
>> > Which part in your "inheritanc e obscures functionality at best"
>> > tirade is factual?
>> >[/color]
>>
>> 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" .[/color]
>
> 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.
>
>[/color]

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

[Ron Natalie]

Re: Does this allocate memory?


"Curt" <cNurOt@nSoPrth AarMc.com> wrote in message news:Xns93C191D C2DAE7suppmcrco m@63.223.5.254. ..
[color=blue]
> 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'.[/color]

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

[tom_usenet]

Re: Does this allocate memory?

On Wed, 23 Jul 2003 18:21:28 GMT, Curt <cNurOt@nSoPrth AarMc.com>
wrote:
[color=blue][color=green][color=darkred]
>>>const int constantA = 10;
>>>static const int constantB = 20;[/color]
>>
>> static is superfluous above - namespace scope consts are static by
>> default. Perhaps you want:
>>
>> extern const int constantC = 30;
>>[/color]
>
>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'.[/color]

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]

Re: Does this allocate memory?



Karl Heinz Buchegger wrote:[color=blue]
>
> ???
> 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.[/color]

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
kbuchegg@gascad .at