OOP (page 4)

May 24, 2004
Re: OOP
Posted by Achilleas Margaritis
in reply to Matthew
Permalink
Achilleas Margaritis
Posted in reply to Matthew
Permalink
In article <c8qa63$1iu5$1@digitaldaemon.com>, Matthew says...
>
>
>"Phill" <phill@pacific.net.au> wrote in message news:c8pimj$hve$1@digitaldaemon.com...
>>
>> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c8ns6g$1697$1@digitaldaemon.com...
>> >
>> > "Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:c8nmek$u31$1@digitaldaemon.com...
>> > >
>> > > "Walter" <newshound@digitalmars.com> wrote in message news:c8e2mb$2h8v$1@digitaldaemon.com...
>> > > >
>> > > > "Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:c8dojk$2048$1@digitaldaemon.com...
>> > > > > "Walter" <newshound@digitalmars.com> wrote in message news:c8bjdv$1eun$1@digitaldaemon.com...
>> > > > > > Someday, C++ may catch up with D <g>.
>> > > > > I send an e-mail to Bjarne Stroustrup regarding the future of C++
>> now
>> > > that
>> > > > D
>> > > > > is around the corner. He told me to leave him alone and go use D,
>> and
>> > > that
>> > > > > C++ is not gonna change anytime soon (although he said it very
>> > > politely).
>> > > > >
>> > > > > I guess some people never realize when their time is over.
>> > > >
>> > > > D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming
>> > > community.
>> > > > C++ was a great leap forward, and it practically invented generic metaprogramming.
>> > > >
>> > > > C++ isn't going away in the forseeable future. I fully expect that
>> future
>> > > > C++ standards will incorporate some of D's innovations, in an
>> analogous
>> > > way
>> > > > that C has adopted some C++ innovations. Bjarne is right, though, in suggesting that this will not happen anytime soon. The C++
>> standardization
>> > > > process is agonizingly slow (and should be, for a mature language).
>> > > >
>> > > > And, in due course, D will eventually be run over by a new upstart,
>> D++
>> > > <g>.
>> > > >
>> > > >
>> > >
>> > > But why is it such a slow process ? I myself can work for a couple of
>> hours
>> > > and produce a better C++ spec...how come these people need years to do
>> so ?
>> >
>> > Wow!
>> >
>> > Arrogance, coupled with  ...
>> >
>> > > I think some people are overhyped. With all due respect to mr
>> Stroustrup, if
>> >
>> > ... ignorance (it's Dr Stroustrup)
>> >
>> > > he can't see that C++ has major flaws that need to be fixed *yesterday*, what can I say ? Let Java dominate, then.
>> >
>> > ... and stupidity.
>> >
>> > What a package!
>> >
>> Mathew I think you forgot to mention the other feature of the package, it was wrapped in Bull S**t
>
>Well, maybe I came off a bit strong, but I fail to see how such disrespect should be tolerated.
>
>Technically Bjarne Stroustrup is a very smart man. Moreover, he is an exceedingly foresightful man - just check my latest article in this month's CUJ in June, which describes a new technique for dramatically improving the performance of string concatenation in any C++ libraries in a thoroughly safe and non-intrusive manner. This was inspired by some research I was doing for the book on another matter - user-defined cast operators (Imperfect C++, Chapter 19, if you're interested) - that caused me to read a certain part of The C++ Programming Language. That was an unconscious bit of smarts on the part of Dr Stroustrup. As for a conscious one, he told me that he did indeed foresee the merging of template and C++ cast syntax, in smart casts.
>
>Furthermore, he's a very responsive man, and invariably helpful (even if he's necessarily terse). I have had occasion to have information and encouragement from him throughout the last year or so wrt my preparation of Imperfect C++, and I can tell you he's a very nice, genuine, fellow. Given that he could potentially be receiving emails from the 3-5 million C++ programmers in the world, that's pretty good work.
>
>A bit more respect for those whose shoulders we stand upon costs nothing, and shouldn't hurt anyone's ego. Maybe when AM has invented a language that is used to implement a significant proportion of the worlds operating systems, and the software that runs on it, I'll pay more credence to his invective.
>
>-- 
>Matthew Wilson
>
>Author: "Imperfect C++", Addison-Wesley, 2004
>    (www.imperfectcplusplus.com)
>Contributing editor, C/C++ Users Journal
>    (www.synesis.com.au/articles.html#columns)
>STLSoft moderator
>    (http://www.stlsoft.org)
>
>-------------------------------------------------------------------------------
>
>"So far, C++ is the best language I've discovered to say what I want to say" -- Alex Stepanov
>
>-------------------------------------------------------------------------------
>
>

I never spoken with bad words for you, Matthew. In fact, I was deeply annoyed by your attitude (see "clear your mixins out of my aggregates")...it sounded as if the sole puprose of the D language is to fit your needs, and not to apply to millions of programmers across the globe.

With my words I wanted to stirr the pot, as well as express my question about how C++ is developed so slowly. I am not disrespecting anyone, nor I will take a chance to call you an arrogant moron, no matter how hard I want to do so.

I could develop a language, If I had the time to. The fact that I work for 8 to 12 hours a day developing real-time defense applications does not leave me any time to develop my own programming language. But that does not stop me from expressing what I desire from a good language.

Mr Stroustrup works for a University and has the time and resources to develop whatever he wants, and present it as research...Walter makes a living out of it. On the other hand, I am in a country that only recently has seen great developments in computers (and until recently, Basic was tought as a the first programming language in computer science courses!)...I did not have a choice to develop my own language, I have to work for another man's company.

Do you want to see If I can come up with many C++ improvements, in a blink of an eye, that would not break backwards compatibility anytime ? ok, here are some of them:

-strings as primitive types: new data types 'string', 'wstring', 'dstring':

string foo1;
wstring foo2;
dstring foo3;

-class properties:

class Foo {
public:
//property
property name {
public:
//getter
string operator () () const {
return m_value;
}

//setter
void operator = (string text) {
m_value = text;
}

private:
//value
string m_value;
}
}


-class partioning:


//partitioned class
class Foo {
public:
partition SomePart {
void bar() {
}
}
}


//usage
Foo foo1;
foo1.SomePart.bar() {
}



-reflection: a vtable entry which points to class data: a method table for accessing all class methods and fields.

used like:

Foo foo = new Foo;
foo.class.method("action1", 10, 20, 30);


-variants:

variant v1;

v1 = 5;
v1 = "foo";
int i = v1;


-safe variable argument lists using the variant type.

-multithreading, synchronized keyword and mutex primitive:


mutex m_mutex;

synchronized (mutex) {
<bla bla>
}


-signals and slots:

//class with signals
class MyDocument {
public:
signal renamed(string name);
}

//class with slots
class Controller {
public:
slot onDocumentRenamed(string name) {
<bla bla>
}
}


//use signals and slots
document1.renamed += controller1.onDocumentRenamed;


-a new type of file extension that would solve the problem of header/implementation files: when the compiler met such a file, it would treat as a translation unit, not expecting include files and such. It could be combined with 'import' statements, as in D, with symbol processing instead of text processing.


-garbage collection through the 'gc' attribute:

//garbage collected class
gc class Foo {
}


-make the -> and :: operators reduntant.

-add design-by-contract, as in D.

-add a 'foreach' statement.

-make 'switch' able to work on non-primive types, like strings.

-introduce strong typedefs with a new keyword.

-add delegates to object methods and functions.

-improve enums by making them strong typedefs which define a scope (as in D).

-provide versioning.

-make the 'operator' keyword optional. It does not make any difference, from the parsing point of view, to have it: the symbol tokens should be put within a known range, and then be recognized by the syntax analyser by a simple 'if token
>= TOKEN_OPERATOR_FIRST && token <= TOKEN_OPERATOR_LAST).

-provide 'and', 'or' and 'not' boolean operators, to make the language better looking.

-make the ';' after class and struct declarations optional.

-provide for registered classes: allow 'new' with class names, instead of types:

MyObject* foo = new "MyClass";

This, coupled with reflection, would make run-time plug-in management a breeze. As it is right now, the compiler already keeps class info through the 'type_info' structure.

-make cast operators optional. Why one should need 'static_cast' etc ? a simple casting, if it is between classes, could be worked out at compile time if it is static or dynamic.

-provide new types of standard length across all platforms.

-provide code splitting between different files, through usage of some keyword combinations.

-provide optional initialization of data with their default values.

-make null a keyword.

-provide strong types with ranges, like this:

strong typedef int(1..10) Index;

-provide static properties to types.

-provide compound primitives:

struct Vector {
int x;
int y;
int z;
}
s = {10, 20, 30};

-provide sequence lists:

sequence s = [1, 2, 3, 4, 5, "foo", object1];

-provide a new keyword 'function' which could make the language functional: assignment would not be allowed during 'function' calls, and calling procedures would not be allowed through functions. A function would make state change not allowed:

class Foo {
public:
function int action(Bar bar1) {
<bla bla state
}
}

-provide an 'abstract' keyword.

-provide managed state changes! Let the programmer model a variable's states, the state changes and the actions to be taken in order to change states. Then, the programmer could not accidentally make unwanted state changes, and many logical errors could be cought at compile time! and in run-time, throw exceptions when a state is violated.

-provide for error report customization. For example, instead of 'syntax error', one could say 'class Foo must not inherit from class Bar' or something like that.

-provide for data modelling like XML, but inside the language. One could than write compile-time or run-time models of data, expressing them in the simplest way possible.

How all these features break backwards compatibility ? they don't. In fact, they are nice additions which solve many issues amongst developers, improve the quality of the programs, elevate the status of the language and give it new life.

After all, D exists and has many of these capabilities, just because C++ just does not have these. If C++ had all these, D would not exist.

Hey, I've spend a couple of minutes typing this stuff into...if I looked really hard, I could add a dozen more features. And this stuff is trivially easy to incorporate into the C++ language (many of them can already be provided in the form of code), but it will make a hell of a difference to developers. But it will never be done so, because someone has decided that it should take decades of years, when in fact it could take a few months for most compiler vendors to support them.

Really wise men know how to talk with their ears, i.e. listen to everyone's opinions, even the lowly ones like me, and then rule things out based on logic and arguments. You have chosen to insult me first...what else can I say, other than you are really immature as a person.
Forums
