First let's take a look at the answer that defines https://pt.stackoverflow.com/q/23103/101 . Much of the question is already answered there.What would in fact be this abstraction and how can I apply it?The abstract is to isolate something from the whole. It usually applies as a form of generalization, parametrized or not. So something you would have to use in a complex way one or more times you put in a place and there exposes only a simple way of use.How does abstraction influence the process of creating functions?The function is an abstraction. And I'm not just talking about computation, mathematics is like this. All you do with functions (and we do little at school because we only learn to solve easy problems and tights to exercise the basics) you do without functions, but with functions it becomes easier to understand, can isolate certain parts of the problem, encapsulate the complexity in a fixed location and is enough https://pt.stackoverflow.com/q/120931/101 . You solve once a problem and no longer have to worry how it should be solved, just know how to consume the function, and although it should not be the reason, it can decrease the typing.Even if you will use only once can be useful to give more semantics to name better something you are doing or to just hide the details of how the solution was given. The primary reason we use a function is to always hide the complexity of what we are doing. Secondary is that it would be to avoid mistakes by having to do again or have the same implementation in two places, which complicates maintenance.Another reason to use abstraction is to leave flexible, so one day you can easily change an implementation without consumers knowing that it happened, so it gives flexibility to change the way to do or even the technology used under the cloths.It is common, but dangerous, to create an abstraction to prevent a possible change. So the person uses, for example, PDO because one day she may want to change the database. But the PDO is full of https://pt.stackoverflow.com/q/354926/101 , so it doesn't work so well. When the solution is complex it is common to have leaks and this is a warning sign to think if you should use this abstraction. And you never exchange database And the PDO is not so well implemented so you pay that price.Already you control the cents of values in an abstract object can be better than dealing with it manually because the amount of cents can change or even the way to deal with it can be different. Other than that there are some formulas to deal with that which are not simple and will be very used, without abstraction runs the risk of making some mistake, having to type more, do not compose so well with other things (but if you do wrong can happen otherwise). Creating a data type for money is a good abstraction.Why don't you do that?x > y ? y : x Isn't that simple? You read that, you know what's on your face? And if you read like this:Min(x, y) Do you know what you do? It seems much easier, this function only encapsulated the expression above. You gonna change one day? I doubt it. Is it really hard to know and write that? Not so much, but it might end up missing the signal or making another mistake. Mainly you can use somewhere that mixed can seem like something else if you forget parentheses, and give another result. You should think about the expression like this:(x > y ? y : x) And relying on what was inside could cause some unwanted side effect.Function abstraction is just that, realizing that a problem should be encapsulated in a function rather than being used directly.Want an example of exaggeration? forEach(), she does basically this (pseudocode):forEach(objeto, acao) { for (var i in objeto) acao(i); } forEach(objeto, (x) => print(x)); //chamando Without abstraction would be:for (var i in objeto) print(i); https://github.com/maniero/SOpt/blob/master/Portugol/Abstraction.ptg .What are the main benefits of it?I don't know if I can add anything here I haven't said in the previous item. It seems to me that decreasing the apparent complexity and avoiding duplicates are quite obvious advantages.The orientation to objects hinders this abstraction?OOP is a form of abstraction, and using abstraction is part of https://pt.stackoverflow.com/q/215679/101 . What I meant there is that OOP is the modinha, the people are very worried about it and no longer care about the basics that is creating good functions. Some will say that OOP is also to create good functions, but read material on the subject and see if any speaks in detail about it. In general they are only concerned with the general structure and give silly examples.It is not that OOP hinders, but it badly used hinders, like any other technique, after all everything in exaggeration is bad, the remedy turns poison. As people were blinded to a way of doing things forget to learn the other ways and do not remember that there are simple and useful solutions without being OOP.In fact, abstraction and encapsulation are confusing terms, but that gives a lot of story... Abstraction is not and cannot make the application more complex, but many people are doing it.How many times do we not see questions here that one cannot make this basic organization?People are so used to giving ^C ^V, follow formulas, reproduce patterns, use what others have already done, that they don't even think that everything could be more abstract. The amount of lines people write today is much bigger than they should. And the more lines in code the more complicated the code base is.

