[quote name='Fiddler' timestamp='1296679116' post='4768701']

Well frankly I don't have problems managing my own memory.

You just haven't worked on a big enough application. The underlying issues are still there, you just haven't hit them yet.


[/quote]


Oh trust me I have. My own personal project is quite big ...


[/quote]


Ok, what's quite big? 10,000 lines? 50? A medium sized project will hit it's stride around a hundred thousand lines of code. A big project will contain a few million.

... I don't have problems because I actually know how to control it and know how to properly use smart pointers and know when to delete and not delete it.

Once again, this is wasted effort. If fiddling with memory management floats your boat, then knock yourself out (to mix metaphors).

But wouldn't it be more fun to add an extra level or feature or polish the design?

[quote name='Fiddler' timestamp='1296679116' post='4768701']

Well frankly I don't have problems managing my own memory.

You just haven't worked on a big enough application. The underlying issues are still there, you just haven't hit them yet.


[/quote]


Oh trust me I have. My own personal project is quite big [/quote]

My own main project is not so big (just 60000 lines, roughly), but there's a lot of data-sharing. Keeping track of all the sharing would be near-impossible with raw pointers. Sub-components may insert new objects into parent-objects, and vice-versa, whole trees are passed into external components, data structures are extended, et cetera. Without shared_ptr's, I would really have a hard time keeping it correct while doing all the mutations. Which code in my codebase depends on properly managing specific objects? Which are forbidden to releasre objects? Et cetera. And if this paragraph is slightly chaotic, then that's by intention.

Of course, a lot is possible (see e.g. the kernel linux), but the more you automate, the more time you have for actual features your users are interested in.

and I don't have problems because I actually know how to control it[/quote]
But your users possibly don't. They won't help you as RAII would in exceptional cases. The number of flow-permutations in only a small sized project of <10KLoC is usually big enough already to make good testing a nightmare, and automating the right deletion moment even for exceptional cases helps a zillion tons.

Like I said the only thing that makes me not just to C# is due to my gui framework not being maintained because pretty much 99% are using the C++ one. My gui library handles pretty much all the memory for me that's why I don't really ever have to deal with memory leaks and I'm happy with it. the other gui's are just not available for cross platform since that's the development stuff I do. But let me be clear, I don't care if others think Linux or Mac doesn't have a high market. the people I target do so yeah. If C# offered a better cross platform api like Qt I'd jump but until then I'm sticking with C++ no matter how better C# gets.

Yeah that makes sense. If your programs are not for the Windows market, you can't just use whatever you want. That's not something that I can argue with. There is Mono but I've never used it so I don't know how it would compare.

[quote name='Garnier' timestamp='1296697060' post='4768823']
If you've never spent time hunting down a memory leak, that's great Seabourne. I imagine most of the rest of us have. I haven't had to in languages with automatic memory management and regardless of the other pros and cons, I consider that a benefit. I'm sure there are times when writing your own code to manage the memory is important, but I haven't encountered them yet myself. C# allows you to manage it yourself if you want to, and I imagine Java does as well, so I don't worry about encountering such a situation.

Now if Microsoft bothered writing an up to date that was much better and drop that ugly poor implementation of Hungarian notation it would be easier to use.

I believe this is what .NET is. It works for me, and I enjoy it a lot better than I did Win32 and MFC. Win32 was kind of fun when I first used it because of the mystery of it, felt like I was using what real programmers used, but eventually I discovered I could make the same gui program five times faster and with very little pain in .NET.
[/quote]

Like I said the only thing that makes me not just to C# is due to my gui framework not being maintained because pretty much 99% are using the C++ one. My gui library handles pretty much all the memory for me that's why I don't really ever have to deal with memory leaks and I'm happy with it. the other gui's are just not available for cross platform since that's the development stuff I do. But let me be clear, I don't care if others think Linux or Mac doesn't have a high market. the people I target do so yeah. If C# offered a better cross platform api like Qt I'd jump but until then I'm sticking with C++ no matter how better C# gets.
[/quote]

qt4dotnet looks pretty solid.

Yeah that makes sense. If your programs are not for the Windows market, you can't just use whatever you want. That's not something that I can argue with. There is Mono but I've never used it so I don't know how it would compare.[/quote]

