Differences between Wrapper and Library [closed] - c++

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am curious to know the differences between a Wrapper and a Library.
From what I have been able to find online I can't really see any major difference between the two. I often came across "Wrapper Library" or "Library Wrapper" and it makes it seem as if they are basically one in the same.
However, my assumption is that a Library is a collection of finely tuned functions that provide a means to accomplish a task that isn't part of the core functionality in the language.
And a Wrapper is a facade that makes it easier and quicker to set up certain functionality within your program so that you have less typing to do.
These two descriptions just make it seem like it's the same thing with different wording to me though.. so I come to you Stackoverflow,
What are your opinions and professional points of view on Wrappers/Libraries?
Sidenote/Background:
This question stems from my C++ Design Patterns Class I finished a month ago:
In my C++ Software Design Patterns class we had to create a Socket Library that took the WinSock Library and created a Thin(Or Thick, our choice) Wrapper over it. We then had to create two applications that used our library so that we didn't have to repeat the basic set up and tedious coding of the WinSock Library. I ended up with 100% on the project but wish to know more about the actual differences or similarities because I want to expand on this project in my personal time.

In general, I personally think of it like this:
A library is typically an actual concrete implementation of some functionality.
A wrapper is mostly just a layer of abstraction around existing functionality. It is only intended to offer a better, cleaner interface (or at least one feels more native to the language or technology it targets) to something that already exists.
Now obviously there are times when the distinction between the two is crystal clear and times when the line is blurred, so some subjectivity may be inevitable in the latter scenarios. In other words, what you consider an implementation and what you consider simply an abstraction can be ambiguous occasionally.
For instance, a wrapper can have argument checking functionality or better state bookkeeping that the underlying system did not have. If this is mostly to serve the correctness of the abstraction, then it this still leans on the side of the wrapper. If some genuinely new functionality is added, it starts becoming a library and could be called a wrapper-library.
On the other hand, a full-fledged library may not be a wrapper at all, in the sense that it may leverage an underlying system to offer some functionality, but without exposing any considerable part of that underlying system in any clean interface (other than the specific functionality it adds). This would be called a library, but most probably it wouldn't be called a wrapper.
(I should clarify that what I said is how I think of the matter in general, not specifically in regard to C++. If the C++ world has less ambiguous definitions of these terms, please do correct me.)

Library is an generic implementation of any sort of functionality. Wrapper is a specific implementation intended to provide abstraction to existing library.

Related