NomenclatureYou use English names (textFieldTempoDeEntregaMin) and in English (isSmallerThan). This is not a big problem, but it leaves the project ugly. When I give maintenance in a project that mixes nomenclature styles, I get the impression that it was made "in the thigh".Consistency in abstractionThere are auxiliary methods that work with less specific types, such as isNotEmptyNorParsableToInteger, and others working with very specific types, such as isSmallerThan. This is similar to the smell code called https://refactoring.guru/smells/inappropriate-intimacy . Choose to work with less specific types whenever possible, this will allow you to reuse these methods in various different contexts.Efficiency and Separation of responsibilities part 1You call the method Integer.parseInt often. Let's say the method parseValidTime be called with the parameter "42":The first conditional calls the method isParsable, which in turn calls Integer.parseInt.The next parole directly calls Integer.parseInt.O return also calls Integer.parseInt.There were 3 consecutive calls passing exactly the same argument! You can greatly improve this logic. Example:private static int parsePositiveInt(String strValue) { int value = Integer.parseInt(strValue); if (value < 0) { throw new IllegalArgumentException(); } return value; } Notice that I removed the references to the word "time" and the call to showMessage. The fact that this method is used in the validation of delivery time is entirely irrelevant to the method itself. Now it has become reusable and you can apply it to any other piece of code that needs to convert strings to positive integers. Example of use:private void jButtonSalvarActionPerformed(ActionEvent evt) { int tempoMinimoEntrega; try { tempoMinimoEntrega = parsePositiveInt(textFieldTempoDeEntregaMin.getText()); } catch (IllegalArgumentException ex) { showMessage("O tempo mínimo de entrega deve ser um número inteiro positivo"); return; } // ... } In fact, the method parsePositiveInt should not be declared within the screen controller.Architecture and Separation of responsibilities part 2One problem that jumps in the eye is that you've mixed enough business rules with data presentation. In javax projects. Swing is very common that happens, unfortunately. I strongly advise you to model your application using MVC (or other similar pattern), exactly as we do in web applications. The only difference, in case, would be that the view is not an HTML code, but rather a Java code.The controller and view do not need to know that the minimum time should be less than the maximum time. This is a particularity of your business, not the screen, so this should be done by a class specialized in validating business rules regarding delivery (e.g. a class called EntregaService).With this separation you can use a unitary test framework to test business rules alone, and make the code less confusing.Answering questions raised in comments" Opte for working with less specific types whenever possible" looks like a good tip, I'm curious where/how you learned itBy experience and because it's natural. Class hierarchy exists for a reason: Abstraction. Imagine if the method System.out.println did not accept one Object, you could not use it to print class objects that you created. Due to the fact that all classes inherit Object, this method accepts any object.As for calling a method several times, what would be the harm in it?The greatest evil is the loss of performance. You could save the result from Integer.parseInt in a variable and use the variable instead of sending Java to convert the string again and again.in parsePositiveInt() does not take into consideration that a time can be null and that it is better that the method does not throw exception (in my view an invalid user input is not so exceptional so, it is almost expected)The method Integer.parseInt launch IllegalArgumentException if the past argument is null. That means try-catch that I did inside jButtonSalvarActionPerformed You're behaving that case.

