"Small C++" Anyone?

J

JohnQ

Dennis (Icarus) said:
Come up with a spec of your nice subset.
Others can come upwith theirs....
Eventually the union of those subsets would, quite likely, approach what
we
have today.

And again, maybe a language that tries to be all things to all developers is
not desireable. Some subsetting is already available in the form of compiler
switches to turn off capabilities: exceptions, templates, RTTI, etc. And I
think that is good. Perhaps if I know I will never use those things, I
should be able to get a compiler that simply does not have those things in
there. Maybe someone wants such a compiler system and source code to base
their own work upon. C++ is too big to be foundational or seminal in that
way. Having various degrees of compliance (subsetting) would make R&D in the
language and toolchain space ("the C++ family of languages") accessible to
wider audience. That last point is key I think. Think "language/toolchain
development toolkit" based upon a subset (maybe the EC++ subset) of C++.

John
 
J

JohnQ

Dennis (Icarus) said:
How about CAD software?
We use C++.

A lot of the shrink wrap gets pretty intense. I can't see doing that in a
higher level language. C++ seems like a good fit for creating shrink-wrapped
CAD software. I wouldn't consider CAD software "low level", but it's hardly
a common GUI/DB-type (say AddressBook) program. I was suggesting that higher
level programming is moving away from (or will move away from) C++ as it's
complexity increases as it should not require one to be a scientist to
create all/any software. It's valid for IT department managers to be afraid
of C++ development projects when they know their relatively simple
application could turn into one of those "C++ projects from hell" in short
order because the language feature set is so huge. What, though, if they had
"Small C++" that enabled them without requiring programmers that all have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is being
relegated to such" rather than being a "general purpose language"?
<shrug> One person's "bell/whistle" is another's essential feature.

And so C++ should include them all? I don't think anyone has actually tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on that
may show that there is no need for all the complexity all of the time. Maybe
then a nice set of compatible C++ languages would evolve out of that: C++
for IT departments, C++ for devices, and on. How a language can purport to
be "general purpose" and lob off a entire domains of development because of
extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.

John
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

JohnQ said:
And so C++ should include them all? I don't think anyone has actually
tried to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that may show that there is no need for all the complexity all of the
time. Maybe then a nice set of compatible C++ languages would evolve out
of that: C++ for IT departments, C++ for devices, and on.

You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.

Or if you think that EC++ is already an adequate subset for your tasks, just
use EC++.
 
D

dave_mikesell

You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.

Or if you think that EC++ is already an adequate subset for your tasks, just
use EC++.

That's my take as well. Also, what if you did use a sanctioned
"subset" for a project and then later requirements need something in
another "subset"? You have to integrate a different toolchain in
your development process.
 
J

JohnQ

Julián Albo said:
You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well
proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.

I am doing that, but I'm thinking ahead.

John
 
J

JohnQ

You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well
proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.

Or if you think that EC++ is already an adequate subset for your tasks,
just
use EC++.

That's my take as well. Also, what if you did use a sanctioned
"subset" for a project and then later requirements need something in
another "subset"? You have to integrate a different toolchain in
your development process."


****************+

By "subset", I mean that which has been determined to be adequate for the
domain in which it is used. Not simply, "oh I didn't use templates for this
application, so I'll never ever need them". Perhaps the subset doesn't have
C++ exceptions but rather a replacement for them at the library level (as
far fetched as that example seems). Let's say that's one thing, and then
there's another thing and another. Eventually C++ implementations begin to
look like way overkill and one wonders if it would be good to fork away from
the standard and even develop a C++ minus those unused features. Why? Well
because it's deemed decidedly better (by those who created and use the
subset+) and C++ is encumbered with backward compatibility (with itself and
C) and cannot be state of the art, while the subset users don't want to be
held back by standard concerns.

(I keep saying "subset" but I mean that there is a subset of C++ and then
some replacements for some or most of jettisoned functionality. The subset
is just the starting point. And it's not to say that the replacements for
the jettisoned functionality wouldn't be in a library or something and
therefor still be C++ compilable. At some point though, it may indeed take
on a life of its own apart from C++).

John
 
D

Dennis \(Icarus\)

