|
yeah something like that.
I just wish there was a way to do unions whose members had nontrivial albeit zero argument constructors but I understand why there's not. It would just be so convenient.
Real programmers use butterflies
|
|
|
|
|
What's this with ICloneable?
It adds a Copy function which you have to implement yourself.
Whether that's a shallow or deep copy or anything in between is up to the implementer.
Microsoft advices against the use of ICloneable (in public APIs) as it doesn't do anything and rolling out your own IDeepCloneable and/or IShallowCloneable would be more clear.
From the docs[^]: "Because callers of Clone() cannot depend on the method performing a predictable cloning operation, we recommend that ICloneable not be implemented in public APIs."
Maybe you're talking about Object.MemberwiseClone Method (System) | Microsoft Docs[^] (which returns a shallow copy)?
|
|
|
|
|
Ah, I wasn't aware of that fine print.
Well I always do implement my ICloneable as private and implement an ICloneable<T> type instead which (in my code) is always a deep copy. And "clone" really should imply that anyway.
And technically, what actually constitutes a "deep" copy is always up to the caller anyway. Some fields in a deep copy may indeed be shallow copied, like if the object uses string pooling or something, and I find Microsoft's docs to be characteristically trite on such matters.
Frankly, I know if I call ICloneable<t> I'm getting the counterpart to MemberwiseClone. That implies a deep copy. And as I said, what that is is always up to the caller in the end anyway. What's expected is a "copy" of the object, but again, when you throw things like pooling into the mix, what that means might be different than what you expect.
Real programmers use butterflies
|
|
|
|
|
Wow, that was some advance stuff here I'm not there yet, but will keep it in my head. I will surely have good use of that knowledge if I advance to that level someday 
modified 3-Jun-21 21:01pm.
|
|
|
|
|
Well, that's problem for me with those modern languages that I'm still learning and they do stuff for me. At my college we are not allowed to use libraries that's why it's a blessing to read c++ books because they teach how to do stuff from scratch. I need that for my school Of course if I start working as a professional I will be gladluy using those libraries, but today they are not so helpful because I'm not allowed to use them anyway so they just make me confused 
modified 3-Jun-21 21:01pm.
|
|
|
|
|
well if you're using C++ appropriately there's some amount of "libraries" that are part of the language and that mess is known as The Standard Template Library or The STL.
It contains things like std::string, std::map, and std::vector which you should really be using rather than rolling your own.
I say they are part of the language because, while not tightly integrated like VBs runtimes for example, they were designed with and to be used as part of programming in C++
I look at it this way. C++ is the language + the STL. The reason they aren't all rolled together is so you can modify it.
Real programmers use butterflies
|
|
|
|
|
Yeah that I can use At my college we can only use some basic Java libraries thatprovides for example String, equals and so on but Collections like arraylists and algorithms are totaly forbidden so I'm glad I could learn how to make some of those forbidden stuff from scratch by reading c++ books.
modified 3-Jun-21 21:01pm.
|
|
|
|
|
C++ has a ton of "collections" built into the STL. They're called containers though, but it's the same thing. Way more than Java or C# in fact. C++ has one of the best container packages I've seen for an imperative language.
Those books should be teaching you those. Hopefully your professors get around to it too because if you don't know them, you don't know C++.
Real programmers use butterflies
|
|
|
|
|
I only learn Java and PHP at my collegaue. I started to learn C++ on my own, because I wanted to read c++ books because they were more interesting. But still... Java relies mostly on libraries... but we are not allowed to use them. I mean most of them. Only arrays, scanner you get what I mean and of course GUI They want us to do all the algorithms from scratch, even in whole applications. Maybe they want to train our brains to be better programmers that way...
modified 3-Jun-21 21:01pm.
|
|
|
|
|
|
Hmm... intereesting. I thought it was all about OOP because I program in that way in C++ but I have background in java. Maybe that's why.
modified 3-Jun-21 21:01pm.
|
|
|
|
|
That's probably why. Buy Accelerated C++. You'll be glad you did. It will make you a better coder. It did me!
Real programmers use butterflies
|
|
|
|
|
When I have more free time in future I will surely read it Thank's. I love to read good books 
modified 3-Jun-21 21:01pm.
|
|
|
|
|
Because you can quite easily write a procedural program in C++. With real OOP languages (Java, C# etc.) you cannot do anything without creating a class first.
|
|
|
|
|
Only because 'one can do it' is not really an explanation. In c++ you can do things like "#define private public" in .net you can access everything using reflection.
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
No, that is the whole point. A proper OOP language begins with the class, and everything proceeds from there. Without the class nothing will work. In C++ the class is just an extra that you can use or not as you like. So you can write C++ code that conforms (more or less) to the rules of OOP, but you can also just ignore them.
As an example:
class Mainclass
{
static void Main(string[] args)
{
}
}
int main(int argc, char* argv[])
{
return 0;
}
|
|
|
|
|
No and no and no, all this _is_ _not_ the defintion of a proper OOP language. Even in ada (which is for me the OOP reference) you can do dirty things
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Then it is not OOP. Either the language follows the rules completely or it does not.
|
|
|
|
|
This is now a valid C# program:
using System;
Console.WriteLine("Hello World!");
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
Very interesting, but there is not much else that it could do.
|
|
|
|
|
Quote: but there is not much else that it could do
It's a real time saver - I bet I'll save at least 0.00000001% on my next .Net project
As for what else is new in C# 9.0 record types seems like a useful extension, with the same pitfalls as structs. Meaning it easy to loose many of the performance benefits through mindless boxing/unboxing.
Init only setters: seems to be useful for functional programming purists - Upside: objects are immutable so you can avoid explicit locking in a multithreaded program, downside: there is going to be a lot of lock contention related to the allocation of objects. So far I believe the downside is, on the average, far greater than the upside.
Pattern matching enhancements: Minor syntactic sugar … which has the potential to make some code more readable, but to me this:
if (e is not null)
{
}
is not more readable than:
if (e != null)
{
}
Native sized integers and delegate pointers: sounds interesting, but I have no idea about how much this will improve the performance of a program. Sounds mostly like stuff the JIT compiler would do for me anyway …
New Expressions: This is something I'm actually going to use.
Support for code generators: I have yet to use partial methods for anything, but have used class factories and virtual functions to achieve similar functionality in the past. This would certainly reduce the amount of generated code.
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
Apples and Oranges for the most part. C++ is a language. OOP is a style of programming. C++ is capable of performing OOP, but there are detractors as well.
|
|
|
|
|
I was a C/C++ programmer before I learned Java and found it quite straightforward. My starting point was The Java™ Tutorials[^], which I recommend. Do it from the beginning and don't skip sections that seem too simple, and it should make sense.
|
|
|
|
|
I don't like tutorials. I just want to read one book from the begining to the end that will answer my queestion "What's the purpose of this and that". The problems are that tutorials are there, the books are there but the answers to questions "Why to use?" and "When to use?" aren't there. A simple example is java interfaces. When I'm reading books and whatching tutorials this is what i get "Interface is a contract. And know what java number this and that allows better interface" Ehhh okey.... but what is it exactly and why should I bother to use it? I cmade programs without it so far and everything is tip top, so why should I use it now? What's the point? "Because compiler doesn't know if a method exist" So what? Why should I write a method in an interface and not directly in a class? No answer there. I check a book on C++... Oh, Now I understand. It's an attempt to go back to multiple inheritance that was thrown away by java inventors 
modified 3-Jun-21 21:01pm.
|
|
|
|
|