According to the definition already existing there, abstraction is to hide details, it is to generalize a solution where the mechanism is more hidden and give only a contact point and a contract on how to communicate with that.The leak of abstraction is something that is not but should be hidden, that who will consume should not know or have to deal and end up having to do it. Then there is leakage when the consumer has to deal with things that could have been hidden from it without prejudice.Right dosageIt's very difficult to do something that doesn't leak. I always talk about how hard it is to create the right abstractions, or leak it or we blind too much. The example of the question is one of the most common abstractions that we too armor. We create complications to have something abstract that never needs to be used in fact, the database never changes.But it is worse, who does not know how to abstract correctly, and almost nobody knows, tends to create a number of problems. We see in codes here on the site people want to abstract the database, they don't even know why they are doing this, but they do naively and create difficulties, introduce bugs trying to reproduce the concrete in abstraction, only who made the concrete knew what he was doing.You don't think you can get any worse? If she doesn't know how to do that well, she leaks specific abstractions, and some details end up not being abstracted, then it is realized that it was a bug, but since it was not properly abstracted it is not possible to correct it without breaking all that it had written, and you have the worst of both worlds. In many cases do not abstract, although it is a complete leak, it may be better than punctual unwanted leaks, but that you do not notice. A conscious leak can cause less harm.It is common for leaks to appear in new versions. You realize that abstraction is inflexible and does not solve all the cases you imagined would solve, there almost always the solution is to leak an abstraction to pass over it.Frameworks are abstractions. As they don't solve it all end up having to let you go over them. So libraries are usually more consistent. Frameworks they are known to wander as madmen, because they propose to solve things they cannot without losing flexibility. People don't even realize they're leaking all the time, even the most basic things of them. What is not a problem in itself, at least not a greater than it would cause if it eliminated abstraction.Trying not to leak can bring other problems. Failure to leak can complicate the internal code of abstraction or even for consumption. More and more we see people so worried about this that they produce real freaks.One of the biggest shortcomings of programmers nowadays is not knowing how to abstract things, with this ExamplesI won't talk about what's already in Joel's article. link down.Exceptions tend to be leakage of abstractions in many cases, as far as they are well used.Manual memory management is a leak, the garbage collector is the right abstraction. But there are cases he fails, there is leakage. You have to adopt certain code patterns to avoid pauses is a leak.If the compilers were good even they would not require us to know how to do a lot of things, especially to get performance.Having to convert a textual representation of the number to number is a leak. We know that attempts to resolve this created aberrations in languages.I liked the example given in https://stackoverflow.com/a/6448753/221800 . The car is full of abstractions to be easy to drive, imagine you have to control the car differential in hand. A manual exchange is an abstraction leak, you have to take care of a car operation mechanism that it should take care of alone. Daring arrow is a necessity nowadays, but shouldn't it be automatic when we start turning the wheel more strongly even if it's late? Was the traction control a way to end an abstraction leak? Is only lighting a light indicating a problem not a leak of abstraction? Or you don't even show anything and you have to realize on your own?Did you notice that it is debatable or not what is leakage? The steering wheel is not considered leaking because it is the minimum way to communicate with the car to say what it should do. But the concept can change because we'll soon have cars where you say where you want to go and it takes you there with no major concerns, but today it's a purposeful leak to not complicate the whole and make the project impossible. Not being possible to do different is no excuse to say that there was no leakage, it is just just just just just just to accept it. And you realize that we can ignore a leak because we don't think you have any other way of doing or that you don't have to have an abstraction there?UXHaving to know how to use Git or SVN is an abstraction leak with the user. I should only know that I want to control versions, not the details of these tools. Imagine how many things you make your user do that the system could take care of alone in the code. Abstraction leak at another level affects the user experience. Why do you think people use the phone better (less my mother) than the computer?Banks and other sectors are increasingly leaking abstractions from their services, one of the reasons for either reducing prices or increasing their profits. And "hope" is who can do only the second by increasing the load upon you.Programming is very difficultEspecially object-oriented that promises something difficult to deliver, because http://wiki.c2.com/?AllAbstractionsLie . And http://wiki.c2.com/?TheMapIsNotTheTerritory , there is no way to reproduce the territory there.All abstractions lie -- including this oneI live repeating that http://wiki.c2.com/?CritiqueOfUseCases enough to create good abstractions, something very preached in OOP. So we need to let things looser to make it easier to change later, and OOP complicates it. And so OOP goes better when we do not reproduce the real world and yes we create own abstractions. Even in GUI where OOP goes well, its abstractions are terrible, so much so you can't map the GUI well from one platform to another.See https://blog.codinghorror.com/all-abstractions-are-failed-abstractions/ .FinishingO https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ was written by another of the creators of this site. At least he warned everyone about the problem.Things https://pt.stackoverflow.com/q/195461/101 are so or more important than abstractions.Simplicity eats abstraction in breakfast. When abstraction generates simplicity it is good, when this does not occur leaks exist or will arise. The complicated generates leakage.I hope analogies and example out of programming help understand abstraction and its leakage.