JohnQ said:
A lot of the shrink wrap gets pretty intense. I can't see doing that in a
higher level language. C++ seems like a good fit for creating shrink-wrapped
CAD software. I wouldn't consider CAD software "low level", but it's hardly
a common GUI/DB-type (say AddressBook) program. I was suggesting that higher
level programming is moving away from (or will move away from) C++ as it's
complexity increases as it should not require one to be a scientist to
create all/any software. It's valid for IT department managers to be afraid
of C++ development projects when they know their relatively simple
application could turn into one of those "C++ projects from hell" in short
order because the language feature set is so huge. What, though, if they
had

Just because its there doesn't mean you have to use it.
Don't get me wrong, if you want to create another language, using C++ (or a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that all have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is being
relegated to such" rather than being a "general purpose language"?

To which I'd reply, no, since there are still lots of folks doing high level
work in C++.
And so C++ should include them all? I don't think anyone has actually tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on that
may show that there is no need for all the complexity all of the time. Maybe
then a nice set of compatible C++ languages would evolve out of that: C++
for IT departments, C++ for devices, and on. How a language can purport to
be "general purpose" and lob off a entire domains of development because of
extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.

Maybe you've said this in a message I've not read, but what exactlyis the
complexity that you find so abhorrent?
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there
I'm pretty sure a device driver writer would find generics useful as well.
Both would find strings useful.
Exception handling would be used in both arenas.

What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?

Dennis
 
D

Dennis \(Icarus\)

JohnQ said:
And again, maybe a language that tries to be all things to all developers is
not desireable. Some subsetting is already available in the form of compiler
switches to turn off capabilities: exceptions, templates, RTTI, etc. And I
think that is good. Perhaps if I know I will never use those things, I
should be able to get a compiler that simply does not have those things in
there. Maybe someone wants such a compiler system and source code to base

And, quite likely, the compiler vendor would give you the same compiler with
the swith just set to off and not have the ability to turn it on.
their own work upon. C++ is too big to be foundational or seminal in that
way. Having various degrees of compliance (subsetting) would make R&D in the
language and toolchain space ("the C++ family of languages") accessible to
wider audience. That last point is key I think. Think "language/toolchain
development toolkit" based upon a subset (maybe the EC++ subset) of C++.

So it sounds like you have what you want then.
Heck, gcc is freely available.

Dennis
 
J

JohnQ

Dennis (Icarus) said:
And, quite likely, the compiler vendor would give you the same compiler
with
the swith just set to off and not have the ability to turn it on.


So it sounds like you have what you want then.
Heck, gcc is freely available.

But you see, with all the complexity of a full ISO compiler instead of an
EC++ one, that source code and grammar is probably pretty nightmarish
(inaccessible).

John
 
J

JohnQ

Dennis (Icarus) said:
had

Just because its there doesn't mean you have to use it.

Yeah, but how do you control a wild team of C++ programmers? Also, what if
the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management skill to
embark on such a project? Well then they either job it out/get consultants,
don't do it, or use something else. That's how C++ gets pushed out of the
picture.
Don't get me wrong, if you want to create another language, using C++ (or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.


To which I'd reply, no, since there are still lots of folks doing high
level
work in C++.

A study with "market share" pie charts for various types of development
projects would be nice to have.
Maybe you've said this in a message I've not read, but what exactlyis the
complexity that you find so abhorrent?

The gargantuan project of implementing a compiler system for the language.
(I know, the thoughts in my previous post drifted a bit from that
sentiment). I just gave the "IT dept/driver" example because they seems so
removed from each other. At the hardware level, one needs a language that
lets one get close to the hardware. Does the IT programmer building a GUI
program need that or need to be concerned with all of the hardware
portability issues? (Yeah, I know, that's not "a feature" that can be
toggled, but you get my point surely).
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there

And a bunch of C++ programmers exploiting all the possibilities of templates
is a scary thought to the IT manager.
I'm pretty sure a device driver writer would find generics useful as well.
Both would find strings useful.
Exception handling would be used in both arenas.

What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?

To be determined. Perhaps some nice library can obsolete some functionality
and reduce the IT manager's control requirement and anxiety. You mentioned
templates. Templates can be exploited such that maintainability of code is
reduced. Maybe do containers the C way and turn off templates. Exceptions
would be a bit harder to eliminate: how about defining "exception" as an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it may be
plausible (?).

So if one could axe "just" templates and exceptions as easily as I wrote it,
how much easier would it be to program maintainable code?

John
 
D

dave_mikesell

Yeah, but how do you control a wild team of C++ programmers?

I'm picturing drunk programmers riding horses around in circles in the
middle of town, firing six-shooters into the air shouting "Yee-hah!" a
lot.
And a bunch of C++ programmers exploiting all the possibilities of templates
is a scary thought to the IT manager.

