Ahhhhhh
-
Rohde wrote:
the STL is great but minimal at best
Thought I'd take a shot at answering you. :) I think it depends on what you're doing. (No wait, I KNOW it depends on what you're doing). I did an app that depended heavily on STL, I couldn't imagine doing it with a language that didn't support true and full STL capabilities. And it needed to be heavily optimized--not saying the same code wouldn't run as well in C#, but damn, it was nice being able to actually see the assembly output and be able to play with register keywords and other optimizations. That said, I do NOT miss the memory leak debugging nor the super-consciousness of always having to think "now, where am I deleting that memory allocation?". And frankly, I don't miss header files either, though when I first started using C#, I thought it was disguisting how the class definition and code were the same thing.
Rohde wrote:
because of the huge API you get for free
The API has never been a selling point for me. I hated MFC, I tolerate the .NET framework, and I basically write wrappers as much as possible for both, because they're so lame as it is. OK, not entirely, there's some great things, but they seem to be the more esoteric things for me. Oh wait, yeah, it depends on what you're doing. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
And frankly, I don't miss header files either, though when I first started using C#, I thought it was disguisting how the class definition and code were the same thing.
Sounds like C# has a lot in common with classic VB. ;P
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Yeah, I'm coveting that Platinum membership as well, mostly because Gold membership doesn't really mean anything since it's just a bonus level. You gotta earn platinum. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
You gotta earn platinum.
That's what I'm thinking. :laugh:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
In thinking it through, it's not so much that I prefer C# less than C++, it's that I enjoy native app development more than web based stuff. If I'm writing a web site, and a browser based solution really is the best way to go (rather than just being the trendy way to go), then C# / .NET rocks over all previous languages I've worked with. But the experience is massively clumsy compared to native development. I've been toggling back and forth this week between the weather channel toolbar in C++ and a basic database browser app in C#. The difference in the number of hoops I have to jump through to do things in a web browser is notable, and I find myself breathing a sigh of relief every time I fire up the C++ project. That said, I'd like to dig into a full tilt boogie native application written in C# and Winforms. I think that's the only way I could really compare the two in terms of productivity, etc. I don't enjoy chasing memory bugs anymore than the next guy, and if the framework gives me lots of cool stuff, it could be fun. I just don't like a language that tells me, "no." And programming within the constraints of a stateless protocol just sucks. I'm not sure how many others are actually feeling the same way, i.e. associate C# with web development rather than as a comparable language to C++. For serious application development, browser based development is like trying to build a sophisticated fighter jet out of your kid's building blocks. It comes nowhere close to native development in C++. However, since that's not a fair comparison of languages, I'd be curious to hear from my C++ brethren who have developed native Windows GUI based apps in both C++ and C# / Winforms. That's the real comparison.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
I tend to associate C#/.NET/et al with business app and web development. I really just see it as repackaged VB with a face lift so some C++ programmers would fall for it. That being said, I'm glad to see it replace classic VB, but I still have the same feelings towards native vs managed as I did before .NET came along.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
John Simmons / outlaw programmer wrote:
- I'm not afraid of a few pointers
But your client is..
John Simmons / outlaw programmer wrote:
- It's in my nature to go against the grain, spit into the wind, take the road less traveled, etc.
Do you advice us to do so too?? :omg:
L.W.C. Nirosh. Colombo, Sri Lanka.
Nirosh wrote:
But your client is..
Not really. Most clients don't know anything about computers.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
John Simmons / outlaw programmer wrote:
I'm coding in unmanaged C++ again, and I feel... liberated.
Congradulations, and welcome back to the fold! :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
welcome back to the fold!
Yeah, I guess we can't pick on John anymore when he's not looking. :rolleyes:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
In thinking it through, it's not so much that I prefer C# less than C++, it's that I enjoy native app development more than web based stuff. If I'm writing a web site, and a browser based solution really is the best way to go (rather than just being the trendy way to go), then C# / .NET rocks over all previous languages I've worked with. But the experience is massively clumsy compared to native development. I've been toggling back and forth this week between the weather channel toolbar in C++ and a basic database browser app in C#. The difference in the number of hoops I have to jump through to do things in a web browser is notable, and I find myself breathing a sigh of relief every time I fire up the C++ project. That said, I'd like to dig into a full tilt boogie native application written in C# and Winforms. I think that's the only way I could really compare the two in terms of productivity, etc. I don't enjoy chasing memory bugs anymore than the next guy, and if the framework gives me lots of cool stuff, it could be fun. I just don't like a language that tells me, "no." And programming within the constraints of a stateless protocol just sucks. I'm not sure how many others are actually feeling the same way, i.e. associate C# with web development rather than as a comparable language to C++. For serious application development, browser based development is like trying to build a sophisticated fighter jet out of your kid's building blocks. It comes nowhere close to native development in C++. However, since that's not a fair comparison of languages, I'd be curious to hear from my C++ brethren who have developed native Windows GUI based apps in both C++ and C# / Winforms. That's the real comparison.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
You're right C# rocks for web development. On the other hand, I've tried it for desktop app, and although you have this nice feeling of speed at the beginning of the project, after a while you feel like on a boat where you have to keep on patching... For desktop apps nothing beats native code! Back in the ASP days, I have developed web pages in C++. The technique was simple, just grab the intrinsics objects, and do everything else in native C++. Although a little bit unnatural for web development, it ended up being very productive and fun. ASP was particularly clumsy for its way of mixing declarative tags with regular code. After I saw some coworkers write VBScript routines that would allow them to generate HTML in a "coded" manner, I figured mixing declarative tags with pieces of code could be simplified to code only. And so used the intrinsics in C++. Some people would prefer using tags though.
-
Rohde wrote:
looking forward to see how they put threading in there for next C++ coming in 2010.
Intel uses OpenMP, so you already can. One of the difficulties is that you need to LEARN threading techniques. The compiler can't do it all for you. One of my team often said, "just put in a mutex that will fix it." I refused and got the reputation of hating mutexes. I do, in someways, properly written parallel code doesn't need them. I even have parallel versions of some STL containers. Parallel is first and foremost a thought process, not a compiler, or a tool. It's no different than learning C# or C++, it is just hated because the mistakes are almost always memory corruption and coredumps. It's an unforgiving taskmaster, but one very worthwhile learning from.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
I even have parallel versions of some STL containers
Have you got parallel versions of the STL algorithms as well, or does that fall out of your parallelized containers?
-
Good post. Yeah the STL can be quite neat; what it does it does very good (with few exceptions) but it just does so little. I'm very much looking forward to see how they put threading in there for next C++ coming in 2010.
FAULTLOG.TXT: File too large.
Rohde wrote:
but it just does so little
It depends what you're doing - much of my work is involved with storing and processing large amounts of disparate data, for which I find a combination of STL and Boost[^] is just right. I wouldn't have a need for the latest .NET doodad like, for example, WPF. However, in many of the libraries I write, the capabilities of C++ over C# ease development. For example, writing generic functions using templates and using specialisation to write specific instances of htose generic functions where necessary.
-
You know what John - you've inspired me to submit some more articles myself. I have lots of little utility classes/functions kicking around which I think I'll tidy up and submit. To exceed 25 decent articles has always been a goal of mine, as I really covet that almighty Platinum membership status... (plus *cough* the warm feeling you get when you share your code with others). :) The problem is that much of my code relies on STL/Boost, but to increase exposure I guess I should probably make it more MFC friendly - use CString's, MFC containers, etc.
Kicking squealing Gucci little piggy.
The Rob BlogRob Caldecott wrote:
MFC containers
Don't do it - you'll never get rid of the 'dirty' feeling you get from using MFC containers... I'll let you off with CString, 'cause it's a better fit for a lot of Win32 stuff, but the containers? Nah.
-
Rohde wrote:
looking forward to see how they put threading in there for next C++ coming in 2010.
Intel uses OpenMP, so you already can. One of the difficulties is that you need to LEARN threading techniques. The compiler can't do it all for you. One of my team often said, "just put in a mutex that will fix it." I refused and got the reputation of hating mutexes. I do, in someways, properly written parallel code doesn't need them. I even have parallel versions of some STL containers. Parallel is first and foremost a thought process, not a compiler, or a tool. It's no different than learning C# or C++, it is just hated because the mistakes are almost always memory corruption and coredumps. It's an unforgiving taskmaster, but one very worthwhile learning from.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
Parallel is first and foremost a thought process, not a compiler, or a tool.
I totally agree. Somehow people think that multithreading will solve their performance issues. Without really understanding what's going on, people will produce bad designs - if designs are made at all - and that will result in a coding nightmare. Not even mentioning that this will even hurt performance. Parallel is more a design concept than a programming thing.
Behind every great black man... ... is the police. - Conspiracy brother Blog[^]
-
I love it when circumstances swing in my favor. I'm coding in unmanaged C++ again, and I feel... liberated. :) And CP wins because I even came up with another article. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Welcome back. :)
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
John Simmons / outlaw programmer wrote:
- I'm not afraid of a few pointers
But your client is..
John Simmons / outlaw programmer wrote:
- It's in my nature to go against the grain, spit into the wind, take the road less traveled, etc.
Do you advice us to do so too?? :omg:
L.W.C. Nirosh. Colombo, Sri Lanka.
Nirosh wrote:
John Simmons / outlaw programmer wrote: 2) I'm not afraid of a few pointers But your client is..
Shya - right. They think a pointer is one of those laser thingies.
Nirosh wrote:
John Simmons / outlaw programmer wrote: 4) It's in my nature to go against the grain, spit into the wind, take the road less traveled, etc. Do you advice us to do so too??
Of course.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Nirosh wrote:
John Simmons / outlaw programmer wrote: 2) I'm not afraid of a few pointers But your client is..
Shya - right. They think a pointer is one of those laser thingies.
Nirosh wrote:
John Simmons / outlaw programmer wrote: 4) It's in my nature to go against the grain, spit into the wind, take the road less traveled, etc. Do you advice us to do so too??
Of course.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Of course.
Those who have changed the world had always done so.. but according to probability, you should have experienced more failures/ troubles than successes/ comforts by doing so..
L.W.C. Nirosh. Colombo, Sri Lanka.
-
Nirosh wrote:
But your client is..
Not really. Most clients don't know anything about computers.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Marc Clifton wrote:
And frankly, I don't miss header files either, though when I first started using C#, I thought it was disguisting how the class definition and code were the same thing.
Sounds like C# has a lot in common with classic VB. ;P
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
Sounds like C# has a lot in common with classic VB.
Yeah, it's basically the same thing except for the curly braces vs. "procedure" or "function", IIRC. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Rohde wrote:
the STL is great but minimal at best
Thought I'd take a shot at answering you. :) I think it depends on what you're doing. (No wait, I KNOW it depends on what you're doing). I did an app that depended heavily on STL, I couldn't imagine doing it with a language that didn't support true and full STL capabilities. And it needed to be heavily optimized--not saying the same code wouldn't run as well in C#, but damn, it was nice being able to actually see the assembly output and be able to play with register keywords and other optimizations. That said, I do NOT miss the memory leak debugging nor the super-consciousness of always having to think "now, where am I deleting that memory allocation?". And frankly, I don't miss header files either, though when I first started using C#, I thought it was disguisting how the class definition and code were the same thing.
Rohde wrote:
because of the huge API you get for free
The API has never been a selling point for me. I hated MFC, I tolerate the .NET framework, and I basically write wrappers as much as possible for both, because they're so lame as it is. OK, not entirely, there's some great things, but they seem to be the more esoteric things for me. Oh wait, yeah, it depends on what you're doing. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
That said, I do NOT miss the memory leak debugging nor the super-consciousness of always having to think "now, where am I deleting that memory allocation?".
You still have to track all the other resources to make sure you call
Disposewhere necessary. You also need to ensure you're not accidentally keeping objects rooted - an application with a lot of static data members can be really bad for this. True, C# offers theusingblock, but C++'s destructors, for stack-based objects, are actually far more effective. Memory leaks actually have little effect on a running Windows program - ultimately you'll run out of virtual address space and allocations will fail; the speed that this occurs depends on how much memory is leaked and how often. By definition, you don't reference a memory leak, so the page containing the leaked memory will eventually be swapped out. The system might need to expand its page file to support this. Resource leaks, on the other hand, normally mean that you can't reopen the resource and you'll get errors from this. Now, finalizers do exist in the .NET Framework, and they will free resources if the garbage collector determines that the objects owning those resources are no longer in use. But you can't predict when this will happen, so you can get errors at some times but not others. This makes it very hard to debug. On top of that, the finalizers only run on a single thread, which is not one of the program threads, so you always have a potential threading problem if an object has affinity with the thread that created it.Stability. What an interesting concept. -- Chris Maunder
-
John Simmons / outlaw programmer wrote:
Of course.
Those who have changed the world had always done so.. but according to probability, you should have experienced more failures/ troubles than successes/ comforts by doing so..
L.W.C. Nirosh. Colombo, Sri Lanka.
I never fail at anything. Sometimes, things don't go exactly as planned, but gaining experience cannot be considered a failure.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Jeffry J. Brickley wrote:
welcome back to the fold!
Yeah, I guess we can't pick on John anymore when he's not looking. :rolleyes:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
I'm always watching. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Jeffry J. Brickley wrote:
I even have parallel versions of some STL containers
Have you got parallel versions of the STL algorithms as well, or does that fall out of your parallelized containers?
Stuart Dootson wrote:
Have you got parallel versions of the STL algorithms as well, or does that fall out of your parallelized containers?
I did an OpenMP version of a couple, but talking my boss into getting the Intel Parallel tools for others. It includes a lot of parallel assisting algorithms. I can't do it all, so I think the best method is to get Intel to help them and me as well through the parallel algorithm tools.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Hey, I'd rather be working for the Evil Empire than for this smelly hippy[^]. ;)
Tech, life, family, faith: Give me a visit. I'm currently blogging about: God-as-Judge, God-as-Forgiver The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Have you smelled him? *imagining someone verifying that the hippy is in fact smelly* Hmmm... too much time on yer hands if your going around smelling hippies. Or did I misunderstand and you were just being derogatory with another useless prejudiced stereotype?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