I would do the following:public class Pergunta { [Key] public Guid PerguntaId { get; set; } [ForeignKey("OpcoesResposta")] public Guid RespostaCorretaId { get; set; } [Required] public String TextoPergunta { get; set; } public virtual OpcoesResposta RespostaCorreta { get; set; } public virtual ICollection&lt;OpcoesResposta&gt; OpcoesRespostas { get; set; } } public class OpcoesResposta { [Key] public Guid OpcoesRespostaId { get; set; } [Required] public String TextoResposta { get; set; } } It goes more by alternative 1, with some nuances. You should put something like this in View:foreach (var opcao in OpcoesRespostas) { @Html.RadioGroup("RespostaEscolhida", opcao.TextoResposta, opcao.OpcoesRespostaId) } And in Controller:public ActionResult Acao(String RespostaEscolhida) { ... } The selected value on screen will be filled in RespostaEscolhida. EDITSupposing I'm actually getting a survey coming from View, I would make one ViewModel where I have in it a set of questions:public class QuestionarioViewModel { public ICollection<Pergunta> Perguntas { get; set; } } O Controller would have Action to initialize the questions:public ActionResult Questionario() { var questionario = new QuestionarioViewModel { Perguntas = context.Perguntas.Take(10).ToList(); } return View(questionario); } A View would have something like this:@model SeuProjeto.ViewModels.QuestionarioViewModel foreach (var pergunta in Model.Perguntas) { ... } And finally the Controller would receive:[HttpPost] public ActionResult Questionario(QuestionarioViewModel questionario) { // Coloque aqui a regra de negócio, obtendo o resultado dentro de questionario.Perguntas }

http://pt.wikipedia.org/wiki/Abstra%C3%A7%C3%A3o_%28programa%C3%A7%C3%A3o%29 has its sense derived from http://pt.wikipedia.org/wiki/Abstra%C3%A7%C3%A3o , which is "isolate an element to the exclusion of others". Its use is much like that done in mathematics - instead of solving a problem for a very specific domain (e.g., it had four oranges and ate two, how many do I have?) to turn this problem into a more general problem (e.g.: x = 4 - 2) and solve that problem, applying the resolution back to the original problem.Giving a concrete example, how do you implement a sum?var resultado = 0; for ( var i = 0 ; i < array.length ; i++ ) resultado += array[i]; And how do you implement a production?var resultado = 1; for ( var i = 0 ; i < array.length ; i++ ) resultado *= array[i]; Note that potentially exist N problems of the same format: it begins with an initial value, an operation involving this value and an input element, the result of the same combined with the next element, etc., until the end result is reached. By abstracting the problem in this way (i.e. isolating the common characteristics, parametrizing the specifics) one can reach a https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce :function reduce(array, fn, valorInicial) { var resultado = valorInicial; for ( var i = 0 ; i < array.length ; i++ ) resultado = fn(resultado, array[i]); return resultado; } var somatorio = reduce([1,2,3,4,5], function(a,b) { return a + b; }, 0); var produtorio = reduce([1,2,3,4,5], function(a,b) { return a * b; }, 1); Another common example in everyday life is the use of types and subtypes, and the creation of "generic" functions that act on various types. Instead of implementing a specific solution for a type of data, one is implemented that meets different types, thus avoiding the duplicate of the code.Why this is important, it must be evident. How to achieve in practice, there is already a question of mathematical reasoning: to try to see similarities among the various concepts we deal with, to describe this similarity in the form of a new concept (more general, or more abstract) and - according to the resources offered by its platform of choice - to develop solutions aimed at this new concept, so as to be easily reusable by the most specific concepts.Of course, much of this work has already been done by others, so that the more knowledge you have - the more contact with third-party work involving abstraction - the easier you will have to identify in practice when an abstraction applies to your case, so as to develop/reuse solutions in this sense. (Do what I say, do not do what I do: study mathematics!)Abstraction LayersFinally, not directly part of the question but rather related, there is the concept of "abstract layers": often to solve a "high level" problem is desirable if you can ignore the "low level" details. For example, when writing "create a window" (e.g.: new JFrame()) You ignore all the work that the computer has to draw the geometric shapes that make up this window, the treatment of the input (keyboard, mouse) over this window, etc. You are reasoning at a high level, and having to think about these details all would just get in the way.On the other hand, those who create a library to implement a graphical interface, do in a very generic way, without worrying exactly what it will be used for (not as will be used, this is part of the API, but the specific windows that will be created). At the same time that at this stage it is ignored how the computer will draw the pixels on the screen, as the main memory will interact with the video card, etc. This is the work of those who create graphic libraries (such as OpenGL and DirectX).Programmers that focus on end-user solutions in general are at the highest abstraction level (i.e. using the tools available to meet a real-world need), but do not always have the tools at the best possible level. So if you realize that you are (or go) repeating yourself too much in building a system, consider that it may be interesting to abstract a little the problem you are dealing with - creating solutions for this abstraction, and then applying them to the real problem. This is to use abstraction in practice.