<snip>

Sounds like you're trying to solve the age-old problem of
undisciplined, inexperienced, less-talented development staff by
dumbing down the tools. That's always the wrong solution in my
humble opinion. Bad programmers will write bad code in any language.
And if you give them a language that "increases productivity", they'll
simply write more bad code in a shorter period of time.

Open the wallet and hire better programmers. And screen them
rigorously during the interview process. Can't tell you how many
interviews I've been on when they simply take me at my word that I
have the experience I say I have. I often ask them if they want to
ask me anything more about my experience. They just want bodies in
most IT shops, where projects are heavily date driven.

Problem is, there are too many programmers in the world writing too
much bad code. Outsourcing is just exacerbating the problem. IT
departments think a programmer is a programmer and will always hire
the cheapest. You get what you pay for. I'm guessing that's why so
much IT code I've seen in the last ten years is an unmaintainable,
brittle mess.
 
D

Dennis \(Icarus\)

JohnQ said:
Yeah, but how do you control a wild team of C++ programmers? Also, what if

Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management skill to
embark on such a project? Well then they either job it out/get consultants,
don't do it, or use something else. That's how C++ gets pushed out of the
picture.

Is C++ project management really that different from managing a Java
project?
C++ is a tool for getting a job done. For me, what I do, its the right tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.
A study with "market share" pie charts for various types of development
projects would be nice to have.

This has bar graphs, not pie charts.
http://www.infoworld.com/article/05/11/30/49FErrdevelop_1.html?s=feature
The gargantuan project of implementing a compiler system for the language.
(I know, the thoughts in my previous post drifted a bit from that
sentiment). I just gave the "IT dept/driver" example because they seems so
removed from each other. At the hardware level, one needs a language that
lets one get close to the hardware. Does the IT programmer building a GUI
program need that or need to be concerned with all of the hardware
portability issues? (Yeah, I know, that's not "a feature" that can be
toggled, but you get my point surely).

Depends on what they're doing. You can avoid hardware portability issues if
you target just one platform, regardless of language.
Still have 32-bit vs 64-bit, so if you want to lock your code to only one of
those two platforms, then you don;t have to worry about'
portability. Otherwise, you do.
If your program writes binary data that's to be read on a different platform
where byte-ordering is different, at some point it'll have
to worry about conversion.
A GUI built on an Intel system, where data is written to a file, and that
file is later read on a Motorola system...

Shortly after I graduated I was working in a data procesing center. We got a
tape from a company that used 6-bit characters, instead of the 8-bit EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do the
conversion. Ugly code.
Wouldve been much cleaner in C++.
And a bunch of C++ programmers exploiting all the possibilities of templates
is a scary thought to the IT manager.


To be determined. Perhaps some nice library can obsolete some functionality
and reduce the IT manager's control requirement and anxiety. You mentioned

Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.
templates. Templates can be exploited such that maintainability of code is
reduced. Maybe do containers the C way and turn off templates. Exceptions

And unmaintainable code can be written is just about any language.
would be a bit harder to eliminate: how about defining "exception" as an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it may be
plausible (?).

So if one could axe "just" templates and exceptions as easily as I wrote it,
how much easier would it be to program maintainable code?

Not very, if instead of using the template-based classes one had to resort
to writing the collection classes themselves.
std::vector<MyObject> Collection

Since std::vector is a standard part of the langaueg, I know immediately
what operations are available, how it can be used, etc.
MyOwnVector Collection2.

Ok, here its sometthing that may act like a collection of objects, though it
might also be a mathematical vector. If the latter, does it use floats or
doubles?
What operations are available? New hires would have to get up to speed on
the company's collection classes.
Or just use std::vector. But they use templates, which aren't in your
"small-c++".

What about operator overloading? That can lead to messy code as well.
It can also lead to very elegant code too - e.g. the IOStream operations or
if one is defining math library.

You don't have "native types" being written via one API and
classes/structures written out by another.
They can all use << amd >>.

Dennis
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

I'm picturing drunk programmers riding horses around in circles in the
middle of town, firing six-shooters into the air shouting "Yee-hah!" a
lot.

And motorcycles... and his head burning (because of so much template
metraprogramming).

And then John Wayne enter the picture saying: "Time to return to ansi Cobol,
boys".
 
J

JohnQ

Dennis (Icarus) said:
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.