Mono works fine and, in some cases, even better than the .Net runtime. As long as you avoid Windows-only technologies (WPF, DirectX), it is great.

[quote name='Seaßourne' timestamp='1296705128' post='4768860']
[quote name='Garnier' timestamp='1296697060' post='4768823']
If you've never spent time hunting down a memory leak, that's great Seabourne. I imagine most of the rest of us have. I haven't had to in languages with automatic memory management and regardless of the other pros and cons, I consider that a benefit. I'm sure there are times when writing your own code to manage the memory is important, but I haven't encountered them yet myself. C# allows you to manage it yourself if you want to, and I imagine Java does as well, so I don't worry about encountering such a situation.

Now if Microsoft bothered writing an up to date that was much better and drop that ugly poor implementation of Hungarian notation it would be easier to use.

I believe this is what .NET is. It works for me, and I enjoy it a lot better than I did Win32 and MFC. Win32 was kind of fun when I first used it because of the mystery of it, felt like I was using what real programmers used, but eventually I discovered I could make the same gui program five times faster and with very little pain in .NET.
[/quote]

Like I said the only thing that makes me not just to C# is due to my gui framework not being maintained because pretty much 99% are using the C++ one. My gui library handles pretty much all the memory for me that's why I don't really ever have to deal with memory leaks and I'm happy with it. the other gui's are just not available for cross platform since that's the development stuff I do. But let me be clear, I don't care if others think Linux or Mac doesn't have a high market. the people I target do so yeah. If C# offered a better cross platform api like Qt I'd jump but until then I'm sticking with C++ no matter how better C# gets.
[/quote]

qt4dotnet looks pretty solid.

Yeah that makes sense. If your programs are not for the Windows market, you can't just use whatever you want. That's not something that I can argue with. There is Mono but I've never used it so I don't know how it would compare.[/quote]

Mono works fine and, in some cases, even better than the .Net runtime. As long as you avoid Windows-only technologies (WPF, DirectX), it is great.
[/quote]

Doesn't seem to be up to date, 2 versions behind. Yeah I have used Mono and it is quite nice. Though sadly their documentation is half completed and the IDE isn't all that great =\

Yeah, yeah, yeah, Microsoft, the evil empire, releasing software for free just so we all get infected then using their market position to release a technology that allows for cross-platform development and then creating MSIL purely to try to make life more difficult for programmers.

Then they had the audacity to release all their pro tools for free, while only expecting people to pay for the team features, given that if you are in a team you probably already have funding.

Come on. Kill these threads. I'm personally very grateful that I can use VS for free and if I really wanted to cross-platform develop then the open nature of MSIL would probably seem my best bet.

(Just because I can't say Ubuntu doesn't make my opinion worthless).

I should make a video on youtube that starts with the quote 'Trust Me, I can manage my own memory!", followed my a non stop montage of memory leaks, blue screens, general protection faults, games that were released in a state that they could only ever crash to desktop, buffer overflow exploits (the entire C standard library needed to be deprecated and replaced with safer alternative functions to remedy this), air traffic control failures, road sign failures, etc, etc, to this music.

c# here. because i CAN MANAGE MY OWN MEMORY, because i CAN write my own containers, because i can write my own file handlers for stuff like xml, because i can write my own database like interface and stuff. but i don't WANT to. oh, and strings, too. i want to get my stuff going. and my stuff is an end product, not a library or tool for other programmers.

oh, and, because i know that i'm not perfect, i know i would do errors with all of the above listed stuff. and those might be hard to trace. memory leaks are one of the biggest issues in the computer industry since years, source of bugs, crashes, hacks, viruses, etc. knowing that i will not be able to 100% prevent it, i prefer to have a compiler/language setup that i know it will.

Almost everything you can do in C++, you can do in C, but just requires a bit more effort.

Yeah thats the point most of the stuff is actually easier to achieve with c++.
And i really don't get why a c programm is easier to maintain.

I've used both C and C++, but prefer to restrict myself to the C-like subset of C++ with maybe a few C++ specific features here and there. I don't subscribe to the thinking that "if you're not using STL/new and delete/etc you're not using C++" and I've seen enough C++ code that focusses more on designing pretty class structures than on actually getting the job done.

One reason I can think of to prefer C is that it compiles faster.