 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
One of the better ones I've seen.
http://web.mit.edu/~axch/www/writing_rant.html
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> One of the better ones I've seen.
> http://web.mit.edu/~axch/www/writing_rant.html
It's funny how everybody keeps repeating the same mantras about C++,
yet I don't experience them myself. It must be a different C++.
I *honestly* can't remember when was the last time I got a segmentation
fault in a C++ program of mine. Maybe sometimes it happens, but really,
really rarely. I'd say that during the past year I might have got perhaps
one segmentation fault.
Memory leaks? *That's* a really, really long time. I'd estimate 10 years
maybe?
Out-of-bounds access is a lot easier to get, especially since off-by-one
mistakes are very easy to do (regardless of the language you are using,
at least if it's an imperative one). Don't remember the last time I had
to actually seriously hunt for one, though.
Well, maybe it's just me. Since everybody keeps repeating the same mantras
then it must be true.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/25/2010 02:02 PM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> One of the better ones I've seen.
>
>> http://web.mit.edu/~axch/www/writing_rant.html
>
> It's funny how everybody keeps repeating the same mantras about C++,
> yet I don't experience them myself. It must be a different C++.
>
I imagine a large part of the difference if that you've learned a set of
programming techniques in C++ which go a long way in avoiding these
problems. If, however, one hasn't programmed in C++ enough to make
these things second nature then I think that it is indeed a relatively
perilous language since part of its design philosophy is not to waste
resources protecting you from yourself unless you explicitly ask for it.
In fact, I'd wager that some of the programming techniques which you
use in C++ are exactly the sort of things that a higher-level language
would do for you automatically (memory management, bounds checking,
etc.), but which you had to learn/be told to do in C++. Granted I
rather like this design philosophy, but it took some work before I could
program in C++ without being frustrated.
Also, his quip about cryptic compile-time error messages is definitely
justified IMHO (at least as far as g++ goes).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler <wampler+pov### [at] uwashingtonedu> wrote:
> In fact, I'd wager that some of the programming techniques which you
> use in C++ are exactly the sort of things that a higher-level language
> would do for you automatically (memory management, bounds checking,
> etc.)
Certainly. In most programming languages you don't have to care *at all*
about certain things which you have to be careful about in C++ (at least
in larger programs). Also many languages offer out-of-the-box features
that C++ doesn't (except as third-party libraries).
On the other hand, it feels like in most of the "higher-level" languages
these features are usually mutually incompatible with memory efficiency
(and sometimes even speed). There are some languages which offer both the
features and the possibility of efficient resource usage, but these languages
often seem to lack good compiler support for most platforms (either there are
no compilers, or they are limited, awkward to use and don't interact with
the rest of the system very well). Many scripting languages are better in
the portability side, but they often also tend to be inefficient.
> Also, his quip about cryptic compile-time error messages is definitely
> justified IMHO (at least as far as g++ goes).
If it's your first time compiling C++ programs with gcc, the error
messages can be quite cryptic, but having used gcc for quite many years
I can recognize all the relevant parts quite fast. It's rare to get
messages I have hard time deciphering. (Usually you get quite far by
simply skipping all the "instantiated from" lines.)
(gcc has improved a lot in its error messages. gcc 2.x tended to produce
extremely lengthy and cryptic messages, especially with template code, but
the current gcc has simplified it quite a lot.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I *honestly* can't remember when was the last time I got a segmentation
> fault in a C++ program of mine.
I fully believe that. I think the problem is you're not dealing with other
peoples' code. I think the people who bust on it are people who have had to
deal with suboptimal code.
I'm dealing with crappy code now. When I say "this giant library core dumps
when I do X, Y, and Z", and they say "It doesn't core dump on our test
program. Must be your problem." then it's easy to get frustrated with C++
not being able to pin down who is at fault.
> Well, maybe it's just me. Since everybody keeps repeating the same mantras
> then it must be true.
I think you're probably rarely talented. :-)
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/25/2010 02:34 PM, Warp wrote:
>
> On the other hand, it feels like in most of the "higher-level" languages
> these features are usually mutually incompatible with memory efficiency
> (and sometimes even speed).
>
I certainly agree, and I actually rather like the approach that C++ has
taken for tasks where I do care about the efficiency. But I can see
where the "knife fight" analogy came from (perhaps a better related
analogy if it weren't so obscure is using a urumi -- very effective but
you'd better know what you're doing or else you'll end up hurting yourself).
>> Also, his quip about cryptic compile-time error messages is definitely
>> justified IMHO (at least as far as g++ goes).
>
> If it's your first time compiling C++ programs with gcc, the error
> messages can be quite cryptic, but having used gcc for quite many years
> I can recognize all the relevant parts quite fast. It's rare to get
> messages I have hard time deciphering. (Usually you get quite far by
> simply skipping all the "instantiated from" lines.)
>
Hmmm, even with the my current version of g++ (4.4.1) I still find the
error messages to be cryptic. This isn't to say that I have trouble
understanding them, but I feel like this is due to gaining skill at
decrypting them and learning that when I see message "x" it probably was
actually caused by mistake "y". Perhaps it's just a difference in what
we mean by "cryptic". That said, I do think that there's some further
evidence for the need for better error messages by the attempted
introduction of concepts into the C++0x standard (even if they didn't
make the final cut).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> evidence for the need for better error messages
I was actually pretty impressed by the C# IDE from MS. I wrote
void do_it(int a, int b, int c = 0) { ... }
and the error message wasn't ") or , expected" or "syntax error", but rather
a pointer to the = and the message "C# does not support default arguments."
I was also impressed when I started up my program under test in full screen
and the IDE bumped its debugger windows over to the second screen and put
them back when the program exited. Cool attention to detail. Not that this
has anything to do with the current thread.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/25/2010 02:58 PM, Darren New wrote:
> Kevin Wampler wrote:
>> evidence for the need for better error messages
>
> I was actually pretty impressed by the C# IDE from MS. I wrote
>
How have you liked C# so far? I last tried it when it was a pretty new
language and it came across as a slightly altered version of Java, but I
imagine it's changed a fair bit since then.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I was actually pretty impressed by the C# IDE from MS. I wrote
> void do_it(int a, int b, int c = 0) { ... }
> and the error message wasn't ") or , expected" or "syntax error", but rather
> a pointer to the = and the message "C# does not support default arguments."
But is that kind of message the rule or the exception?
And it's not like gcc didn't have similar-sounding error messages:
error: ISO C++ forbids declaration of 'x' with no type
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 25 Feb 2010 13:39:25 -0800, Darren New wrote:
> One of the better ones I've seen.
>
> http://web.mit.edu/~axch/www/writing_rant.html
He missed "Pseudocode", which I'd write as:
Coding in pseudocode is like a metaphor.
;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