Is C++ project management really that different from managing a Java
project?

Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be tough.
C++ is a tool for getting a job done. For me, what I do, its the right
tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.


This has bar graphs, not pie charts.
http://www.infoworld.com/article/05/11/30/49FErrdevelop_1.html?s=feature

Looks like C++ use is declining.
Depends on what they're doing. You can avoid hardware portability issues
if
you target just one platform, regardless of language.
Still have 32-bit vs 64-bit, so if you want to lock your code to only one
of
those two platforms, then you don;t have to worry about'
portability. Otherwise, you do.
If your program writes binary data that's to be read on a different
platform
where byte-ordering is different, at some point it'll have
to worry about conversion.
A GUI built on an Intel system, where data is written to a file, and that
file is later read on a Motorola system...

Shortly after I graduated I was working in a data procesing center. We got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do the
conversion. Ugly code.
Wouldve been much cleaner in C++.

I can't think of all the things that C++ doesn't take for granted, such as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
<shrug> sounds like the IT manager isn't managing then.

Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.

C++ is hard to learn. To manage projects where it is used, one should know
how to use it very well IMO. That may be too big of a pill to swallow for an
IT manager (or for that career path).
And unmaintainable code can be written is just about any language.

It's much easier in C++ (to write unmaintainable code)!
Not very, if instead of using the template-based classes one had to resort
to writing the collection classes themselves.

I didn't say axe the container library, just templates. Other non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.
What operations are available? New hires would have to get up to speed on
the company's collection classes.

Or the vendor's or "Small C++"''s standard library.
Or just use std::vector. But they use templates, which aren't in your
"small-c++".

That doesn't solve the problem we were trying to solve above.
What about operator overloading? That can lead to messy code as well.

Indeed! Use with caution (mostly, don't use).
It can also lead to very elegant code too - e.g. the IOStream operations
or
if one is defining math library.

For math they make a lot more sense. I haven't thought about operators in
regards to decreasing complexity of implementation. From the maintainable
code standpoint, I don't think juat that reason is enough to axe operator
overloading (Who know's, maybe that is next!).
You don't have "native types" being written via one API and
classes/structures written out by another.
They can all use << amd >>.

John
 
S

SasQ

Dnia Wed, 14 Mar 2007 16:05:54 +0000, JohnQ napisa³(a):
GUI, DB, business, application programming.

But that's not the language issue, but the libraries issue!
There are platforms which don't use graphics display. Why
should the programmer of that platform have to deal with
GUI stuff forced on him by the language itself?
Even on the platforms supporting graphics and GUI toolkits,
there are differences in supported features and graphic
capabilities, so the One True language GUI couldn't handle
all of them one way [though I think some standardization
of that domain will be helpful here].

The things you mentioned should never be the part of the
core language - external libraries are for that. The core
language is only a tool for expressing algorithms, general
concepts, program organization and stuff like that.
(As opposed to device driver or OS development).

OS/drivers developers also use libraries/system APIs.
The language had always been not enough for that.
There's usually 2 positions (not just for programming
languages): you like all the bells and whistles or
you like simply elegant. I'm the latter and C++ isn't
in the latter category.

C++ is elastic language. You can program in a low level if
you want/need, but you can also program in a high-level
with full OOP and generic programming stuff. C++ has a
features to use that nasty low-level things efficiently, but
it has also a features to hide it under the hood of elegant
and easy-to-use interfaces ;) [according to Stroustrup].
You can use only a small subset if you don't want/need all
the rest. But if you want/need - it's all there, waiting
for you ;) and you probably won't be happy if you need those
extended functionality but someone gave you a "C++ light"
version cropped to only a small subset of C++ ;J
C++ is a language which gives you a freedom of choice.
 
J

JohnQ

Dennis (Icarus) said:
tough.

So its the IT manager experience/competence level that's more important?
Thats kind of what I was thinking.

Let's see... BigCompany can either 1.) Develop departmental software with
C++ and a high-powered (read, expensive) IT manager, or 2.) Use a different
tool and omit the specialist requirement. Which are they going to choose?

It also shows Win32 as having a shrinking user base. :)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like it'll
be
in the version 2.0 of the standard.
http://www.infoworld.com/article/05/11/30/49FErrdevelop_1.html?s=feature
Now, memory leaks are a problem, surely. Though realistically any resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?

But STL requires templates and that could lead to unmaintainable code if the
manager can't keep the programmers on a leash.
And if it were more platform-specific it would be much more difficult to
move programs to different platforms when they came out.

