|
Anyone's who's ever had to write a COM server in C++ from scratch will undoubtedly have used "delete this". It's how COM objects self destruct when Release reaches a ref-count of 0. Just remember not to access any of the class's member variables afterwards, or boom! 
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
Alvaro Mendez wrote:
Anyone's who's ever had to write a COM server in C++ from scratch will undoubtedly have used "delete this".
Whoa ! I'm a just 19-year old student. I'm quite strong in C and C++, but as far as Win32 SDK and MFC are concerned, I consider myself a novice.
Alvaro Mendez wrote:
Just remember not to access any of the class's member variables afterwards, or boom!
That part I can understand.
About that code of yours ...
Regards and thanks,
Vikram.
Do not put off until runtime what you can do at compile-time.
|
|
|
|
|
I've used this in my in-place editors inside my grid control. Works like a dream.
cheers,
Chris Maunder
|
|
|
|
|
Thanks, Chris!
I'm checking out your article right now.
Regards,
Vikram.
Do not put off until runtime what you can do at compile-time.
|
|
|
|
|
I occasionally use VB, either because i need to prototype a GUI quickly, or because i need to write some ASP(not net) code. Although many things about the language anger and frustrate me, i can't deny it does what it aims to do - you can throw together programs quickly, and with few critical problems. Sure, they'll then be difficult to maintain, extend, or reuse effectively, but hey - that wasn't the point. If you take the time, you *can* write maintainable, extensible, reusable VB code, but then again, you can hammer in nails with your fist too if that's your thing.
Now, VB.NET has revamped some major portions of the language, and i could actually see a nicely planned and designed piece of software being fairly painless to write in it, while still not being sh*t two years (or heck, 6 months...) later.
But, so what? So does C++, so does Java, so does C#, so does... you get my point - if this is what you wanted, you already had it, sans VB. No doubt there are one or two hardcore souls out there who have been doing serious programming with VB for years, and who'll embrace VB.NET with open arms and dewy eyes... But for the "throw the controls on the form, double-click, type in all code in event handler" user, what does VB.NET add, beyond an annoying conversion and a new development environment?
My prediction: 5 years from now, VB6 will still be used for older code, VB.NET will be used for newer code, but used in the same careless way VB6 was. The serious VBers will have gradually moved to C# (cursing semicolons all the way no doubt), and will probably be happer for it, though asserting all that is good in C# came from VB.
I'll be sitting and drinking gin someplace, and wondering why i ever cared...
shog
nine
Ever since i heard the voice
i thought i had no choice...
|
|
|
|
|
"Sure, they'll then be difficult to maintain, extend, or reuse effectively, but hey - that wasn't the point. If you take the time, you *can* write maintainable, extensible, reusable VB code, but then again, you can hammer in nails with your fist too if that's your thing."
They are only difficult to maintain/extend/reuse if written by bad programmers. Bad programmers will be bad programmers no matter what tools they choose. If someone blames the tool, then he is most likely a bad programmer. VB itself does not produce bad programmers, but you may be able to say that it allows even a bad programmer to get something done!
"But for the "throw the controls on the form, double-click, type in all code in event handler" user, ..."
C# allows a user to do the same, besides the character C in its name and the syntax, there is really no big difference between C# and VB.NET. You will probably blame VB for a lot of bad C# programmers in the future.
|
|
|
|
|
You will probably blame VB for a lot of bad C# programmers in the future
This is true.. I blame it now. In my opinion C# and VB are one of the same.. the sig tells it all.
IMHO C++ is one of the only languages that one should absouluty learn. Not that I don't think you should learn other launguages and tools, for example I am proffecient in Perl. Sure C++ has a steep learning curve, I have been learning it for two years now, and I still can't create any great wizbang applications without a lot of work.. but at the same time my knowledge of C++ allows me to write for Win32, Linux, and I have even written a few apps for BeOS. I can create some pretty stunning apps in Windows.. It just takes me a while (part of that is poor math skills though.. my fault.. not the language). I just got done creating a small media player for win and ported it over to my Linux box running X with releative ease.. try and do that with C# or VB!
C# a poor attempt at bringing C++ to the VB masses
|
|
|
|
|
Picture Hanger wrote:
They are only difficult to maintain/extend/reuse if written by bad programmers.
Bullshit. Not that bad programmers won't produce bad code in whatever language/environment they adopt... But where is it written that all programs must be maintainable/extensible/reusable? Once-off hammer-it-out-and-never-touch-it-again prototypes and demos certainly have their places, and VB works nicely for these.
Picture Hanger wrote:
If someone blames the tool, then he is most likely a bad programmer.
Sure, sure... And i suppose only a bad golfer would blame the ball, right? Let's set Tiger Woods up with some wiffle balls before his next game...
Picture Hanger wrote:
C# allows a user to do the same, besides the character C in its name and the syntax, there is really no big difference between C# and VB.NET.
Gee, and i thought i'd have to ask for volunteers to prove my predictions acurate... 
shog
nine
Ever since i heard the voice
i thought i had no choice...
|
|
|
|
|
vb stopped being a language with .net... it became a syntax like every other "language" in .net. The only real languages in .net are IL and C++.
|
|
|
|
|
aren't all "languages" just syntax? isn't the only "real language" machine code?
Ender_JC
P.S. I do however see you point.
|
|
|
|
|
Shog9 wrote:
I occasionally use VB,
I think you have incriminated yourself enough in your first four words.
Now how can anyone take anything else in your post seriously ?
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign'
Rob Manderson wrote:
|
|
|
|
|
Colin Davies wrote:
Now how can anyone take anything else in your post seriously ?
People were taking my posts seriously? 
shog
nine
Ever since i heard the voice
i thought i had no choice...
|
|
|
|
|
Shog9 wrote:
People were taking my posts seriously?
I don't take anything anyone posts here on CP seriously, least of all anything you post;P
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Shog9 wrote:
People were taking my posts seriously?
THe problem is that you shouldn't usually take Colin's posts too seriously. 
You can pick your friends, and you can pick your nose, but you can't pick your friend's nose.
|
|
|
|
|
All well said Shog. Sane stuff in an insane issue.
Shog9 wrote:
cursing semicolons all the way no doubt
Funny but I now curse End XXX syntax since having started using C#. What that chap up above said about ; and {} is grudgingly true.
I 'ave seen the light with {} and ;
Shog9 wrote:
I'll be sitting and drinking gin someplace, and wondering why i ever cared...
Amen brother!
Though I have to say that why we care right now is beyond me.
Shog9 wrote:
The serious VBers will have gradually moved to C#
I hope you are wrong there and that "gradual" is replaced by "swift".
Paul Watson
Bluegrass
Cape Town, South Africa
Macbeth muttered:
I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er
Want a job?
|
|
|
|
|
Paul Watson wrote:
I hope you are wrong there and that "gradual" is replaced by "swift".
Well... there's "serious" and then there's "wild-eyed fanatic"... 
Paul Watson wrote:
What that chap up above said about ; and {} is grudgingly true.
Indeed! I've tried to explain this before, and never quite managed. I remember the first time i saw a code listing in C, and though unfamiliar with the syntax, was able to recognize at a glance the structure, without resorting to scanning it line-by-line as i'd been accustom to with BASIC and Pascal.
shog
nine
Ever since i heard the voice
i thought i had no choice...
|
|
|
|
|
Shog9 wrote:
I'll be sitting and drinking gin someplace, and wondering why i ever cared...
Enter Shog9 the philosopher. Interesting view I might add.
Nick Parker
The only man who never makes a mistake is the man who never does anything. - Theodore Roosevelt
|
|
|
|
|
From what I can gather, VB.NET is the bridge between VB and .NET.
Yes, yes, you use the CLR so technically it's the same, but soon enough MS is going to start splitting the languages, with C# emerging as the more dominant (of the two).
There are also too many programmer who know just one .NET language. My opinion is that programming should be more about understanding concepts and principles than a focus on a single syntax.
Cheers,
Simon
"I ask candidates to create an object model of a chicken.", Bruce Eckel on interviewing programmers.
animation mechanics in SVG (latest pic 1) (latest pic 2)
|
|
|
|
|
SimonS wrote:
My opinion is that programming should be more about understanding concepts and principles than a focus on a single syntax.
This is what I was taught in school, however, in 99% of my interviews people are more concerned about syntax/semantics specific to a language.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
Soliant wrote:
This is what I was taught in school, however, in 99% of my interviews people are more concerned about syntax/semantics specific to a language.
Precisely. And I'm sure this is why the majority of programmers aren't good/able to be reskilled in technology X from vendor Y.
Check this[^] from Bruce Eckel and pals on interviewing programmers.
Cheers,
Simon
"I ask candidates to create an object model of a chicken.", Bruce Eckel on interviewing programmers.
animation mechanics in SVG (latest pic 1) (latest pic 2)
|
|
|
|
|
|
I've used VB professionally for many years and the reason for that is that so many employers picked it for their developments. Why? Because the productivity levels are so superior to C++.
Who wants to spend days coding their own components when they're already available. 
C++ programmers spend so much time bleating about coding for re-use and not enough time actually re-using existing code. VB programmers have, from day one, re-used the components already written for them. No-one builds a house these days by making their own bricks.
Admittedly VB6 is lacking in many areas. It's not anywhere near an OO language. It would be foolish to attempt many projects using it. C++ is obviously the most powerful, complex and multi-purpose language available. However these strengths are also it's weaknesses.
VB's weaknesses have been addressed by Microsoft in VB.NET. They have bravely cut many ties with VB6 leaving it in-compatible. This has resulted in a usable object-oriented language (admittedly still not fully OO).
For the odd occasion where VB.NET is not appropriate we now have C#. At last a version of C which addresses the complexity issues and provides productivity levels on a par with VB. Perhaps this is why I have noticed that the majority of .NET jobs advertised are asking for C#.
I evolved into VB.NET, but I am going to move to C# because it now offers the best combination of simplicity and productivity. This move will be helped by the fact that the languages are so similar and that 90% of the time you are merely using the .NET Framework which is the same in either language. Who knows, perhaps this was Microsoft's master plan all along. Maybe VB.NET was written merely to ease the passage of VB programmers over to C#.
We find comfort among those who agree with us - growth among those who don't
(Frank A. Clark)
|
|
|
|
|
I've used VB professionally for many years and the reason for that is that so many employers picked it for their developments. Why? Because the productivity levels are so superior to C++.
Yes and no. In San Diego a few years ago, most employers wanted VB consultants because they were cheaper, and because they were more numerous, thus easily replaceable.
Productivity appears superior to begin with, but I've found that large scale development in VB eventually becomes unmaintainable, primarily because most VB programmers don't think in terms of generalization and abstraction. In my experience, VB programmers cut&paste code everywhere (hence your reuse) but fail to generalize. Eventually, making a simple change means finding 100 places that it needs to be changed and missing a 100 more.
That said, I'd say the biggest problem with C++ programmers is their complete lack of understanding of object oriented design and the appropriate use of objects, which leads to a different problem than the VB camp--namely inflexibility. It becomes impossible to make changes to the program without breaking the entire thing.
In either case, I feel the productivity thing is based on perception as opposed to real numbers (or simply having been burned on a C++ project first!).
What we need is a language/environment that promotes generalization AND flexibility. In some ways (especially with the event capability), .NET (whether C# or VB or anything else) helps this situation, but not totally, in my opinion.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
>>VB programmers cut&paste code everywhere (hence your reuse) but fail to generalize
As that statement is a generalization I take it you're a C++ programmer
I think it would be fairer to say that BAD programmers write unmaintainable code. It would also be fair to say that more VB programmers fall into that category - because only good programmers can cope with C++'s complexity.
Lots of people get drawn to VB because it is easy to get a simple program written in a very short period of time. Consequently everyone thinks they're a programmer and we end up with badly written unmaintainable code.
OK so assuming we have a set of bad programmers, which of their code would you rather debug - VB or C++? I suppose the answer would be whichever you're most comfortable with, but I for one would find the C++ harder because it's harder in the first place. I don't know of any figures (perhaps someone reading this may know) but I would imagine that the C++ equivalent of a VB program would require many more lines of source code. Increased source size inevitably leads to increased complexity - there's a whole industry called software metrics which swears by this.
Assuming we have a set of good programmers I would say it was a mute point and that the productivity I mentioned before would swing into VB's favour.
Asserting yourself while respecting others is a very good way to win respect yourself.
- Janice LaRouche
|
|
|
|
|
Assuming we have a set of good programmers I would say it was a mute point and that the productivity I mentioned before would swing into VB's favour.
Wow, this thread is sure getting a lot of message voting!
I've done some VB programming for a couple clients, and I rapidly became "comfortable" with the language but there were some things that I simply couldn't figure out how to do in VB (partly because the client didn't want to pay for too much of my learning curve).
In particular, part of what I consider to be productivity enhancing is:
1. ability to hook into memory allocation and deallocations to test for memory leaks. I prefer this method to other methods, but that may just be me.
2. the ability to implement sophisticated instrumentation using macros--assertions, warnings, traces, etc...
3. multithreading, semaphores, mutexes, etc...
4. the ability to implement objects for things like internal messaging, state machine, event handlers, and data pooling, and thread pooling, all of which I consider to be foundational requirements in any application, now matter how small. Instrumentation of these objects is a major productivity enhancer when it comes time to debug complex code interactions.
5. runtime generated GUI's instead of design time .RC style GUI's.
Now, it seems that VB.NET can do all of the above (except for the cool /// comment capability that C# has but I didn't put that in the above list), but how much of this was possible with VB5/6?
There. I have revealed my ignorance. I am actually quite interested in the answers, as I have never taken the opportunity to have this discussion with someone well versed in VB. No criticism intended, but my limited experience with project leads on VB projects (both for HMO provider companies) was that the project lead wasn't really running on all cylinders. And therefore I didn't feel there was much point in any meaningful discussion.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