Thinking only in Object Guidelines, this is not possible. The Something method receives the Animal class, so this method has to know what to do with this type of class, the bark( method), belongs only to Dog and not to Cat, so if your method receiving Animal, receive the Cat class, but try to call the bark( method), it would be "lost", so it is not possible to do what you want correctly.What you could have, is a method "Acao" for example, where in the Dog vc class would implement the code that makes latir and in the Cat class you would implement the code that makes piss for example. Your method would call animal. Acao() and each implementation of Animal does what has to do...If your method already knows it will call the "bark()", then, in theory, vc already knows it will receive a dog and not an Animal and there makes no sense the method to receive an Animal as a parameter.You can do this that you want as stated in the comments, using equals and converting the object, however, you would break the Open/Closed principle, because every new implementation of Animal, vc would have to add a new "if" in your Something method to only treat this new implementation.

We can say conceptually pointers are abstract.In fact almost everything is abstract, concrete even only the excited electrons (the delira people when I speak so :D) circulating by static electrons in computer materials. The bit is already an abstract concept.Things are more abstract or less abstract, but some level of abstraction always has, at least in things created by humans. We have to always consider abstraction levels and not if it is abstract or not. Even a word that indicates something is already a https://pt.stackoverflow.com/q/23103/101 .Pointer is a concept that a human created to understand that we have a https://pt.stackoverflow.com/q/181032/101 . The most common is to be in memory, but not to be, we have in other contexts, for example one can have a pointer in database (which if people knew how to do could make some economies).In memory, the most used concept in programming, in fact a pointer is represented by a memory address.From the abstract point of view (i.e. from the moment memory is abstracted) no matter whether physical memory is linear or not. The abstraction serves precisely for this.To measure the level of abstraction is not always easy, it becomes subjective. What is the minimum and maximum abstraction? Are you going from 0 to 10 or from 0 to 100? Or that's not even how you get. We don't have parameters for that.We can say he is https://pt.stackoverflow.com/q/56470/101 .And the mechanism is a more abstract way of accessing memory.Abstrately should not worry as much as they are implemented, but the lower the most important level is knowing this.I don't know if you have that dichotomy that the question leaves. Or even if it has relevance. But I'll try to answer.But it even exists in Assembly, it is a guy who handles something that the processor understands, as well as the numerical types. Can you understand the level of concretude? He is more concrete than string, a date, or even a array which is more abstract than a pointer, even because it depends on the pointer to exist.In the exposed form it seems to speak of the guy who is a pointer, not just the mechanism. And then doubt whether he would be a concrete guy or a https://en.wikipedia.org/wiki/Abstract_data_type makes sense.My understanding is that it is more concrete, it is a concept that exists on the computer, it is not the same as a int or long. It is not another type composed solely of an integer, it has its own form. This is the opposite of what happens with a date for example that has the amount of seconds or fractions and seconds represented as integers or other numeric type "concrete", or the interaction between numeric data that represent years, months, days and who knows hours, and other fractions of days.One int can be interpreted as a pointer? You can, but that's circumstantial, not always that's true."Type of the pointer"Another question has been asked which is completely different from what was asked in the title, perhaps because does not understand it.Differing to what the pointer is pointing at has nothing to do with the pointer itself. To tell what it points out is important to know the size it is pointing and to know how far it should access that information, or even calculate the virtual position of memory of a sequential structure (array).The compiler needs this information to make choices and generate a suitable code, and some cases force typing (not so much because C has weak typing, but some implementations have options to strengthen typing and becomes more important yet).The question malloc() It's just a case of what I just said, but it's https://pt.stackoverflow.com/q/195461/101 to the pointer or his type, he does not need to know the size of the pointer or his appointed type.O https://en.cppreference.com/w/c/memory/malloc Aloca Bytes, always, the sizeof can be used to catch the size of something. O sizeof can be used to catch the size of the pointer because depending on the architecture the size of it is different. But it doesn't make sense to take the size of the pointer according to the type, because the size of the pointer does not change, changes the size of the pointed object.sizeof char (people always use parentheses because they think it's a function, but it's an operator) doesn't make sense because the language specification says it's guaranteed to be 1. Those who do this are usually a terraplanist, think that one day can change D.Accepting something doesn't mean anything, C accepts almost everything. Alocar 1 byte (char) is as accepted as allocating 4 bytes typically (int, may be another size), but allocates very different. That's nothing to do with a pointer.The type of complete data when using pointer is "point of something", it's not just pointer, never, and it's not just the guy. Can make a pointer for nothing (void), which in practice means that it is for anything, it opens hand to the size of the object pointed out.In C hands tend to be relatively safe, if use right, in Assembly is pure mathematics, but if they were generated by a compiler C as they will work perfectly.Just remembering that the C specification, not only in this, is well open to the implementation do as you wish, but in practice, that's what I explained here.It has interesting add-ons in the comments above and below.

