T
Tony
Signal9 said:
But I am "they", so that's not likely.
Tony
But I am "they", so that's not likely.
Tony
T
Tony
I would agree with that if you change 'one' to 'five' and 'year' to 'years'.
Tony
P
peter koch
Steven T. Hatton skrev:
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
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
G
Geo
peter said:
Alas, we are not all so gifted
(Of course that was a 'Royal' we, I speak only for myself)
J
John Carson
peter koch said:
Here is Stroustrup's take on the matter:
http://www.research.att.com/~bs/bs_faq.html#How-long
S
Steven T. Hatton
peter said:
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.
T
Tony
Steven T. Hatton said:
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
T
Tony
John Carson said:
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
P
peter koch
Steven T. Hatton skrev:
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
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
P
peter koch
John Carson skrev:
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
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
S
Steven T. Hatton
peter said:
You would have to be insane to learn C++ by reading Stroustrup's book!
Trust me, I did it that way.
Actually, RAII, understanding referencesand their consequences, and value vs. reference semantics (for recovering
Java programmers) are some of what I consider the most essential aspects of
C++. Understanding what templates are (and are not) is also essential.
Koenig and Moo offer a very different perspective on C++ than does
Stroustrup. I would call the essential distinction "type-based"
programming to contrast it with OOP or generic programming. Stroustrup
covers the same set of facts, but the approach in _Accelerated C++_ opened
my eyes to what the STL really means.
I've been at this for a little less than two years[*] and can honestly say
there are several aspect of the language which I am not yet comfortable
with. For example, I still don't understand the subtleties of friend
declarations as they involve scopes and declarative regions. It doesn't
help that my compiler seems to get it wrong.
[*]Punctuated by several months spent investigating the formation and
stability of Prussian Blue, the epistemological validity of Cantor's
transfinite numbers, the emissivity, absorptivity and radiation profiles of
various molten metals, and the dynamics of the WTC7 collapse, etc.
P
peter koch
Steven T. Hatton skrev:
I found Stroustrups books very nice and easy to read, so perhaps
there's a cultural difference here ;-). Still... at the time there was
no "Accelerated C++" book available.
programmed in Pascal.
Surely. You need an understanding, but it does not need to be complete.
Actually, basic template programming is quite easy: most of the job in
making a function/class generic is to replace a concrete type with a
generic one and often youre done. Take as an example std::min.
inline int min(int i, int j) { return i < j? i: j; }
now template it:
inline template <typename T>
T min(T i, T j) { return i < j? i: j; }
and you're basically done until you discover that you have to many
copies running around and/or std::min takes to much time. So replace it
with the final version:
inline template <typename T>
T min(T const& i, T const& j) { return i < j? i: j; }
(This last step will probably be taken immediately if you are anything
than a beginning C++-programmer).
I haven't read Koenig/Moo (except for the sample chapters), but
Stroustrup actually emphasises that C++ is a multi-paradigm language,
not forcing OO or generic unto you.
Right. But in your practical day-to-day life how often does this
happen? Just how often do you get this tricky friend declaration as a
problem? I'd guess less than twice a year. With other C++ subtleties
slapping your face, I'd guess you'd need to check the standard perhaps
bimonthly and probably not that often.
/Peter
[snip]
peter said:
You would have to be insane to learn C++ by reading Stroustrup's book!
Trust me, I did it that way.
I found Stroustrups books very nice and easy to read, so perhaps
there's a cultural difference here ;-). Still... at the time there was
no "Accelerated C++" book available.
Right. But you should know that already - at least as soon as you've
programmed in Pascal.
Surely. You need an understanding, but it does not need to be complete.
Actually, basic template programming is quite easy: most of the job in
making a function/class generic is to replace a concrete type with a
generic one and often youre done. Take as an example std::min.
inline int min(int i, int j) { return i < j? i: j; }
now template it:
inline template <typename T>
T min(T i, T j) { return i < j? i: j; }
and you're basically done until you discover that you have to many
copies running around and/or std::min takes to much time. So replace it
with the final version:
inline template <typename T>
T min(T const& i, T const& j) { return i < j? i: j; }
(This last step will probably be taken immediately if you are anything
than a beginning C++-programmer).
I haven't read Koenig/Moo (except for the sample chapters), but
Stroustrup actually emphasises that C++ is a multi-paradigm language,
not forcing OO or generic unto you.
Right. But in your practical day-to-day life how often does this
happen? Just how often do you get this tricky friend declaration as a
problem? I'd guess less than twice a year. With other C++ subtleties
slapping your face, I'd guess you'd need to check the standard perhaps
bimonthly and probably not that often.
/Peter
[snip]
S
Steven T. Hatton
Signal9 said:
I watched C++ get evicted from much of the so-called application server
market back before Microsoft ("cut off their air supply") dumped IE on the
market to drive Netscape out of business. Most of the advantage that Java
has over C++ does not relate to what you can do with Java but not with C++.
It almost exclusively relates to what you _cannot_ do with Java but can do
with C++.
Another factor that compromised C++'s viability was the (often unreasonable)
insistence that new C++ code had to be backward compatible. For example,
in some cases projects still have injunctions against using templates or
namespaces because "some compilers don't support them". An injunction that
made a bit of sense when originally imposed, but is now obsolete.
It would be extremely valuable to compare the experiences of beginning
programmers learning C++ vs. a similar group learning Java. I believe such
a study would reveal that students learning C++ encounter a considerable
awkwardness which is not really inherent to the core language, but is not
presented by Java. It is clearly easier to create comprehensive IDEs for
Java than it is to create them for C++. Some of that has to do with the
complexity of C++, but much of it has to do with Cpp.
I guess that depends on what you are willing to do, and the company you work
for. My brother has been programming almost exclusively in C for about 20
years. My preference is to be the one determining the language I work in.
There are also perl, LISP, SML, Mathematica, Bash, JavaScript, etc.
Mathematica is an especially interesting programming language. I have
often called it LISP on steroids. The whole Mathematica system (front end
and kernel) has an uncanny similarity to Emacs and Emacs LISP.
If you don't end up spending all of your time in "engineering" meetings.
S
Steven T. Hatton
Kai-Uwe Bux said:
That makes sense to me. In the latter, the lifetime of in_vector() ends
before that of iv. In the former you create an anonymous object which
lives until you exit the block.
I am inclined to const violations as an indication of bad design on my part.
A first I found it frustrating and even irrational. The more I worked with
it, however, the more I realized it was good for me.
Nonetheless, it imposes another requirement on the compiler to deal with all
possible contingencies. From my perspective, you seem to be asking to get
away with something you probably should not be doing.
I guess I don't follow. How can a lack of a protected member in the least
derived type restrict what you can do with derived types?
Stroustrup contributed to a paper a while back which talked about 'automatic
type detection' or something like that. IIRC, the idea was to determine
the type of an lvalue based on the type of an assigned rvalue. It seemed
to me like a ticket to overly generalized design.
You can do what amounts to the same thing in Java.
In a way that would be less convoluted than the existing approach of using a
visitor pattern? Care to provide an example?
See TC++PL(SE) §24.4.1.
There is nothing you can do with templates which cannot be done with OOP.
The only difference is when type-checking takes place.
There are ways of folding error messages so that you only see the level or
parts you are interested in.
Care to provide an example? I really don't see how you can define
std::list said:
Can you provide an example in which the value of a pinter to void is larger
than any value possibly returned by sizeof()? Likewise for ptrdiff_t.
I know a lot of people who will disagree with you.
E
Evan
Steven said:
Unless I'm mistaken, the temprorary in version 1 goes away at the end
of the statement just like the one in version 2 would if it were
allowed. It only lives 'till the end of the block because there are no
statements following.
When did imposing an extra requirement on compiler writers (that really
wouldn't be hard to satisfy at all) become worse than imposing a burden
on programmers?
If anything, C++ puts the burden on the compiler more than any other
language I know. What other language is there where 8 years after the
standard was published there's still only about one conforming
compiler?
Evan
S
Steven T. Hatton
peter said:
The distinction I'm talking about isn't really an issue with Pascal. It has
to do with polymorphism and what happens when you assign objects of derived
types to objects of their base type, etc. Pascal is not object oriented,
so that never comes into play. In Java there is never a possibility of
slicing because you are always dealing with pointers.
See page 59 of _C++ Templates: The Complete Guide_ for s discussion of
problems related to using const references.
As I say, all the facts are present in TC++PL(SE). It was just a difference
in presentation which made me realize there was another way of thinking
about types and how they are used.
I would just like to get to a point where I feel like I have grasped the
entire language. I expect I will be learning new ways of using it for as
long as I am programming with C++. It would be nice, however, to be able
to understand how both of the following statements from the Standard can be
true:
"friend declarations may introduce a name into an enclosing namespace".
"friend declarations refer to functions or classes that are members of the
nearest enclosing namespace, but they do not introduce new names into that
namespace".
K
Kai-Uwe Bux
Steven said:
Actually, the temporaries in both examples die at the end of the full
expression not at the end of the block.
The standards committee seems to see the need that I was hinting at: the
current draft of the next revision of the standard introduces rvalue
references; and I can't hardly wait until they make their way into the
compilers.
[talking about typeid() returning something more meaningful than
std::type_info]
Well, just prove me wrong and tell me how to implement a get-instance method
in something deriving from std::type_info. I just hope we are on the same
page: by get-instance I want to get an object of the type whose typeid()
matches the type_info object that I have. I don't see how you could
possibly achieve that within current C++.
To me things like these look like exciting new possibilities to express
myself in code.
Maybe, I don't know Java. Does Java have the type "type", i.e., does Java
have variables that hold types? and can you use those variables like you
can use type constants? Could you do:
virtual
void f ( type T ) {
if ( T.default_constructible() ) {
T x;
}
...
}
I would love to have something like that in C++. I took your claim above
(about std::type_info) as saying that you could already implement this kind
of thing in C++ as it is today. Unfortunately, I just don't see how. Maybe,
I misunderstood your point entirely.
[snip]
Even if that should be right on a technical level, it is still irrelevant
for the discussion. Generic programming differs vastly from OO in design,
idioms, the way to structure and go about a problem. The reasons to use
templates are not so much what you _can_ do but what feels _natural_ to do
in a certain problem domain. That is a cultural thing. I still maintain
that your point of view just exhibits a certain cultural bias toward OO;
and that C++, on the other hand, is not best understood as an OO language
with some performance hacks (aka templates) added.
Cool, where can I get such a system?
I did that elsethread:
#include <iostream>
#include <iterator>
#include <algorithm>
#include <list>
class recursive_list {
std::list< recursive_list > the_list;
public:
friend
std:
stream & operator<< ( std:stream & 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:
stream_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: [ [] [] [] [ [] [] [] ] [] [] [] ]
Actually, this already compiles on my machine. 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.
This is again one of these cases where all implementation (that I know)
already conform to expectations (like the std::list<> example above). What
I dislike is just that the standard does not require sizeof( void* ) <=
sizeof( std::size_t ) nor does it require that an integers type exists that
can hold a void*.
Ok, I do not claim to be an expert in numerical analysis, however, I am
pretty certain that a linear algebra template collection that works nicely
with doubles, large integers, and rational numbers is a considerable
undertaking. For floating point types, all of a sudden numerical stability
enters the pictures whereas for rational numbers storage and runtime might
be considered paramount. If you show me something that is done "without too
much effort" that does not suck, I will be very impressed. I just recall
that the last time I needed heavy linear algebra was a few years ago when I
had to solve 10000 linear programs, some of significant size. The programs
I found differed considerably in capacity. The ones done "without too much
effort" amounted to nothing more than toys in comparison to those written
by people in the field: the toy would run for hours on a medium size
problem that took less than a minute with the real thing and when the real
linear program solver would take a few minutes, the toy would just not be
able to complete the computation.
Best
Kai-Uwe Bux
B
bjarne
Steven said:
You seem remarkably certain of your opinion. As far as I can tell
(1) there is no one best way to learn C++ for all people
(2) there is no one best book for learning C++ for all people
(3) many people have successfully learned C++ from TC++PL
(4) many people have successfully learned C++ from other sources
(5) many people have failed to learn C++ from TC++PL
(6) many people have failed to learn C++ from other sources
Here, "many" means "hundreds of thousands".
In http://www.research.att.com/~bs/bs_faq.html#best-book I give my
opinion on who might benefit from TC++PL: "The book is aimed at
programmers with some experience and a wish to master C++. It is not
aimed at non-programmers trying to learn their first programming
language or casual programmers trying to gain a superficial
understanding of C++ as fast as possible."
To each his/her own. People really do think and learn differently.
People really do have different interests, skills, and needs when it
comes to writing code.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
S
Steven T. Hatton
bjarne said:
It was a joke: "Trust me, I did it that way.
"What I find is that reading a different introductory text usually gives me a
new perspective on things. I hope to get around to reading Stan Lippman's
_Primer_ as well as Nicolai Josuttis's _OOP in C++_. I'm sure each will
provide new insights. I'm currently reading _Intro to Design Patterns in
C++ and Qt 4_ by Alan and Paul Ezust. Though it's quite elementary, I have
learned a thing or two from it about pointers and how programs arrange
memory in the real world.
I could not agree with you more. I know my learning style is quite
different from that of most other people. I quite enjoyed TC++PL(SE), and
plan to read it again. I consider it among the great works of the 20th
Century.
Though I never finished it, I rather enjoyed this as well:
http://www.hkbu.edu.hk/~ppp/cpr/toc.html
P
peter koch
Steven T. Hatton skrev:
So you are not talking about the difference between reference and value
semantics - an
absolutely fundamental concept in computer science - but about slicing?
To put it kindly, your argumentation is not very convincing.
it is possible to copy stuff around, and I do not see how slicing
becomes more or less of a problem in that language.
references in my example, please feel free to speak up.
[snip]
grasped the english language. That point will only be reached by very
few, and yet so many express themselves in english quite well.
to (at least) examine the standard.
/Peter
[snip]
So you are not talking about the difference between reference and value
semantics - an
absolutely fundamental concept in computer science - but about slicing?
To put it kindly, your argumentation is not very convincing.
What makes you think so? Just because most stuff in Java is pointers,
it is possible to copy stuff around, and I do not see how slicing
becomes more or less of a problem in that language.
I do not have that book: if you believe there to be problems with const
references in my example, please feel free to speak up.
[snip]
I believe you would also like to get to a point where you felt you'd
grasped the english language. That point will only be reached by very
few, and yet so many express themselves in english quite well.
That one looks confusing. If you'd like an explanation from me I'd have
to (at least) examine the standard.
/Peter
[snip]