Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Does this allocate memory?

Reply
Thread Tools

Does this allocate memory?

 
 
Jingz
Guest
Posts: n/a
 
      07-22-2003
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. 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.

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 operator
overloading are automatically easier to maintain? I think not. They CAN
be, but care must be used, as in all programming.

-Curt


On Tue, 22 Jul 2003 16:18:48 -0400, Ron Natalie wrote:


> "Jingz" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed) ...
>
>> Yes I've seen that argument as well, it is equally contrived.

>
> It's not contrived at all. If you've never seen it, you've never
> managed a large project where more than one organization wrote parts of
> the code.
>
>> You really
>> have to bend over backwards to show how sane use of #define can be a
>> problem;

>
> I didn't bend over backwards. This stuff happens all the time. It's
> a perennial problem with Microsoft include files for example.
>
>> I'm not going to defend such a practice, nor expouse it. The point I
>> have often made when instructing junior programmers fresh out of
>> college is that many textbook problems are solutions to problems that
>> only exist in textbooks.

>
> Sorry, just because YOU have never seen the problem, doesn't mean they
> shouldn't exist. Do you advocate telling drivers to not fasten their
> seatbelts because you've never been in an accident?
>
>> "The real world" is an overused phrase, but maintainability is key.

>
> Precisely. Using C++ constructs promotes maintainability.


 
Reply With Quote
 
 
 
 
Jingz
Guest
Posts: n/a
 
      07-22-2003
> 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?


Indeed, if all you took away from my posts was "inheritance is no good"
then one of us does need to take more time and study, and its you.

-Curt

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      07-22-2003
"Jingz" <(E-Mail Removed)> wrote...
> > I really would like to see you implement polymorphism without
> > inheritance. Or is polymorphism an overrated "touchy-feely OO" as well?

>
> Would be delighted to, show me the example.


I don't think you deserve it, considering the tone you've taken.

class DrawContext;

class Window
{
set<Window*> child_windows;
public:
virtual void draw(const DrawContext&) = 0;
void addChildWindow(Window* pw)
{
child_windows.push_back(pw);
}
};

class OpenGLWindow : virtual public Window
{
void draw(const DrawContext&);
};

class ToolbarWindow : virtual public Window
{
void draw(const DrawContext&);
};

class ThreeDToolbarWindow : public ToolbarWindow, OpenGLWindow
{
...
};

class MainWindow : public Window
{
public:
MainWindow(const string&);
void draw(const DrawContext&);
};

....

class MySpecialMainWindow : public MainWindow
{
public:
MySpecialMainWindow(const string& title) :
MainWindow(title)
{
addChildWindow(new ThreeDToolbarWindow);
}
};

void Window::draw(const DrawContext& dc)
{
set<Window*>::iterator kid_it = child_windows.begin();
while (kid_it != child_windows.end())
{
(*kid_it)->draw(dc);
++kid_it;
}
}

.... Why do I bother? ...

Victor


 
Reply With Quote
 
Alexander Terekhov
Guest
Posts: n/a
 
      07-22-2003

Victor Bazarov wrote:

> ... Why do I bother? ...


http://www.uclan.ac.uk/facs/science/...ty/ppsycho.pdf
(see "fixation -> anal personality")

regards,
alexander.
 
Reply With Quote
 
Jingz
Guest
Posts: n/a
 
      07-22-2003
This is not a complete example, this is a code snippet from a larger
system that assumes this functionality is available. Since its clearly
from a very large system I don't think its feasible to show you how it
could be implemented in a far easier to maintain and less obscure way.

What am I talking about? Well, for example, everything thats important
happens as the result of a side-effect of calling "draw". Since the code
is not declarative, you have to hope the implementor thought of
everything when they wrote their piece of the class.

Since, of course, they didn't, you're going to have to go spelunking
through an endless list of header files to find the implementation, and
heaven forbid the original design was flawed, and critical information
was not passed back to a class back at layer 2 or 3. I've seen that and
its not pretty.

-Curt


On Tue, 22 Jul 2003 16:53:37 -0400, Victor Bazarov wrote:

> class DrawContext;
>
> class Window
> {
> set<Window*> child_windows;
> public:
> virtual void draw(const DrawContext&) = 0; void
> addChildWindow(Window* pw)
> {
> child_windows.push_back(pw);
> }
> };
>
> class OpenGLWindow : virtual public Window {
> void draw(const DrawContext&);
> };
>
> class ToolbarWindow : virtual public Window {
> void draw(const DrawContext&);
> };
>
> class ThreeDToolbarWindow : public ToolbarWindow, OpenGLWindow {
> ...
> };
>
> class MainWindow : public Window
> {
> public:
> MainWindow(const string&);
> void draw(const DrawContext&);
> };
>
> ...
>
> class MySpecialMainWindow : public MainWindow { public:
> MySpecialMainWindow(const string& title) :
> MainWindow(title)
> {
> addChildWindow(new ThreeDToolbarWindow);
> }
> };
>
> void Window::draw(const DrawContext& dc) {
> set<Window*>::iterator kid_it = child_windows.begin(); while (kid_it
> != child_windows.end()) {
> (*kid_it)->draw(dc);
> ++kid_it;
> }
> }
> }


 
Reply With Quote
 
Jingz
Guest
Posts: n/a
 
      07-22-2003
On Tue, 22 Jul 2003 16:28:00 -0400, Victor Bazarov wrote:

> "Jingz" <(E-Mail Removed)> wrote...
>> [...]
>> 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.
>>
>>

> 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


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

 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-22-2003
"Jingz" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) ...
> 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.


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.

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

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.

> 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

operator
> overloading are automatically easier to maintain? I think not. They CAN
> be, but care must be used, as in all programming.


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.merkerk(at)dse.nl



 
Reply With Quote
 
Jingz
Guest
Posts: n/a
 
      07-22-2003
On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:

> "Jingz" <(E-Mail Removed)> 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".

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

-Curt

 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      07-23-2003


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.

--
Karl Heinz Buchegger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      07-23-2003


Jingz wrote:
>
> On Tue, 22 Jul 2003 17:56:04 -0400, Victor Bazarov wrote:
>
> > "Jingz" <(E-Mail Removed)> 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.


--
Karl Heinz Buchegger
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Does c_str property of string class allocate memory? Alfonso Morra C++ 5 09-28-2005 07:17 AM
What does "no scheduler allocate" mean? Steve Gross Cisco 1 08-11-2004 11:36 PM
Does malloc() allocate memory only in powers of 2...? dsptechie C Programming 3 08-10-2004 05:22 AM
Does malloc() allocate memory only in powers of 2...? dsptechie C Programming 2 08-09-2004 10:54 AM
Why does new allocate more memory than there is?? Alan Gifford C++ 4 10-27-2003 10:01 AM



Advertisments