What are Zero Cost Abstractions?It is the ability to create an abstraction, to have a greater expressivity than you are doing, without incurring in cost because of this.In general when you create an abstraction and hide an implementation detail often use some mechanism that imposes some memory or processing cost that is not always noticeable, but if you measure it is there, and accumulating with others in large quantity can make the application be perceptively less efficient.It is a noble goal and I like it, but it is rare to achieve effective result.Origin of the termIt is very rare a language to achieve many good abstractions at no cost. What is done is this cost to be reduced, or to be obvious, or to pay only if to use ease, but to have a way to do, even more complex, without cost.What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.--Bjarne StroustrupThe first sentence of the quote gives a lot of room for much to be accepted as ZCA. The second shows the hardest side to get.The term began to be used more strongly by C++ (given to perceive by the quote above the creator of the language), including is part of his philosophy. And marketing. I am not saying that C++ is not efficient and often does not reach the goal of zero cost abstraction, but she reaches less times than it makes it look. There are even articles and lectures on the subject, not everything is so cost-free, even comparing only with C.There are several C++ mechanisms that impose cost and when they launch it they say it is cost-free. In general it is very efficient, but at no cost it is usually exaggerated.For example C, it has many features that we can say that are zero-cost abstractions, this is given whenever that code produces an exactly equal Assembly you would if you had to write it in hand and with the ability to do as optimized as possible. If you can't, if you put an extra instruction, if you need to occupy some extra space, if you have to opt for an instruction that costs more expensive, if the required order is one that does not privilege processor optimizations at the time of execution, then the abstraction cost was not zero.I have seen definition that says the meaning would be:costs are well defined, predictable and more or less controllableThat's a fallacy. Even when you consider that you can only see the cost you will pay is already ZCA is still very complicated, I will quote examples that costs are not so obvious unless you know the implementation details, which killed part of the advantage of being an abstraction. So many people think of the term as a cake recipe and not a questionable fact. The term is not a scientific norm, it is a market expression.If that were true then almost all languages would have ZCA. It is true that C is a language that this is quite true (I will not speak of Assembly because there has no abstractions that generate an extra layer of nothing), but not 100% true. All others have much lower percentages, although some more than others, C++ and Rust case, but not in all mechanisms.If the term was that last quote then it should be Controllable Cost Abstraction or something like that.C compared to C++ or RustSome will say that you wouldn't do anything in your hand more efficient than that, reaching the same goal, since the goal is to have something easier to use. This may be true, but it is an abstraction and has a cost.You can say that you are not required to use that and only pay if you use it, you have another more efficient way. It's also true, but it can't say that that mechanism is cost-free, it can still say that language can be cost-free, but it's only truth-free if programming as if it were C.Even this is an exaggeration because the C++ compiler generates a slightly heavier code even if it only uses C mechanisms. It is minimal, but it is not zero.The same happens with Rust, although in some things she is closer to C than C++. But it also has less powerful abstractions, Rust leaks more abstraction than C++ (if you want can leak in C++ too, and if you do it tends to get more efficiency in many cases).That's why language comparison tests don't help much, you can write a very efficient Rust code without using abstractions and a less efficient C++ using abstractions.ExamplesstringAn example is string C++'s, very powerful and easy to use, but you can't tell that it is always free of extra costs in relation to what is used in C. It usually makes a dynamic allocation that is very expensive without you or knowing (not always does). And it has optimization that makes it increase cost at another point.Most C++ implementations occupy 24 bytes no matter what they use. Some think it should occupy 32 bytes. With it small strings with even a certain size fit right there and everything looks great, except for the fact that you always have to analyze if it is a string short before doing something. If she's big there has the pointer to the place of heap where in fact will be string. That sounds good, it has interesting gains, but it has costs. That's a good abstraction, but it's not zero-cost. It's weird, the guy can be by value or reference. If you have multiple short equal texts you will have multiple instances, but if they are long it may be the same object. Can a simple reference be 24 bytes? WTF! Put that in one array and see the damage you do. Neither Java or C# or languages script They are often so inefficient at that specific point.And it's very used in places where you need to calculate one hash, you do not pay anything if you do not use, but if you use it will pay a higher price because you will have to calculate every time you need it, an indecency for a language that presses for performance.At least it is so in the default implementation, if you don't use it at all of this has cost, you can do your without problems and that you don't have the unwanted costs, but you will also have trouble using it with any standard library that expects you to string standard.Have you heard that in computing, as in life, (almost) everything is tradeoff?C# in 64 bits also occupies 24 bytes at least for a string (without counting the pointer in the original object of the reference(s), and grows fast as it adds characters. It is great abstraction, but it has cost, always requires dynamic allocation, but if it shaves, outside that there is no optimization for short text, it is more efficient than C++.Java arrived to have 40 bytes in 32bits, I do not know how it is today, but this is absurd, in many cases to store 1 or 2 characters (it will be larger).C has nothing of this cost, you decide where you want to allocate, although some say you should never allocate in stack, or even within a struct (some compilers do not even allow), everything great, but it does work, causes error, not always the programmer achieves the best efficiency, for example it can store as value and at some point may have to copy the data that can be too big, to compensate, or use a reference where causes licking.Not to mention the fact that you have to spend the size along with the text to make sure and be efficient (not the way we see it around that Comparing high-level languagesLanguages script connect little to typing, to where the data is being allocated, if you access it by value or reference, so they are easier, everything is abstracted and you pay for it, and you have no choice, have choices makes it difficult.And this generates more costs than people imagine, all data accessed is a potential danger, always needs complex processing only to take the data (some cases there are optimizations). For example, these languages do not usually have objects but rather structures https://pt.stackoverflow.com/q/429851/101 that pass by objects, this is a cost in various aspects.Java has already opted for a path that you have more type controls, from where it allocates, but well above. Not the same C#, especially in the newer versions that control is much higher, you may not pay certain costs if you use the most efficient mechanism.In C++ and Rust this goes further and gives more freedom of choice, eliminating much of the costs, and how it competes with C, if you choose this subset of language may have less cost yet, only losing, in some cases, to Assembly. Not all decisions are as you would like for a certain scenario.You can give up abstraction does not indicate that it has no cost, but some people think so.Is it something the programmer needs to know how to use or is it indifferent?Yeah, and no. A good programmer who cares about it should know and ideally he should research and see if he really is fulfilled what was promised, I already said he has a lot of marketing on it.If you need a lot of squeezing everything you can, you need to understand all the costs of all the mechanisms you're using and you can do it in a better way to achieve the ultimate goal of maximum efficiency. Not everything you're doing needs this.But who has to worry more is who makes libraries for others to use in an environment where they are cared for zero cost abstraction. If your library has no zero cost, no applications that use it, including other parts of the library will cost zero, it is contaminant.Is it really a 100% positive point?As far as I know, he himself, yes. Of course, if it does right, and if it is true and not illusion, or if it exists at one point but harms another.Being ZCA at one point can prevent being at another, see the example of string C++ I talked about. Note that others have some costs to avoid certain costs. But you can always claim that you can do as it is in C and have zero cost or make a type of yours where you have a cost only in what you really use. It's true, but that's worth any language, in C# you can create your type string with the commitments you want, the difference is that the normal type goes along even if you don't use it, although this will be true in almost all languages, only gives to give up a type so present if you give up everything that the standard library has.Is there no undesirable effect on the use of language by possessing this feature?Generally and clearly does not have, but language tends to be a little more complex to achieve this, I do not know if it is something bad, and even if it is, it is still something that may be necessary for other reasons.The building of the library is usually much more complex and the internal code is usually quite confusing because of this. If it's not such a confusing code, or language is too good, until it's true, or it doesn't cost zero in fact.It has compilers that make exceptions in the compilation when you know that there you need to whim to have a zero cost or at least lower than the normal one he would do. This is not always good, but gives an interesting advantage, it is a way not to create complexity in language to treat very specific cases. A typical case can be a string, a very used type that requires out-of-normal optimizations, and that can be easier because it knows in depth with what it is dealing with.You can write much more about it, almost every sentence opens the door to new doubts.