Creating containers c++ [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm wondering if creating my own container is very useful ? There are a few containers already implemented in c++ but what are the advantages of creating my own container ?
More information : I am a beginner.
Edit : can someone give me an example of what a Standard Library container can't do ?
If your intent is to learn about the containers and C++, by all means, go ahead and try to implement them. If you just want to use a container and it exists in the standard library, boost, or some other reputable library you have in your project, just use the library version. It's likely to be well tested and optimized. Other programmers are also likely to be more familiar with that container than something you roll out yourself.
A rule of thumb is, reuse code, unless you can do better and can justify the associated cost.
If you want to learn how to program, or understand how containers work, or everything related to them, then your own implementation of containers is a good practice.
However, large companies often also use their own containers, as they may consider standard containers and algorithms not optimal for their own tasks.
There are several non-standard containers in Boost, like the ones in Boost.Container or Boost Graph Library, so there's certainly some ground the STL doesn't cover.
Generally speaking, start with std::vector and check the other STL containers if it doesn't meet your requirements.
C++ Standard Library is a general purpose library for C++ programming language. In is designed to be well enough for most tasks you may encounter in your job. But sometimes it can turn out that some container from Standard Library does not fit your needs. This is the case when you can implement your own version of some container because Standard Library can't satisfy absolutely every need that can arise during your work.
I'm wondering if creating my own container is very useful ?
It could be.
My understanding of containers is template-s in C++ code
A simple example are matrixes. You may want to develop your own template<unsigned Height,unsigned Width,typeclass ElementType> class Matrix, and you would certainly call that a container. Remember that matrices of polynomial makes sense in mathematics.
A typical example is numerical scientific computations, related to representing huge mathematical symmetrical or triangular or diagonal or sparse (etc...) matrixes on various kind of numbers (float-s, but also bignums). Think of finite element methods computation.
The opencv library is an open source C++ library on computer vision which uses template-s. Download its source code and study it.
Another example is some heavy C++ software taking advantage of OpenCL (when that is available).
Or representing efficiently in memory a mathematical permutation between integers less than some given N. You may want to represent that as two std::vectors (one for the direct, another for the inverse mapping) inside your own template.
Some generic parsing libraries in C++ are heavily using templates.
The Qt graphical toolkit is coded in C++, is open source, and has template-s.
The tensorflow machine learning library has open source C++ code with template-s.
The Wt web toolkit is coded in C++, is open source, and uses template-s. You can download and study its source code. My opinion is that it has specialized containers.
The GCC compiler is coded mostly in C++, is free software, and uses template-s. You can download and study its source code. My opinion is that it has specialized containers.
A third example is garbage collection support. The RefPerSys project has templates...
A fourth example could be related to storing your C++ container in a database (like PostgreSQL)
Don't forget another approach: generating C++ code (like SWIG or ANTLR does) from some higher-level description. And be aware of the rule of five.
See also Autosar MISRA C++ coding guidelines.

What components are essential to a C++ project which are not found in a common library? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
For most C++ projects Boost covers a lot of ground component wise but often used solutions and idioms require some boiler plate or ground work. What do you consider so essential that you would have it in every project and thus have it in a small "library"?
Some things I thought of:
Singleton base-class (somebody will think he needs it, so he can do it properly)
ScopeGuard
Factory base-class
any_iterator
(The last two are in Loki but Loki has overlap with Boost and people are hesitant to use it.)
Edit: I might should add that I don't ask about the usual extensions of the standard library e.g. copy_if.
None of the above. In particular, definitely not a Singleton class, since the use of Singletons are typically an indication of a design flaw. In the past 15 years, I have never needed a Singleton class and all those that I have found in my travels were hacks or otherwise compromised the robustness of the system they were in.
Generally speaking, aside from a good, Standards-compliant compiler, a desire to never stop learning more about my language of choice and coding standards that don't restrict my movements, I have found that I need nothing in order to write complete systems.
Of particular note, over the past 15 years every job I've had has specifically forbidden the use of Boost. Although I use Boost in my own projects and in little tools I hack up, none of my production code uses it. I am a fan of Boost, but I haven't really missed it. And now with the C++0x support in VS2010, I miss it even less.
That said, over the years I have cooked up an #include library that I take with me wherever I go of useful little things and gizmos. It includes:
An exception framework
A version of sprintf that works with std::string
A high-resolution timer class which I use primarily for development, stress testing & debugging
An implementation of transform_if
An implementation of copy_if
And a few other STL extensions which I use very rarely.
My small library, that I carry along with most projects contains very practical tools:
assert utilities (release & debug assert with a user dialog with details and buttons for "start debugger", "ignore this assertion", "always ignore..")
Buffer utilities to avoid working with "plain" heap arrays (class HeapBuffer and class SharedHeapBuffer with ref counting)
logging facilities
UTF8 / UCS2 encode/decode
configuration utilities (class CfgValue with one-liner string-to-number/bool conversion methods)
some fast string to number and number to string routines
fast float to int conversion routines
explode/implode numbers/strings on separator utilities
ini file parser & writer
timer class and some quick&dirty profiling tools
mutexes, conditions, r/w-locks, multi-threading utilities (but from time to time I replace more and more of that with boost locks and thread utilities)
a lightweight messaging system "construction kit" (messages, ports, sender, handlers, sinks, dispatchers, routers, threaded sinks, threadpool sinks and so on)
None of the ones you suggested.
A singleton is a horrible antipattern, and the last thing I'd want in my C++ programs is more of them.
And if you use RAII consistently for your own classes, you don't really need a separate ScopeGuard class.
A factory base-class? What exactly would it do? I don't really see enough common functionality between factories that it'd be worth putting in a single universal base class.
And I'm not really sure what you mean by an any_iterator. :)
The things that are essential to a C++ project are the ones people put in libraries.
And if something is not in any of the common libraries, then it is because it is not commonly needed (or because it has to be customized for the individual project, so a library version has little value)
So your question could basically be rephrased as "what would be an obvious addition to popular libraries, which hasn't already been added to them", and the answer, just as obviously, is "nothing, because if the idea was obvious, the library writers thought of it as well, and so they already added it"
Maybe I don't write the sheer volume of code as other people (been using C++ professionally for six years), but I'm going with: nothing. Any time I've wished an idiom was in the standard library or Boost, that's a clue that maybe it isn't the best way to go. Often times you can express your concepts more simply by rewriting them to take advantage of existing constructs. Good code is easy code. Let the geniuses behind Boost take care of the complicated stuff for you.
Ring or circular buffer. This an often used data structure in Embedded Systems.
logging class (that also works in a Gui)
An encryption library or two wrapped up in a nice interface.
Hashing algorithms can also be quite useful.
a good logging mechanism such as Boost.Log or log4cxx
unit testing framework such as Boost.Test or google test
documentation, preferably using doxygen

C++ Adobe source libraries impressions? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just stumbled upon Adobe source libraries, ASL. It is set of templates and functions similar to boost, under MIT license.
Some of the utilities in the library I found quite useful and now I consider using it.
the library seems pretty straightforward, however.
Have you used ASL yourself? if so, what were your impressions? do you recommend it?
does it work well with a range of compilers and platforms e.g. IBM C++, ICC, g++?
have you encountered quirks/unexpected things?
thanks
ASL uses Boost heavily, so it's not such similar to Boost, as (in some cases) a relatively thin wrapper around Boost.
The "big" pieces of ASL are Adam and Eve. Most of the rest appears to be (and if memory serves, really is) little more than support for those.
ASL hasn't been updated in a while, and if I'm not mistaken some of what it provides in wrappers around Boost has now been incorporated into the Boost libraries themselves (most Boost authors have been aware of ASL at least since they featured in Sean Parent's keynote presentation at Boostcon 1).
My own experience with them has been somewhat mixed. At one time, I used a couple of their Boost-wrapper classes a bit, but IIRC, within the next release or two, the bits I cared about were available in Boost without any wrappers (though offhand, I don't remember exactly what those pieces were...)
Adam and Eve are kind of cool for playing around with different UI layouts and such -- but I've never used them for a finished version of a program. At least to me, it appears that they're useful primarily with a relatively complex UI. My impression was that if you find them very useful, your UI probably needs work. If you need Adam and Eve to help understand what's going on, chances are your users can't figure out either.
OTOH, there are probably at least a few cases where a dialog is clear to a user, but the code much less so to a developer. If you do a lot of disabling some controls until values have been entered in other controls, and such, it can make it a lot easier to ensure controls are disabled until all values they depend upon have been entered.
As already noted, thew whole point of ASL is Adam and Eve, the rest are just handy tools.
Adam & Eve work together to describe UI with auto-layout in a cross-platform way.
If this is not what you need, then you should probably not spend much time on ASL.
Eve has the typical collection of vertical/horizontal/other containers for auto-layout.
And scripting with Adam allows you to achieve things difficult (if not impossible) to achieve just with layout containers (things like keeping separate groups of controls the same size, for instance).
True, you implement some of the rules in your C++ code. But it makes sense to store the UI description rules related to UI behavior in the same place where you store the UI to begin with.

What is the best way to implement templates in a programming language? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm designing a high level, object oriented, garbage collected programming language, and I'm having a problem with how to do templates. I plan on creating a VM-type system, similar to .NET or JVM (but it will use LLVM under the hood). The problem is that I want to have powerful, C++-like templates, but with dynamic linking (so I could replace the template library without recompiling everything that uses it). I want to be able to compile a source file without having the definition of the templates. Code generation at JIT-time should be minimized.
Here are the options I'm thinking of:
Have the concept of a template library which is statically linked into each compilation unit. A template library would essentially be like an AST with blanks to be filled in when the template is instantiated. The problem with this is that if two files are compiled with different versions of the template library, they may be incompatible, or if the template library is buggy, everything will have to be recompiled. This is how C++ does it.
Have template libraries that are linked at JIT-time. This solves most of the problems but requires the IR to essentially be an AST. I would like the IR to be much lower level. This requires much more work for JIT-ing.
Have wimpy C#-like generics with only types as arguments. This is quite limiting, but allows simple code generation and dynamic linking.
Are there any other good ways I'm not thinking of? I'm leaning towards the first option, but I don't really like any of the options. What do you think is the best option?
I guess it depends on the amount of specialization you want, i.e. how powerful the compiler of templates has to be.
If you look at c++, the compiler can do all sorts of fancy stuff (like generate subclasses via recursion, probably compute a fractal inheritance graph as well as computing the numbers of Pi on the fly).
If you want that power, you probably need a powerful high-level JIT. FWIW, I think that would be cool. (Just include the full compiler in the runtime.)
Depends a bit on the rest of the language... if you have operator overloading, value types etc, then you are really complicating matters (and possibly missing out on great optimisation opportunities) by not going the C++ route: the code using the template would also have to be represented as an AST up to JIT time to allow maximum specialization.
Since C++ templates are essentially a form of macros, they allow much of all the bloat produced by duplication to be reduced before you get generate code.
Template types (at least in C++) tend to be the most core types that underly all other code, as such, if they change, assuming other code will still be compatible with it is not going to be true for all but the smallest changes.
What you're trying to achieve is nearly impossible. You have to leave pretty much all of the high level representation of your language for both the templates definitions and the code using those templates, and perform your JIT compilation from almost the level of slightly processed source code. If you're ok with that - you'd have to keep the rest of your compiler really trivial, and you won't be able to use any of the heavyweight LLVM optimisations. There are no other ways around, template metaprogramming relies on the availability of the high level information.
Think about how powerful are these templates going to be. You must remember that having a language that is compiled Just In Time, means that a lot of the heavy lifting will have to be done at load time and at run time. So, the more powerful you make your templates the less performance you will get from them.
If you are really going to that path, you may also include the compiler in the run time as Macke suggested. In fact there are plenty of languages that do this.
By doing this you are making your implementation of the language an "interpreted" or partially "interpreted" one. In those terms a template is just a fancy dress for match-replace-eval, and there is anything wrong with that, templates often work like that in dynamic languages. Just remember that at the end it will be Power vs Performance.
Note: when facing this kind of decisions it may be worth to step back a little. Identify the use cases and prioritize them, separate how to implement from the design so you can iterate the design without having the implementation be a cause of paralysis, yet still having it into consideration.
Each iteration you extend the design to cover more use cases while deciding what will be the best design. When you reach a design you like you can iterate then you can iterate on the implementation too. This methodology allows you to cover the more important cases first.
Yes, I'm suggesting an iterative incremental methodology. And I do this because this question is about the design of a language yet it seems much concerned about the implementation. It is necessary to keep the ideas grounded or you will end up in one of the extremes (too much powerful with pity performance or no templates at all for a high performance solution).

How to teach a crash course on C++? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In a few weeks, we'll be teaching a crash course on C++ for Java programmers straight out of college. They have little or no experience yet with C or C++.
Previous editions of this course were just 1 or 2 half-day sessions and covered topics including:
new language features, e.g.
header vs. implementation
pointers and references
memory management
operator overloading
templates
the standard libraries, e.g.
the C library headers
basic iostreams
basic STL
using libraries (headers, linking)
they'll be using Linux, so
Basic Linux console commands
GCC and how to interpret its error messages
Makefiles and Autotools
basic debugger commands
any topic they ask about
During the course, each person individually writes, compiles, runs, and debugs simple programs using the newly introduced features. Is this the best way to learn?
Which topics do you consider most crucial?
Which topics should be added or removed?
Which topics just can't be covered adequately in a short time?
I can only once again point to Stroustrup and preach: Don't teach the C subset! It's important, but not for beginners! C++ is complex enough as it is and the standard library classes, especially the STL, is much more important and (at least superficially) easier to understand than the C subset of C++.
Same goes for pointers and heap memory allocation, incidentally. Of course they're important but only after having taught the STL containers.
Another important concept that new students have to get their head around is the concept of different compilation units, the One Definition Rule (because if you don't know it you won't be able to decypher error messages) and headers. This is actually quite a barrier and one that has to be breached early on.
Apart from the language features the most important thing to be taught is how to understand the C++ compiler and how to get help. Getting help (i.e. knowing how to search for the right information) in my experience is the single most important thing that has to be taught about C++.
I've had quite good experiences with this order of teaching in the past.
/EDIT: If you happen to know any German, take a look at http://madrat.net/coding/cpp/skript, part of a very short introduction used in one of my courses.
If they are coming from a Java world, they are used to garbage collection. As such, I'd probably spend a bit of time talking about smart (reference counted) pointers, and how they compare to garbage collection.
If you are going to put a lot of Java programmers straight out of college to write production code, I'd say the first thing you should be concerning is pointers and memory management.
Really, those who come directly from managed code rarely have the skills to debug pointer-related exception, let alone use it correctly, or even understands how their language/tools utilize it.
Pointers is how you think not just write code.
The framework and coding practices can be taught as tips and notes along the way.
But failing to understand pointers when writing C code is just waiting to shoot yourself in the foot, if not the head.
I would like to add that you should make sure to point out where they can find language and API references. In java, the API and language specification is at your fingertips online at java.sun.com... with C or C++, it's not quite as simple and easy to find reference documentation.
Whenever I am doing something in C or C++, that is my biggest problem... trying to find what I need. I usually turn to cplusplus.com, which usually has what I need, otherwise I google for it. If you have a set of references you use (online or in the form of books), list them and tell them what you use each reference for.
Memory management (pointers, allocation etc), basics of STL and templates (since STL uses templates). I think STL is important since one would be missing the richness of the Java SE class library in C++.
I would spend a whole day discussing how to write a good class in C++. Deitel & Deitel may help as a reference.
When are constructors called?
When are assignment operators called?
When are destructors called?
What's the point for const Foo & a_foo?
You should take some time on memory management, and especially RAII.