No, this is not a troll, and I am not promoting Java, C-flat, D, APL, Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling points
for Java and Microsoft's Java-like pseudo-C++ are "garbage collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of C++
in comparison to the competing languages. RAII forces the programmer to
know what he or she is really doing with resources, and leads to cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory enables
many optimizations and capabilities which the other languages have to
provide by modifying the language implementation (which is more than likely
written in C++). There are plenty of programming practices which protect
against traditional buffer overrun problems, etc.
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler. It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program. The meaning and implication of static and extern
have always been nebulous to me. Only recently have I really come to
understand them.
Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays. The latter is something that Stroustrup seems to have omitted
completely from TC++PL(SE).
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/ 75  5344 
Steven T. Hatton wrote:
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me.
The cost of retaining backwards compatibility with 30+ year old tools
and techniques. New languages have the luxury of defining their own
infrastructure.
Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler.
These problems can largely be removed by the use of conditional builds,
rather than conditional compiles. A conditional build splits platform
specific code into its own compilation unit.
It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
I can't argue with that. Although in my experience the problem is rare
and once bitten one learns the symptoms.
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program.
Again, the cost of retaining backwards compatibility with 30+ year old
tools and techniques.
>
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays.
The declaration and use of pointers to members is without doubt an
abomination.
--
Ian Collins.
Ian Collins wrote:
Steven T. Hatton wrote:
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me.
The cost of retaining backwards compatibility with 30+ year old tools
and techniques. New languages have the luxury of defining their own
infrastructure.
Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler.
These problems can largely be removed by the use of conditional builds,
rather than conditional compiles. A conditional build splits platform
specific code into its own compilation unit.
It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
I can't argue with that. Although in my experience the problem is rare
and once bitten one learns the symptoms.
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program.
Again, the cost of retaining backwards compatibility with 30+ year old
tools and techniques.
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays.
The declaration and use of pointers to members is without doubt an
abomination.
--
Ian Collins.
If you dont like it you can start from scratch and build it from top to
bottom in C++... go try that in java (or wait you cant).
I like C++ and Java but they have their own purposes and uses. Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Right now the three strongest skills that company's are looking for in
a dev is: C++ (still number one), Java and C#.
Ian Collins wrote:
Steven T. Hatton wrote:
....
The declaration and use of pointers to members is without doubt an
abomination.
What is your proposed alternative ?
Signal9 wrote:
[unreferenced posting snipped]
>
If you dont like it you can start from scratch and build it from top to
bottom in C++... go try that in java (or wait you cant).
I like C++ and Java but they have their own purposes and uses. Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Right now the three strongest skills that company's are looking for in
a dev is: C++ (still number one), Java and C#.
Please trim text you are not replying to.
--
Ian Collins.
Gianni Mariani wrote:
Ian Collins wrote:
>Steven T. Hatton wrote:
....
>The declaration and use of pointers to members is without doubt an
abomination.
What is your proposed alternative ?
Abominations sometimes arise out of necessity. If I had an alternative,
I'd propose it.
--
Ian Collins.
Steven T. Hatton <ch********@germania.supwrote:
>What I found most problematic when learning C++ were, roughly in order of
significance:
>Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler. It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
>The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program. The meaning and implication of static and extern
have always been nebulous to me. Only recently have I really come to
understand them.
>Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
Seems to me that all the above issues -- Cpp, linkage, translation
units, extern, static -- are inherited from C. This has the dual
problem of (1) some aspects of these features being out of date, and
therefore not part of "good" C++, and (2) long-time C programmers
know intuitively how these things work, and so don't think much
about what problems they might cause for other programmers.
This might again be an argument for learning C first.
BTW, I like C/C++'s concept of separate translation and linkage
between translation units. It's very strong in practice.
Steve
Steven T. Hatton wrote:
No, this is not a troll, and I am not promoting Java, C-flat, D, APL, Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++.
If i recall, that teacher noted how a local company (ie: Electronic
Arts) has serious problems hiring C++ programmers (thats all they do).
Fact is: its industry, not student's preferences, that dictates what is
in fact "declining".
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler.
Syntax problems are often coder generated.
Macros should not be used in Cpp.
I find Cpp compiler diagnostics to be considerably better than most
other languages - where diagnostics are non-existant and debugging is
near impossible.
>
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program. The meaning and implication of static and extern
have always been nebulous to me. Only recently have I really come to
understand them.
Statics should be replaced by namespaces and i'll agree as far as
translation units are concerned although thats nothing unmaneageable.
>
Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays. The latter is something that Stroustrup seems to have omitted
completely from TC++PL(SE).
Take Java, for instance, where a reference is actually a naked pointer.
At least C++ gives you the option of using either ptr or ref.
Arrays and pointers should not be used except as a last resort. Most
qualified Cpp programmers are able to write thousands of lines of code
without ever needing an array and much less a dumb pointer (exception:
smart pointers).
Steven T. Hatton wrote:
No, this is not a troll, and I am not promoting Java, C-flat, D, APL, Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling points
for Java and Microsoft's Java-like pseudo-C++ are "garbage collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of C++
in comparison to the competing languages. RAII forces the programmer to
know what he or she is really doing with resources, and leads to cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory enables
many optimizations and capabilities which the other languages have to
provide by modifying the language implementation (which is more than likely
written in C++). There are plenty of programming practices which protect
against traditional buffer overrun problems, etc.
But in most other languages it's enforced while in C++ it depends on
those conventions. Where the tradeoff is.. I don't know. There isn't
one in general I think, it depends on the application.
If you have a well diciplined programming team which is working off of
a good code base, C++'s supposed weaknesses aren't. If you're handed a
legacy C app that has elements of C++ grafted on but still has pointers
out the wazoo... then I'll take memory safety please. (Unless there's a
good reason for performance needs.)
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler. It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
As someone who has been bitten by CPP crap a few times (who TF names a
macro "current"? I'm looking at you Linux kernel devs... it took me
like 20 very frustrating minutes to find out why "int current;" gave a
compile error)... I wouldn't give it up.
There have been too many times when I've used it to reduce code
duplication, or (when programming Java) said "man, I wish a had a
preprocessor".
I think there are definite improvements that could be made to the
mechanism though to reduce the "I'm stepping on your toes" effect, but
coming up with sufficently powerful mechanisms that didn't do that
would take some thought.
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions,
I gripe about this a lot. I used to say that it was inconsistent,
because poniters to functions were the only type where declarations
didn't look like <type<name>, and instead the name is in the middle
of the thing.
Just a few days ago I realized that this isn't really true: arrays also
take the same form. "int c[10];" in some sense would be better
represented, as Java and C# do it, by "int[10] c;" because c isn't an
int, it's an int array. So that really is another example of the name
(c) appearing in the middle of the type (int[10]). So function pointer
syntax isn't as... unique as I was thinking.
Though I still think that it's crap. I semi-joke that Ritchie must have
been high when he came up with that, which makes sense given the time
period.
--
This seems like as good a place as any to air my newly-developed syntax
gripes. I'm working on a C++ front end to do source-to-source
transformation, and the "print out the modified source" is fairly
buggy. It' a pain to fix because of a few things, but one of them is
that there are a bunch of special cases in C++ that you have to deal
with.
(Actually I'd appreciate any explanations if there are any reasons for
these things that I don't know about.)
1. Typename is required before dependent types, but prohibited before
non-dependent types. This means that I can't just uniformly print out
"typename" before printing the name of a type. Instead, I have to
determine whether the type I'm about to output is dependent or not.
(This is made difficult by the fact that I fully qualify names, so
something that wasn't dependent when it was parsed so isn't represented
as a dependent name can become dependent when it's printed.)
2. Elaborated names can't be used when printing explicit calls to
constructors. Again, for uniformity, Elsa always prints elaborated
names. So:
class C {};
C c;
will output with the second line reading "class C c;". But this doesn't
work in the following context:
void foo(C);
void bar() { foo( C() ); }
because the second line prints as
void bar() { foo( class C() ); }
which is not legal. Thus I have to supress printing the keyword when
printing the creation of temoraries like that.
3. Qualifiers that mark class members cannot be printed in definitions
outside of the class:
class C {
virtual void foo();
};
virtual void C::foo() { }
is not legal. (The same applies to static and explicit.)
4. Default arguments cannot be included at the definition of a
function. (This and #3 were mostly coded when I started working on the
project, but each had situations where sometimes specialized versions
of classes or members didn't supress printing the key piece of
information.)
Evan
Steven T. Hatton wrote:
No, this is not a troll, and I am not promoting Java, C-flat, D, APL,
Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling
points for Java and Microsoft's Java-like pseudo-C++ are "garbage
collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of C++
in comparison to the competing languages. RAII forces the programmer to
know what he or she is really doing with resources, and leads to cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory enables
many optimizations and capabilities which the other languages have to
provide by modifying the language implementation (which is more than
likely
written in C++). There are plenty of programming practices which protect
against traditional buffer overrun problems, etc.
What I found most problematic when learning C++ were, roughly in order of
significance:
[snip]
Ok, and here is what I dislike most about C++ in no particular order:
a) 8.3.5/5, in particular the rule about initialization of const references
and the fact that one cannot bind temporaries to non-const references.
b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for introspection
and allocation/construction of variables of that type.
c) that I cannot overload the dot operator, e.g., so that I could have smart
references or _1.member_function() in lambda.
d) that C++ doesn't have virtual member templates.
e) that my beloved templates produce error messages that fill multiple
screens.
f) that the standard is worded according to the philosophy "when in doubt,
declare the behavior undefined".
g) that the standard library components have too restrictive requirements,
e.g., list<Trequires the type T to be complete.
h) that there is no integral type or typedef guaranteed to be long enough to
hold a void*, and that there is no useful conversion to integral types for
function and member function pointers.
Here is a shorter list of minor nuisances:
A) that there is no guarantee that one can derive from standard
container/iterator classes.
B) that signed integral types make virtually no useful guarantees, and that
std::limits does not provide enough information to work around that
problem.
C) that there is no arbitrary precision / big integer class and no matrix /
tensor template in the standard.
D) that there is no window / gui support in the standard.
Best
Kai-Uwe Bux
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:el**********@murdoch.acc.Virginia.EDU...
Ok, and here is what I dislike most about C++ in no particular order:
a) 8.3.5/5, in particular the rule about initialization of const
references
and the fact that one cannot bind temporaries to non-const references.
b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for introspection
and allocation/construction of variables of that type.
c) that I cannot overload the dot operator, e.g., so that I could have
smart
references or _1.member_function() in lambda.
d) that C++ doesn't have virtual member templates.
e) that my beloved templates produce error messages that fill multiple
screens.
f) that the standard is worded according to the philosophy "when in doubt,
declare the behavior undefined".
g) that the standard library components have too restrictive requirements,
e.g., list<Trequires the type T to be complete.
h) that there is no integral type or typedef guaranteed to be long enough
to
hold a void*, and that there is no useful conversion to integral types for
function and member function pointers.
Here is a shorter list of minor nuisances:
A) that there is no guarantee that one can derive from standard
container/iterator classes.
B) that signed integral types make virtually no useful guarantees, and
that
std::limits does not provide enough information to work around that
problem.
C) that there is no arbitrary precision / big integer class and no matrix
/
tensor template in the standard.
D) that there is no window / gui support in the standard.
For me (in addition to most of your points):
A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
B) Sequence containers have an erase function that returns the next
iterator. Associative containers don't.
C) Overriding a non virtual function in a derived class, doesn't
require a diagnostic that the function is hidden.
D) A compiler is allowed to give a diagnostic in the case of C.
"Steven T. Hatton" <ch********@germania.supwrote in message
news:EY******************************@speakeasy.ne t
No, this is not a troll
Perish the thought.
The reality is that C++ is likely to be obsolete long before there is any
chance of your list of desired changes being implemented. The next version
of the standard is still years away and won't come close to addressing your
wish list. The version after that, if there is one, will be another 10 years
or so further on, and it's anyone's guess what changes might be made. The
computing environment will have changed beyond recognition before there is
any chance of the preprocessor being abolished.
So what is the point of endlessly banging on about what you don't like about
C++? Learn it, live with it, and get on with it --- or use some other
language.
--
John Carson
"Signal9" <ce****@msn.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...
Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Or instead of being a consultant of technology, be someone that can actually
build something with it. With C++, rarely do you have to look anywhere else.
All the time spent learning other languages and stuff doesn't make you as
valuable as one who can apply it to some domain, like scientific computing,
graphics/games, OLTP etc. Do survey the other stuff, but don't waste too
much time trying to learn everything and become too broad to apply anything
"professionally". (Sure, I could learn German, Spanish and Latin. But I find
English more than adequate for my purposes and I have better things to do!).
Tony
Kai-Uwe Bux wrote:
Steven T. Hatton wrote:
>No, this is not a troll, and I am not promoting Java, C-flat, D, APL,
Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling
points for Java and Microsoft's Java-like pseudo-C++ are "garbage
collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of
C++ in comparison to the competing languages. RAII forces the programmer
to know what he or she is really doing with resources, and leads to
cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory enables
many optimizations and capabilities which the other languages have to
provide by modifying the language implementation (which is more than
likely
written in C++). There are plenty of programming practices which protect
against traditional buffer overrun problems, etc.
What I found most problematic when learning C++ were, roughly in order of
significance:
[snip]
Ok, and here is what I dislike most about C++ in no particular order:
a) 8.3.5/5, in particular the rule about initialization of const
references and the fact that one cannot bind temporaries to non-const
references.
Why on Earth would you want or expect such a thing? In general temporaries
are not even guaranteed to exists. The more requirements you place on
them, the more restrictions you place on the compiler to limit
optimization.
b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for introspection
and allocation/construction of variables of that type.
That kind of thing takes a lot more infrastructure than the current model.
It would almost certainly violate the zero overhead rule. type_info is
extensible (has a virtual destructor), so you can implement your own
get_instance if you want it. Requiring that every type be default
constructible also places restrictions on the design of objects. The
functionality is really not useful enough to justify making it a
requirement for all types.
c) that I cannot overload the dot operator, e.g., so that I could have
smart references or _1.member_function() in lambda.
That has been proposed. I don't know what the status of the proposal is.
d) that C++ doesn't have virtual member templates.
How would that be useful? One of the biggest motivations for using
templates is to avoid the overhead of virtual function calls, and even of a
vtable in most cases.
e) that my beloved templates produce error messages that fill multiple
screens.
That is largely an implementation issue.
f) that the standard is worded according to the philosophy "when in doubt,
declare the behavior undefined".
Any other choice would place a requirement and/or restriction on the
implementation. For example, requiring an exception when any invalid
pointer is dereferenced would lead to extra clock cycles being spent for
every pointer access.
g) that the standard library components have too restrictive requirements,
e.g., list<Trequires the type T to be complete.
That's really a fundamental requirement of the language. list<Tis a type
which can be used to define objects. It must therefore be complete. There
are ways to use typedef to get around some of the order dependencies with
templates. What I would like are typedef templates.
h) that there is no integral type or typedef guaranteed to be long enough
to hold a void*, and that there is no useful conversion to integral types
for function and member function pointers.
Are you sure size_t does not qualify?
Here is a shorter list of minor nuisances:
A) that there is no guarantee that one can derive from standard
container/iterator classes.
What's to stop you?
B) that signed integral types make virtually no useful guarantees, and
that std::limits does not provide enough information to work around that
problem.
That has been under discussion. AAMOF, I raised that issue a long time ago
on comp.std.c++.
C) that there is no arbitrary precision / big integer class and no matrix
/ tensor template in the standard.
There are things I would want a lot more than a standard tensor. You can
implement such things without too much effort using std::valarray.
D) that there is no window / gui support in the standard.
That is not something that should be part of the core language or library.
Any given implementation would impose far too many requirements on
implementors, and would never satisfy the needs of a sufficient majority of
users to justify it. You can run X on every major platform, so you can use
any of the GUI tool kits that run under X. Qt is available for Windows,
Mac and (other) *nix. Mozilla/Netscape is written using a cross platform
widget kit, Gtk.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
If you dont like it you can start from scratch and build it from top to
bottom in C++... go try that in java (or wait you cant).
I like C++ and Java but they have their own purposes and uses. Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Right now the three strongest skills that company's are looking for in
a dev is: C++ (still number one), Java and C#
SECONDED!! c++ rox! and next comes java!!!!! (and other languages).
Steven T. Hatton wrote:
Kai-Uwe Bux wrote:
a) 8.3.5/5, in particular the rule about initialization of const
references and the fact that one cannot bind temporaries to non-const
references.
Why on Earth would you want or expect such a thing? In general temporaries
are not even guaranteed to exists. The more requirements you place on
them, the more restrictions you place on the compiler to limit
optimization.
It's still better than creating a variable to contain the value you
want to pass into the function just because you can't pass in the
literal directly.
g) that the standard library components have too restrictive requirements,
e.g., list<Trequires the type T to be complete.
That's really a fundamental requirement of the language. list<Tis a type
which can be used to define objects. It must therefore be complete.
If the template only would refer to T* or T&s, then it wouldn't have to
be complete. For instance,
class Incomplete;
template <typename T>
class List {
T* head;
};
List<Incompletelist;
I assumed that Kai-Uwe's complaint was about an example like that, in
which case it would be a "defect" IMO with the language. The problem
with that view is... the example works. GCC, ICC, and Comeau all
compile it.
There
are ways to use typedef to get around some of the order dependencies with
templates. What I would like are typedef templates.
I think there's a proposal for that too. I think that was one of the
"this is a likely addition" things in a presentation Stroustrup did a
couple years ago about C++0x.
A) that there is no guarantee that one can derive from standard
container/iterator classes.
What's to stop you?
The lack of a virtual destructor is at least fairly limiting. (I
remember hearing there's also a proposal to add versions of the STL
containers with virtual destructors.)
Evan
Duane Hebert wrote:
A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
I'm not sure this is a wart. Since since most floating reps (does the
Standard mandate IEEE-754?) use a separate sign bit, the minimum value
of a floating type is -std::limits<floating_point_type_t>::max().
red floyd wrote:
Duane Hebert wrote:
A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
I'm not sure this is a wart. Since since most floating reps (does the
Standard mandate IEEE-754?) use a separate sign bit, the minimum value
of a floating type is -std::limits<floating_point_type_t>::max().
I think the poster knows that.. what Kai-Uwe is saying is that you
can't just write std::limits::min() for the minimum value generically.
Which means that if you have a template that takes a type T and you
need to find the minimum value T can take on, you can't do it
generically, because std::limits<T>::min won't give it to you in all
cases.
It makes generic programming harder, NOT determining the minimum FP
value harder.
Evan
Steven T. Hatton wrote:
Kai-Uwe Bux wrote:
>Steven T. Hatton wrote:
>>No, this is not a troll, and I am not promoting Java, C-flat, D, APL,
Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling
points for Java and Microsoft's Java-like pseudo-C++ are "garbage
collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of
C++ in comparison to the competing languages. RAII forces the programmer
to know what he or she is really doing with resources, and leads to
cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory
enables many optimizations and capabilities which the other languages
have to provide by modifying the language implementation (which is more
than likely
written in C++). There are plenty of programming practices which
protect against traditional buffer overrun problems, etc.
What I found most problematic when learning C++ were, roughly in order
of significance:
[snip]
Ok, and here is what I dislike most about C++ in no particular order:
a) 8.3.5/5, in particular the rule about initialization of const
references and the fact that one cannot bind temporaries to non-const
references.
Why on Earth would you want or expect such a thing?
This compiles:
#include <vector>
typedef std::vector<intint_vector;
int main ( void ) {
int_vector iv ( 2000 );
int_vector().swap( iv );
}
This does not:
#include <vector>
typedef std::vector<intint_vector;
int main ( void ) {
int_vector iv ( 2000 );
iv.swap( int_vector() );
}
The consequences range from minor nuisances to more serious issues: when I
return proxy classes instead of non-const references to members, the
temporary instances of these proxy classes cannot be passed to functions
properly, which leads to absurd constructions like swap() methods that take
their parameters by value or const reference. I ran into these issues
several times.
In general
temporaries
are not even guaranteed to exists. The more requirements you place on
them, the more restrictions you place on the compiler to limit
optimization.
Those temporaries that I do not bind to references can still be optimized
away.
>b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for
introspection and allocation/construction of variables of that type.
That kind of thing takes a lot more infrastructure than the current model.
It would almost certainly violate the zero overhead rule. type_info is
extensible (has a virtual destructor), so you can implement your own
get_instance if you want it.
Nope, you can't: it lacks the protected members you would need to do that.
Requiring that every type be default
constructible also places restrictions on the design of objects. The
functionality is really not useful enough to justify making it a
requirement for all types.
1) I was not proposing that. What I meant is something like:
typeof( some_expression ) dummy;
should allocate a variable dummy if possible. There would be an exception
thrown if the type does not allow for default construction.
2) How do you know how useful this feature is. Maybe, there is a little lack
of imagination on your part.
>c) that I cannot overload the dot operator, e.g., so that I could have
smart references or _1.member_function() in lambda.
That has been proposed. I don't know what the status of the proposal is.
>d) that C++ doesn't have virtual member templates.
How would that be useful?
For instance, it can help with the double dispatch problem.
One of the biggest motivations for using
templates is to avoid the overhead of virtual function calls, and even of
a vtable in most cases.
Among my motivations for templates, this item does not even occur at all;
and I am doing template code all the time. Very likely, your statement is
made from the point of view of OO where templates may enter the picture as
an optimization hack.
>e) that my beloved templates produce error messages that fill multiple
screens.
That is largely an implementation issue.
Not really: the instantiation trace is indeed by and large necessary to
locate the error (at least there are obscure errors that you would not spot
without it). The compiler can format it nicely, but trimming the trace
correctly is probably equivalent to the halting problem.
>f) that the standard is worded according to the philosophy "when in
doubt, declare the behavior undefined".
Any other choice would place a requirement and/or restriction on the
implementation. For example, requiring an exception when any invalid
pointer is dereferenced would lead to extra clock cycles being spent for
every pointer access.
I do not complain about judicious use of undefined behavior in the language
specs. However, C++ is going overboard with it.
The particular case of unchecked pointer access I find easy to deal with: I
have a dummy smart pointer class that does nothing more than adding
debugging support, e.g., an assert in operator* and operator->. When the
assert gets defined away, there is no difference in performance but for
debugging I get my error messages.
>g) that the standard library components have too restrictive
requirements, e.g., list<Trequires the type T to be complete.
That's really a fundamental requirement of the language. list<Tis a
type
which can be used to define objects. It must therefore be complete.
Maybe you misread what I wrote. Anyway, std::list<Tcan be complete for
incomplete T. In fact, all implementations of std::list<that I know
already do this trick (except, maybe, g++ with concept checks turned on).
It's just that the standard does not make it a requirement.
There are ways to use typedef to get around some of the order dependencies
with templates.
Not this one.
What I would like are typedef templates.
Me too. And I also want partial specialization for function templates.
>h) that there is no integral type or typedef guaranteed to be long enough
to hold a void*, and that there is no useful conversion to integral types
for function and member function pointers.
Are you sure size_t does not qualify?
Yes: there is no guarantee that sizeof( void* ) <= sizeof( std::size_t ).
>Here is a shorter list of minor nuisances:
A) that there is no guarantee that one can derive from standard
container/iterator classes.
What's to stop you?
There is a trick preventing derivation (making slick use of a virtual base).
The standard makes no promise whatsoever that standard classes are not
implemented using that trick. Again, all implementations known to man allow
deriving from standard containers / iterators, and for good reasons; but
formally an implementation is allowed to reject code relying on this.
>B) that signed integral types make virtually no useful guarantees, and
that std::limits does not provide enough information to work around that
problem.
That has been under discussion. AAMOF, I raised that issue a long time
ago on comp.std.c++.
>C) that there is no arbitrary precision / big integer class and no matrix
/ tensor template in the standard.
There are things I would want a lot more than a standard tensor. You can
implement such things without too much effort using std::valarray.
If you do it "without too much effort", you get a useless toy. To do it
right requires some serious work. This is an area where performance matters
tremendously. Since there is compiler magic available to implementors that
is not available to programmers, I think, this is a good candidate for an
extension.
>D) that there is no window / gui support in the standard.
That is not something that should be part of the core language or library.
Any given implementation would impose far too many requirements on
implementors,
Nope. This just becomes a quality of implementation issue: if an implementor
is too lazy to implement the window classes, just make every constructor
throw. Then all members can be implemented as do-nothing methods. Since the
standard cannot require the existence of a screen, we have to allow for
allocation of screen resources to fail anyway.
and would never satisfy the needs of a sufficient majority
of users to justify it.
That is debatable.
You can run X on every major platform, so you can use
any of the GUI tool kits that run under X. Qt is available for Windows,
Mac and (other) *nix. Mozilla/Netscape is written using a cross platform
widget kit, Gtk.
That is a little bit missing the point: I was not complaining that there is
no window / gui support for C++. However, standardization brings more
benefits than mere existence.
Best
Kai-Uwe Bux
Evan wrote:
Steven T. Hatton wrote:
>Kai-Uwe Bux wrote:
a) 8.3.5/5, in particular the rule about initialization of const
references and the fact that one cannot bind temporaries to non-const
references.
Why on Earth would you want or expect such a thing? In general
temporaries
are not even guaranteed to exists. The more requirements you place on
them, the more restrictions you place on the compiler to limit
optimization.
It's still better than creating a variable to contain the value you
want to pass into the function just because you can't pass in the
literal directly.
g) that the standard library components have too restrictive
requirements, e.g., list<Trequires the type T to be complete.
That's really a fundamental requirement of the language. list<Tis a
type
which can be used to define objects. It must therefore be complete.
If the template only would refer to T* or T&s, then it wouldn't have to
be complete. For instance,
class Incomplete;
template <typename T>
class List {
T* head;
};
List<Incompletelist;
I assumed that Kai-Uwe's complaint was about an example like that, in
which case it would be a "defect" IMO with the language. The problem
with that view is... the example works. GCC, ICC, and Comeau all
compile it.
I am thinking of examples like this:
#include <list>
struct tricky {
std::list<trickyrecursive;
};
int main ( void ) {
tricky dummy;
}
This compiles fine with g++ and Comeau, but I can make it fail when I build
g++ with concept checks. The code is not _required_ to work and it is not
_required_ to fail.
>
> There
are ways to use typedef to get around some of the order dependencies with
templates. What I would like are typedef templates.
I think there's a proposal for that too. I think that was one of the
"this is a likely addition" things in a presentation Stroustrup did a
couple years ago about C++0x.
A) that there is no guarantee that one can derive from standard
container/iterator classes.
What's to stop you?
The lack of a virtual destructor is at least fairly limiting. (I
remember hearing there's also a proposal to add versions of the STL
containers with virtual destructors.)
The lack of a virtual destructor won't stop me. However, as far as I can
tell,
#include <vector>
class X : public std::vector<int>::iterator {};
is not _required_ to compile.
Best
Kai-Uwe Bux
Steven T. Hatton wrote:
No, this is not a troll, and I am not promoting Java, C-flat, D, APL, Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++.
Most C++ courses are utter dreck. In fact the course tutor is
usually not proficient in C++. This may account for the decline.
"Evan" <ev****@gmail.comwrote in message
news:11**********************@l12g2000cwl.googlegr oups.com...
>
red floyd wrote:
>Duane Hebert wrote:
A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write
templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
I'm not sure this is a wart. Since since most floating reps (does the
Standard mandate IEEE-754?) use a separate sign bit, the minimum value
of a floating type is -std::limits<floating_point_type_t>::max().
I think the poster knows that.. what Kai-Uwe is saying is that you
can't just write std::limits::min() for the minimum value generically.
Which means that if you have a template that takes a type T and you
need to find the minimum value T can take on, you can't do it
generically, because std::limits<T>::min won't give it to you in all
cases.
This was actually my comment, not Kai-Uwe. And yes I do
know that.
It makes generic programming harder, NOT determining the minimum FP
value harder.
I would prefer min() to always return min() and something like
::smallest() that would return what std::limits<double>::min() returns.
"red floyd" <no*****@here.dudewrote in message
news:j8******************@newssvr29.news.prodigy.n et...
Duane Hebert wrote:
>A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
I'm not sure this is a wart. Since since most floating reps (does the
Standard mandate IEEE-754?) use a separate sign bit, the minimum value
of a floating type is -std::limits<floating_point_type_t>::max().
The point is that finding the min value for a double requires
finding the max value and negating it.
-The function is different depending on the type.
-The idea that min() means something different
when talking about an int as opposed to a double is also confusing.
Sounds like a wart to me <g>
Steven T. Hatton wrote:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler. It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program. The meaning and implication of static and extern
have always been nebulous to me. Only recently have I really come to
understand them.
Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
There is work being done in the standard to improve that.
It's called `plugins'.
>
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays. The latter is something that Stroustrup seems to have omitted
completely from TC++PL(SE).
The latter is heritage from C, unfortunetely.
You could use std::array instead of arrays which are so weird.
I see nothing really problematic with functions pointers though.
Kai-Uwe Bux wrote:
a) 8.3.5/5, in particular the rule about initialization of const references
and the fact that one cannot bind temporaries to non-const references.
That makes perfectly sense though.
Why should you be allowed to modify rvalues? To help hell break loose?
b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for introspection
and allocation/construction of variables of that type.
To return useful information it would need to store them somewhere.
c) that I cannot overload the dot operator, e.g., so that I could have smart
references or _1.member_function() in lambda.
That could have been nice, indeed.
But no good way was thought of.
>
d) that C++ doesn't have virtual member templates.
This is not trivial to implement.
Implementors already had enough problems with export, so it is hard
asking for features needing collaborative work of both the compiler and
linker.
f) that the standard is worded according to the philosophy "when in doubt,
declare the behavior undefined".
You're confusing undefined and unspecified.
And it has nothing to do with doubts.
g) that the standard library components have too restrictive requirements,
e.g., list<Trequires the type T to be complete.
Variables should be perfectly workable upon declaration.
Since list<Tis a container of T's, T must be complete.
Recursive definitions do not really play well with this, indeed.
h) that there is no integral type or typedef guaranteed to be long enough to
hold a void*, and that there is no useful conversion to integral types for
function and member function pointers.
There is one in the next standard.
A) that there is no guarantee that one can derive from standard
container/iterator classes.
Of course you can.
It's just that members aren't virtual, so you can't do polymorphism with
them.
B) that signed integral types make virtually no useful guarantees, and that
std::limits does not provide enough information to work around that
problem.
C++ only allow three ways to represent signed integrals.
C) that there is no arbitrary precision / big integer class and no matrix /
tensor template in the standard.
Those are available in third party libraries.
D) that there is no window / gui support in the standard.
This is heavily platform specific.
Mathias Gaunard wrote:
Steven T. Hatton wrote:
>>
Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
There is work being done in the standard to improve that.
It's called `plugins'.
I guess that's kind of like modules with some kind of abstract linking
specification?
>>
The only aspect of the core language I really find problematic, and this
is far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays. The latter is something that Stroustrup seems to have omitted
completely from TC++PL(SE).
The latter is heritage from C, unfortunetely.
You could use std::array instead of arrays which are so weird.
Is that the same as boost::array (which may also be std::tr1::array??)? I
often use them. The truth of the matter is, if properly used, passing
arrays by reference works rather nicely with some template applications.
I see nothing really problematic with functions pointers though.
I just find the syntax less than obvious, and when I've needed to write them
myself, I had to look up the syntax. Right now, I remember how they work
because I recently look at them. In 3 months, however, I may not remember.
But, as I say, that is way down on the list of problematic features.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Signal9 wrote:
>
>The declaration and use of pointers to members is without doubt an
abomination.
If you dont like it you can start from scratch and build it from top to
bottom in C++... go try that in java (or wait you cant).
I have to agree that pointer to member syntax is goofy. OTOH, I rarely need
it, and it really does push the bounds of proper encapsulation. It's
probably a good thing that it's less than obvious.
I like C++ and Java but they have their own purposes and uses. Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn anything new
about programming languages in the past 19 years. Such a person had "one
year of experience twenty times", as he put it. Our prof suggested a
person who has exposure to many different languages will be a far better
programmer than one who has focused on only one.
I will argue that a person with one solid year of learning and working with
C++ is (with very few exceptions) a novice who is just getting started.
Right now the three strongest skills that company's are looking for in
a dev is: C++ (still number one), Java and C#.
I had a bit of exposure to C++ back before templates were considered part of
the language. I learned C fairly easily. I took one course in C and read
K&R cover to cover in a few days. Java was also fairly easy to pick up.
When I decided to learn C++ in earnest, I thought it was going to be about
as hard as Java had been. ....
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Tony wrote:
>
"Signal9" <ce****@msn.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...
>Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Or instead of being a consultant of technology, be someone that can
actually build something with it. With C++, rarely do you have to look
anywhere else. All the time spent learning other languages and stuff
doesn't make you as valuable as one who can apply it to some domain, like
scientific computing, graphics/games, OLTP etc. Do survey the other stuff,
but don't waste too much time trying to learn everything and become too
broad to apply anything "professionally". (Sure, I could learn German,
Spanish and Latin. But I find English more than adequate for my purposes
and I have better things to do!).
I don't claim any proficiency in the language, but I did find that learning
a bit of German improved my understanding of English considerably. There
are some advantages to knowing how things are done in other programming
languages. Sometimes the idioms are transferable, and sometimes you gain
an appreciation for what C++ (or whatever your primary language is) doesn't
provide, and learn ways to compensate for those limitations.
For me, I feel like I still have a lot to learn in C++. I believe I've been
exposed to every aspect of the language, but that doesn't come close to
meaning that I can use every aspect proficiently. My time is better spent
improving my C++ skills than trying to learn C#.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Gianni Mariani wrote:
Ian Collins wrote:
>Steven T. Hatton wrote:
...
>The declaration and use of pointers to members is without doubt an
abomination.
I did not write the above.
>
What is your proposed alternative ?
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Steve Pope wrote:
Seems to me that all the above issues -- Cpp, linkage, translation
units, extern, static -- are inherited from C. This has the dual
problem of (1) some aspects of these features being out of date, and
therefore not part of "good" C++, and (2) long-time C programmers
know intuitively how these things work, and so don't think much
about what problems they might cause for other programmers.
It really goes beyond knowing how Cpp works. At a certain point, any
sufficiently large project which is pasted together with a bunch of Cpp
directives and definitions will become a burden. Not only does Cpp confuse
me at times, it can confuse my tools (including Emacs). It limits the
ability to create tools that provide extensive contextual information to
the programmer, because the tools have to be able to second-guess the
values macros will take on in different situations.
This might again be an argument for learning C first.
It's not so much that Cpp was hard, in itself, to understand. What it does
to code is hard to understand.
BTW, I like C/C++'s concept of separate translation and linkage
between translation units. It's very strong in practice.
The problem really isn't the basic model. It's the 'invisibility' of it.
Things are going on behind the scenes which have no direct symbolic
representation, and lead to subtle and confusing consequences. The
situation with the const char[]s used as template parameters is a good
example.
One thing that probably made my learning experience a bit more difficult
than what most people go through is that I learned C++ on a linux box using
Emacs (and KDevelop). On a Windows box with VC++ I would probably not have
encountered many of the problems I met in trying to do everything "by
hand". I also have a tendency to use CVS builds of very thing. I'm
finally cured of doing that with GCC.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
John Carson wrote:
"Steven T. Hatton" <ch********@germania.supwrote in message
news:EY******************************@speakeasy.ne t
>No, this is not a troll
Perish the thought.
The reality is that C++ is likely to be obsolete long before there is any
chance of your list of desired changes being implemented.
Did I recommend any changes in the Standard?
The next version
of the standard is still years away and won't come close to addressing
your wish list.
The version after that, if there is one, will be another
10 years or so further on, and it's anyone's guess what changes might be
made. The computing environment will have changed beyond recognition
before there is any chance of the preprocessor being abolished.
So what is the point of endlessly banging on about what you don't like
about C++? Learn it, live with it, and get on with it --- or use some
other language.
Uh, I am investing my time in learning C++. If C++ is considered too
difficult to be worth learning, then people and projects will move to other
languages. That means my options become more limited.
The biggest problem with all of the features I mentioned is that many C++
programmers really don't care if they abuse them. They don't even
understand what that means.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Mathias Gaunard wrote:
I see nothing really problematic with functions pointers though.
Man, you guys are spending way too much time on this...
There's nothing problematic about function pointers beyond not really
being able to interchange them. The new function object being added to
the standard is a much better abstraction. Unfortunately for the OP it
uses pounds upon pounds of template magic to do so.
Evan wrote:
red floyd wrote:
>Duane Hebert wrote:
>>A) std::limits<Any integral type>::min() returns the
minimum value the type can hold but that with floating point types
it returns the smallest positive value. Makes it hard to write templates
dealing with ranges. Couldn't there be std::limits<double>::smallest ?
I'm not sure this is a wart. Since since most floating reps (does the
Standard mandate IEEE-754?) use a separate sign bit, the minimum value
of a floating type is -std::limits<floating_point_type_t>::max().
I think the poster knows that.. what Kai-Uwe is saying is that you
can't just write std::limits::min() for the minimum value generically.
Which means that if you have a template that takes a type T and you
need to find the minimum value T can take on, you can't do it
generically, because std::limits<T>::min won't give it to you in all
cases.
It makes generic programming harder, NOT determining the minimum FP
value harder.
Ah, now I see your (and Duane's) point. Good call. My mistake.
Noah Roberts wrote:
>
Mathias Gaunard wrote:
>I see nothing really problematic with functions pointers though.
Man, you guys are spending way too much time on this...
There's nothing problematic about function pointers beyond not really
being able to interchange them. The new function object being added to
the standard is a much better abstraction.
Care to provide a reference to the proposal?
Unfortunately for the OP it uses pounds upon pounds of template magic to
do so.
Anything like what is describe in Chapter 22 of _C++ Templates: The Complete
Guide_? I have to confess I haven't studied it closely.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Mathias Gaunard wrote:
Kai-Uwe Bux wrote:
>a) 8.3.5/5, in particular the rule about initialization of const
references and the fact that one cannot bind temporaries to non-const
references.
That makes perfectly sense though.
Why should you be allowed to modify rvalues?
You can already call a non-const member function of a temporary.
To help hell break loose?
No, but, e.g., to make working with proxy classes easier. Also, I just find
it silly that I can do
std::vector<int>().swap( some_int_vector );
but neither
std::swap( std::vector<int>(), some_int_vector );
nor
some_int_vector.swap( std::vector<int>() );
_Modifying_ temporaries is perfectly fine. I do it all the time. Hell does
not break loose. I do not see why _binding_ temporaries to non const
references is not fine. (I agree that there is a problem that arises from
temporaries created by automatic type conversion/promotion.)
>b) that typeid returns a by and large useless type_info object where it
could return a full-fledged type object that would allow for
introspection and allocation/construction of variables of that type.
To return useful information it would need to store them somewhere.
True. However, this information could be optimized away by the compiler if
global data flow analysis reveals that it's not used anywhere in the
compilation unit.
>
>c) that I cannot overload the dot operator, e.g., so that I could have
smart references or _1.member_function() in lambda.
That could have been nice, indeed.
But no good way was thought of.
Sad but true.
>>
d) that C++ doesn't have virtual member templates.
This is not trivial to implement.
Implementors already had enough problems with export, so it is hard
asking for features needing collaborative work of both the compiler and
linker.
I know, it's tricky. Nonetheless, I'd love to have them.
>f) that the standard is worded according to the philosophy "when in
doubt, declare the behavior undefined".
You're confusing undefined and unspecified.
I don't think so.
And it has nothing to do with doubts.
That, maybe.
>g) that the standard library components have too restrictive
requirements, e.g., list<Trequires the type T to be complete.
Variables should be perfectly workable upon declaration.
Since list<Tis a container of T's, T must be complete.
Recursive definitions do not really play well with this, indeed.
Well, the following compiles and works as expected with g++ (and I would
predict with most STL implementation):
#include <iostream>
#include <iterator>
#include <algorithm>
#include <list>
class recursive_list {
std::list< recursive_list the_list;
public:
friend
std::ostream & operator<< ( std::ostream & o_str,
recursive_list const & rl ) {
if ( rl.the_list.empty() ) {
o_str << "[]";
} else {
o_str << "[ ";
std::copy ( rl.the_list.begin(),
rl.the_list.end(),
std::ostream_iterator<recursive_list>
( std::cout, " " ) );
o_str << "]";
}
return ( o_str );
}
void push_back ( recursive_list const & rl ) {
the_list.push_back( rl );
}
};
int main ( void ) {
recursive_list const empty_list;
recursive_list r1;
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( r1 );
r1.push_back( empty_list );
r1.push_back( empty_list );
r1.push_back( empty_list );
std::cout << r1 << '\n';
}
Intended output: [ [] [] [] [ [] [] [] ] [] [] [] ]
So it is possible (and already usual) to implement std::list<the way I
would like. However, the code above has undefined behavior according to the
standard and is not even required to compile (but is permitted to): and
indeed, the code fails to compile when I build g++ with concept_checks
enabled.
>h) that there is no integral type or typedef guaranteed to be long enough
to hold a void*, and that there is no useful conversion to integral types
for function and member function pointers.
There is one in the next standard.
That's good to know.
>A) that there is no guarantee that one can derive from standard
container/iterator classes.
Of course you can.
It's just that members aren't virtual, so you can't do polymorphism with
them.
You can in all implementations that I have seen so far, yet there is no
guarantee in the standard. The type std::vector<T>::iterator is marked as
implementation defined: (a) it could be T* or (b) it could use a virtual
base trick to prevent derivation. At least the second point goes for all
iterator types. With regard to the container classes, I might be paranoid
in thinking that they could legally prevent derivation.
>B) that signed integral types make virtually no useful guarantees, and
that std::limits does not provide enough information to work around that
problem.
C++ only allow three ways to represent signed integrals.
Really? I recall that I once tried to deduce that from the standard and
that I failed.
>C) that there is no arbitrary precision / big integer class and no matrix
/ tensor template in the standard.
Those are available in third party libraries.
True. However, this kind of thing can benefit tremendously from support by
compiler magic. In addition, standardization has more benefits that
providing availability. Anyway, the availability of third party libraries
makes this a minor nuisance, and I have already qualified this item as
such.
>D) that there is no window / gui support in the standard.
This is heavily platform specific.
So is IO. Yet still, the standard provides means for IO. Again, this is a
minor nuisance, and I might be argued that C++ could drop IO facilities
from the standard altogether.
Best
Kai-Uwe Bux
Steven T. Hatton wrote:
Noah Roberts wrote:
>>
Mathias Gaunard wrote:
>>I see nothing really problematic with functions pointers though.
Man, you guys are spending way too much time on this...
There's nothing problematic about function pointers beyond not really
being able to interchange them. The new function object being added to
the standard is a much better abstraction.
Care to provide a reference to the proposal?
TR1 section 3, in particular 3.7 (polymorphic function wrappers).
>Unfortunately for the OP it uses pounds upon pounds of template magic to
do so.
Anything like what is describe in Chapter 22 of _C++ Templates: The
Complete Guide_? I have to confess I haven't studied it closely.
tr1::function< some_function_call_signature is a class that can hold any
entity that you can use as the function object in a function call
conforming to the specified signature. I don't know whether what is in
chapter 22 conforms to that description.
Here is a baby version for unary functions just to demonstrate the kind of
combination of virtual functions and templates that goes into wrappers like
this:
template < typename R, typename T >
class unary_function_wrapper;
template < typename R, typename T >
void swap ( unary_function_wrapper<R,T& a,
unary_function_wrapper<R,T& b ) {
kubux::swap( a.f_ptr, b.f_ptr );
}
template < typename R, typename T >
class unary_function_wrapper
: public std::unary_function< R, T >
{
friend
void swap<( unary_function_wrapper &, unary_function_wrapper & );
struct base
: public std::unary_function< R, T >
{
virtual
T operator() ( R ) = 0;
virtual
~base ( void ) {}
virtual
base* clone ( void ) const = 0;
}; // unary_function_wrapper_base
template < typename F >
struct X : public base {
F f;
X ( F g )
: f ( g )
{}
virtual
T operator() ( R r ) {
return ( f(r) );
}
virtual
X* clone ( void ) const {
return ( new X ( f ) );
}
}; // X
base * f_ptr;
public:
template < typename F >
unary_function_wrapper ( F f )
: f_ptr ( new X<F( f ) )
{}
unary_function_wrapper ( unary_function_wrapper const & other )
: f_ptr( other.f_ptr->clone() )
{}
unary_function_wrapper & operator=
( unary_function_wrapper const & other ) {
unary_function_wrapper dummy ( other );
swap( *this, dummy );
return ( *this );
}
~unary_function_wrapper ( void ) {
delete ( f_ptr );
}
T operator() ( R r ) {
return ( (*f_ptr)( r ) );
}
}; // unary_function_wrapper
Now, unary_function_wrapper< int, void can take any object x that can be
called like x(5) and returns void.
Best
Kai-Uwe Bux
"Steven T. Hatton" <ch********@germania.supwrote in message
news:Mp******************************@speakeasy.ne t
>
Uh, I am investing my time in learning C++. If C++ is considered too
difficult to be worth learning, then people and projects will move to
other languages. That means my options become more limited.
And posting about the problems with the precompiler and C++'s compilation
model is going to change that?
The biggest problem with all of the features I mentioned is that many
C++ programmers really don't care if they abuse them. They don't even
understand what that means.
So you hope to improve programming practices in this respect. This will mean
C++ is not considered as difficult to learn and so your options will be
broader. Talk about drawing a long bow!!!!!!!!
Save yourself the trouble and focus your energies on improving your C++
expertise. It will do far more to broaden your options.
--
John Carson
Tony wrote:
"Signal9" <ce****@msn.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.com...
Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Or instead of being a consultant of technology, be someone that can actually
build something with it. With C++, rarely do you have to look anywhere else.
All the time spent learning other languages and stuff doesn't make you as
valuable as one who can apply it to some domain, like scientific computing,
graphics/games, OLTP etc. Do survey the other stuff, but don't waste too
much time trying to learn everything and become too broad to apply anything
"professionally". (Sure, I could learn German, Spanish and Latin. But I find
English more than adequate for my purposes and I have better things to do!).
Tony
and you will be on the corner asking for change when they drop the only
tool you know how to use....
i got 25cents for ya...
John Carson wrote:
"Steven T. Hatton" <ch********@germania.supwrote in message
news:Mp******************************@speakeasy.ne t
>>
Uh, I am investing my time in learning C++. If C++ is considered too
difficult to be worth learning, then people and projects will move to
other languages. That means my options become more limited.
And posting about the problems with the precompiler and C++'s compilation
model is going to change that?
I've seen a lot of changes take place as a result such observations. One
high-profile project I know of completely reworked their Cpp laden code
base, replacing their macros with templates.
>The biggest problem with all of the features I mentioned is that many
C++ programmers really don't care if they abuse them. They don't even
understand what that means.
So you hope to improve programming practices in this respect. This will
mean C++ is not considered as difficult to learn and so your options will
be broader. Talk about drawing a long bow!!!!!!!!
Some people do listen to reason.
Save yourself the trouble and focus your energies on improving your C++
expertise. It will do far more to broaden your options.
I would still have to deal with crappy code if I only worried about my own
coding style. It is invariably the case that the design choices other
people make impact my ability to use appropriate language features when
extending their work.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
If you invest your time in this language it will not steer you wrong.
Honestly I would say learn this as your major language, but also learn
other languages. Java and C# are very popular right now and have a
decent mature framework.
When you start as a professional developer you will end up changing
languages over the years and maybe on a project to project basis
(depending on the company you work for).
Actually I say this to you. Go learn C++ as much as possible, learn C
as well. Then for "fun" develop your own high level language. this
will teach you a lot. At this point you may want to get into some
Assembly (which is heavily used in driver and kernel development).
The world of software development is fun, do not forget that. So go
have fun !
"Signal9" <ce****@msn.comwrote in message
news:11**********************@79g2000cws.googlegro ups.com...
>
Tony wrote:
>"Signal9" <ce****@msn.comwrote in message
news:11*********************@80g2000cwy.googlegro ups.com...
Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Or instead of being a consultant of technology, be someone that can
actually
build something with it. With C++, rarely do you have to look anywhere
else.
All the time spent learning other languages and stuff doesn't make you as
valuable as one who can apply it to some domain, like scientific
computing,
graphics/games, OLTP etc. Do survey the other stuff, but don't waste too
much time trying to learn everything and become too broad to apply
anything
"professionally". (Sure, I could learn German, Spanish and Latin. But I
find
English more than adequate for my purposes and I have better things to
do!).
Tony
and you will be on the corner asking for change when they drop the only
tool you know how to use....
i got 25cents for ya...
But I am "they", so that's not likely.
Tony
"Steven T. Hatton" <ch********@germania.supwrote in message
news:4o******************************@speakeasy.ne t...
I will argue that a person with one solid year of learning and working
with
C++ is (with very few exceptions) a novice who is just getting started.
I would agree with that if you change 'one' to 'five' and 'year' to 'years'.
Tony
Steven T. Hatton skrev:
>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn anything new
about programming languages in the past 19 years. Such a person had "one
year of experience twenty times", as he put it. Our prof suggested a
person who has exposure to many different languages will be a far better
programmer than one who has focused on only one.
I will argue that a person with one solid year of learning and working with
C++ is (with very few exceptions) a novice who is just getting started.
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
peter koch wrote:
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
Alas, we are not all so gifted :(
(Of course that was a 'Royal' we, I speak only for myself)
"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@79g2000cws.googlegro ups.com
Steven T. Hatton skrev:
>>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn
anything new about programming languages in the past 19 years. Such
a person had "one year of experience twenty times", as he put it.
Our prof suggested a person who has exposure to many different
languages will be a far better programmer than one who has focused
on only one.
I will argue that a person with one solid year of learning and
working with C++ is (with very few exceptions) a novice who is just
getting started.
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available
for questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
Here is Stroustrup's take on the matter: http://www.research.att.com/~bs/bs_faq.html#How-long
--
John Carson
peter koch wrote:
>
Steven T. Hatton skrev:
>>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn anything
new
about programming languages in the past 19 years. Such a person had "one
year of experience twenty times", as he put it. Our prof suggested a
person who has exposure to many different languages will be a far better
programmer than one who has focused on only one.
I will argue that a person with one solid year of learning and working
with C++ is (with very few exceptions) a novice who is just getting
started.
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
That's a very hard thing to assess given that a productive C programmer is
productively using a subset of C++ already. The question is largely at
what point did you stop using C++ as extended C? There are many subtleties
to C++ that can have a significant impact on producing optimal results.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
"Steven T. Hatton" <ch********@germania.supwrote in message
news:eO******************************@speakeasy.ne t...
peter koch wrote:
>>
Steven T. Hatton skrev:
>>>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn anything
new
about programming languages in the past 19 years. Such a person had
"one
year of experience twenty times", as he put it. Our prof suggested a
person who has exposure to many different languages will be a far better
programmer than one who has focused on only one.
I will argue that a person with one solid year of learning and working
with C++ is (with very few exceptions) a novice who is just getting
started.
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available for
questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
That's a very hard thing to assess given that a productive C programmer is
productively using a subset of C++ already. The question is largely at
what point did you stop using C++ as extended C?
If I was hiring developers at this time, I would PREFER those who used it
only as "a better C". The last one I would want is someone who was
"capable" of doing "amazing" things with the template machinery.
Tony
"John Carson" <jc****************@netspace.net.auwrote in message
news:45***********************@uv-55king-reader-01.melbourne.pipenetworks.com.au...
"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@79g2000cws.googlegro ups.com
>Steven T. Hatton skrev:
>>>
That works with many languages. I had a professor who told us that a
programmer with 20 years experience in C probably didn't learn
anything new about programming languages in the past 19 years. Such
a person had "one year of experience twenty times", as he put it.
Our prof suggested a person who has exposure to many different
languages will be a far better programmer than one who has focused
on only one.
I will argue that a person with one solid year of learning and
working with C++ is (with very few exceptions) a novice who is just
getting started.
What do you mean about a "novice"? If it is a highschool student with
no programming expertise you may be right, but for someone with a
background in software engineering this is simply ridiculous. I spent
two weeks myself before I became productive, and those two weeks were
spent reading Stroustups and Lippmans books (at home), while I began
updating an existing codebase with fellow C++ programmers available
for questioning.
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
Here is Stroustrup's take on the matter:
http://www.research.att.com/~bs/bs_faq.html#How-long
Indeed it's all relative to what one already knows as many skills are
directly
transferrable. If one is already proficient in another language (a REAL
language and not VB for instance... hehe ;) ), it may take less than 5 years
(but I doubt it!). Another key, probably more important, is what the
developer
can build with the language tool. All said, I think good
architecting/designing
is much more important than language, though there is overlap with
programming
with a specific language of course.
Surely I'm just preaching to the choir or reiterating what others have said
time
and again (except maybe that _I_ think it takes longer than other people
think it
does).
There's at least 2 trains of thought on years of programming experience with
a
specific language: 1.) More is better (when you cannot assess if someone is
adequate or not) 2.) Less is better (because you don't have to "unteach"
people
their "bad" programming habits).
Tony
Steven T. Hatton skrev:
peter koch wrote:
[snip]
>
That's a very hard thing to assess given that a productive C programmer is
productively using a subset of C++ already. The question is largely at
what point did you stop using C++ as extended C? There are many subtleties
to C++ that can have a significant impact on producing optimal results.
Which ones?
I believe that I wrote C++ code from day one - almost. My one failure
was my disliking of declaring variables at their first use. I
stubbornly declared them first in the function, much preferring that
approach for the "messy" C++ way of doing this.
That was only the first week, however. As soon as I saw Stroustrups
explanation of RAII, I was convinced that this was the way to go.
/Peter
John Carson skrev:
"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@79g2000cws.googlegro ups.com
[snip]
I had a background as a C programmer so I knew the "basics" and also
had read a bit about OO programming before. Also, my collegues were
knowledgeable and helpful, so I might have been a bit faster than
average. But one year is ridiculous.
/Peter
Here is Stroustrup's take on the matter:
http://www.research.att.com/~bs/bs_faq.html#How-long
--
John Carson
Thanks for that pointer. I vaguely remember having read it before, and
rereading confirms my suspicion that I was not a particularly fast
learner.
/Peter This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: yasaswi |
last post by:
How can I find out the worst performing sql queries or statements in
DB2 database? Is there a command or script to monitor all the sql
statements which are consuming huge amounts of CPU cycles and...
|
by: CBFalconer |
last post by:
Additions welcome. Without further ado, I present.
/* ---------- worst.c -----------*/
/* The objective here is to include as many C errors as
possible, without triggering the compiler into...
|
by: CBFalconer |
last post by:
Presented without further comment for "improvement"
/* ---------- worst.c -----------*/
/* The objective here is to include as many C errors as
possible, without triggering the compiler into...
|
by: aron t |
last post by:
Hi,
I am good php programmer and want to learn asp.net.
Can someone tell me what are the best and the worst features of ASP.NET?
thanks
|
by: Steven T. Hatton |
last post by:
This is one of the first obstacles I encountered when getting started with
C++. I found that everybody had their own idea of what a string is. There
was std::string, QString, xercesc::XMLString,...
|
by: alf |
last post by:
Hi,
is it possible that due to OS crash or mysql itself crash or some e.g.
SCSI failure to lose all the data stored in the table (let's say million
of 1KB rows). In other words what is the worst...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