But if it's known it won't be moving, why not use the easy-to-use language
for that platform?
Or are you not just referring to word sizes and such, but stuff like GUI
and/or databases?

No, just language-level things.
Far too extreme. Code reviews are a good, useful technique - can even find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.

Ouch, I sure wouldn't want to be the one to examine microscopically all that
template code the programmers wrote.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.

The manager needs to be able to control the product. It shouldn't be at the
whim of any/all of the programmers.
Code reviews, even on just a few projects, can provide "spot-checks".

Again, too labor intensive.
That's a personnel/management issue though.

It is with C++ because there is no way to harness it.
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.

And it takes more experience and years and therefor costs more with C++
because of all the ins and outs of it.
I dont know of any other language that has an obfuscated code contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :)

That's different: they are trying to make obfuscated code. With C++ and
templates and other features, the obfuscation is almost built-in to the
language! ;)
Microsoft had a set of non-template containers, IIRC. In order to be used
didn't they have to all deive from CObject or some such?

Have to? Why would they have to? Obviously you can make cosmic hierarchies
or not.
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their needs.

Who says "Small C++" wouldn't have generics? They just won't be so
exploitable and won't be difficult to implement.
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?

At least "C with classes". ;)
But then you're still at risk having your programmers writing obfuscated
code contest entries.

At least they won't be trained to do it and think that is good coding for
production software.

John
 
D

Dennis \(Icarus\)

JohnQ said:
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be
tough.

So its the IT manager experience/competence level that's more important?
Thats kind of what I was thinking.
Looks like C++ use is declining.

It also shows Win32 as having a shrinking user base. :)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like it'll be
in the version 2.0 of the standard.
http://www.infoworld.com/article/05/11/30/49FErrdevelop_1.html?s=feature
Now, memory leaks are a problem, surely. Though realistically any resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?

I can't think of all the things that C++ doesn't take for granted, such as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.

And if it were more platform-specific it would be much more difficult to
move programs to different platforms when they came out.
Or are you not just referring to word sizes and such, but stuff like GUI
and/or databases?
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.

Far too extreme. Code reviews are a good, useful technique - can even find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
Code reviews, even on just a few projects, can provide "spot-checks".

That's a personnel/management issue though.
C++ is hard to learn. To manage projects where it is used, one should know
how to use it very well IMO. That may be too big of a pill to swallow for an
IT manager (or for that career path).

Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
It's much easier in C++ (to write unmaintainable code)!

I dont know of any other language that has an obfuscated code contest - no,
wait, that's C.
C, without classes, overloading, or templates. :)
I didn't say axe the container library, just templates. Other non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.

Microsoft had a set of non-template containers, IIRC. In order to be used
didn't they have to all deive from CObject or some such?
And without templates being available to the programmers, it'd be difficult
for 'em to come up with their own generic classes that fit their needs.
Even if you don't trust the regular developers to handle templates, there
may be some developers responsible for developing the internal framework
that may need to create a generic class for others to use. So if templates
aren't available, then the framework couldn't be developed unless there's a
way to say
"its ok for this, but not for that" section of code.
Or the vendor's or "Small C++"''s standard library.


That doesn't solve the problem we were trying to solve above.


Indeed! Use with caution (mostly, don't use).

I approach it with a "use when needed".
If + is being overloaded, it had best clearly represent an "addition"
concept.

Lets say you have multiple heaps, and you gather memory usage stats on each
heap into a class.
A total can be represented in the same class, and two stats can be added
together

Total += HeapStats;
For math they make a lot more sense. I haven't thought about operators in
regards to decreasing complexity of implementation. From the maintainable
code standpoint, I don't think juat that reason is enough to axe operator
overloading (Who know's, maybe that is next!).

Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?

But then you're still at risk having your programmers writing obfuscated
code contest entries.

Dennis
 
I

Ian Collins

JohnQ said:
But STL requires templates and that could lead to unmaintainable code if the
manager can't keep the programmers on a leash.
Bollocks. The code has nothing to do with a manager, it should be the
domain and responsibility of the development team.Use pair programming and collective code ownership and none of this crap
is necessary.
Ouch, I sure wouldn't want to be the one to examine microscopically all that
template code the programmers wrote.


The manager needs to be able to control the product. It shouldn't be at the
whim of any/all of the programmers.
No he doesn't. He may be responsible for its delivery, but certainly
not its implementation.
Again, too labor intensive.


It is with C++ because there is no way to harness it.
What?
 

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,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top