I am confusion.
I'm learning about the ofstream, it seems that it's really a basic_ofstream according to:
https://en.cppreference.com/w/cpp/io/basic_ofstream/basic_ofstream
https://msdn.microsoft.com/en-us/library/7z434859.aspx
What is the reason for a class named basic_ofstream with a constructor named ofstream? 'basic' implies that there is a non-basic version. Why is the constructor name different than the class name?
There is no constructor named ofstream (constructors don't have names), and there's no class named basic_ofstream (despite of what Microsoft documentation claims).
basic_ofstream is a class template (which is different from a class), and ofstream is a typedef name a.k.a. type alias that refers to one instantiation of that template, specifically to basic_ofstream<char>.
wofstream is another such name that refers to basic_ofstream<wchar_t>.
This is the naming convention that the C++ standard library uses to define different variants of types that differ in the character type they use. Another set of names that follows this convention is basic_string, string and wstring.
This is not constructor named differently. It's a specialization. So basic_ofstream is a template. Then you have two "shortcut names":
ofstream for basic_ofstream<char>
wofstream for basic_ofstream<wchar_t>
Why are they named basic... maybe because standard library provides only basic versions and client can write non-basic classes and plug them in. If you look at c++ standard io library diagram, all components are prefixed as "basic".
It's usually by replacing basic_streambuf any tying custom streambuf to stream. One example taken from boost
#include <ostream>
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/stream.hpp>
namespace io = boost::iostreams;
int main()
{
io::stream_buffer<io::file_sink> buf("log.txt");
std::ostream out(&buf);
// out writes to log.txt
}
It's a buffer implementation working with std::ostream.
If you want to explore fancy implementations you can checkout more from boost::iostreams library and their examples. Nice one is with gzip. It works with ifstream:
#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/gzip.hpp>
int main()
{
using namespace std;
ifstream file("hello.gz", ios_base::in | ios_base::binary);
filtering_streambuf<input> in;
in.push(gzip_decompressor());
in.push(file);
boost::iostreams::copy(in, cout);
}
Related
The code bellow compiles without a warning on GCC and issues an error with clang (any c++11 compatible versions of both clang and GCC).
Which compiler is right with respect to the standard?
Specifically, is it allowed to declare as friend a non partially specialized template alias which is a partial template specialization of a class?
This makes me think that it might not be allowed:
cppreference says: "Friend declarations cannot refer to partial specializations [...]".
And also: "A type alias declaration introduces a name which can be used as a synonym for the type denoted by type-id. It does not introduce a new type [...]".
Finally: "Both function template and class template declarations may appear with the friend specifier [...]". It implicitly excludes the possibility for a template alias to be a friend of a class as an actual template alias but rather as the aliased class template, which is a partial specialization in the snippet bellow.
However, this makes me think that it might be allowed:
cppreference says : "An alias template is a template [...]". I undestand that a template alias is a distinct template. By consequence, declaring it as friend as in the following example without partial specilization of the class template alias is valid... Or not.
This code (not from me) also gives a workaround and let me think that there is no obvious reason for making the following code ill-formed.
This post asks a very similar question but no clear answer was provided with respect to the specific usage of an intermediate template alias.
template<typename T,typename N> class B{};
template<typename T> class A{
// template<typename U> friend class B<T,U>; fails as expected
template<typename N> using alias = B<T,N>;
template<typename N> friend class alias;
};
Intent: legal way to declare a partial specialization as friend using an intermediate alias (workaround).
Result: GCC is happy with it and produces the intended behaviour. Clang produces the following error:
<source>:7:35: error: redefinition of 'alias' as different kind of symbol
template<typename N> friend class alias;
^
<source>:6:22: note: previous definition is here
template<typename N> using alias = B<T,N>;
Following code does not compile with clang-700.1.81 and it's standard library:
#include <memory>
class something;
std::unique_ptr<something> external_function();
std::unique_ptr<something> local_function()
{
auto thing = external_function();
return thing;
}
The diagnostics by clang:
......./include/c++/v1/memory:2626:46: note: in instantiation of member function 'std::__1::unique_ptr.....requested here
_LIBCPP_INLINE_VISIBILITY ~unique_ptr() {reset();}
^
test.cc:10:18: note: in instantiation of member function 'std::__1::unique_ptr<something, std::__1::default_delete<something> >::~unique_ptr' requested here
auto thing = external_function();
^
test.cc:4:7: note: forward declaration of 'something'
class something;
^
I guess it is trying to destroy the unique_ptr after copying it as return value, but is this really necessary? It is going be moved anyways, does it need to check if it can copy before realizing that it is easier to move it?
I could of course do this easily with a naked pointer.
Is there some other way to allow a uniqe_ptr to just "pass through" a translation unit, as shown in the example, without including extra header to get the definition of class something?
------EDIT--------
Also tried with GCC 5.3.0 and gnu libstdc++
Does not compile as well, with similar error messages.
------EDIT----
I think it is just trying to destroy the original thing object.
Thanks to Rudolf for the deleter idea ( a bit messy, but only option for this )
Looking at the library code I found this in unique_ptr's code:
if (__tmp)
__ptr_.second()(__tmp);
where second(_tmp) destructs the object pointed to. Even though it is never called, the compiler needs a definition to compile it. This is silly, but apparently gotta live with it.
From cppreference.com:
std::unique_ptr may be constructed for an incomplete type T, such as to facilitate the use as a handle in the Pimpl idiom. If the default deleter is used, T must be complete at the point in code where the deleter is invoked, which happens in the destructor, move assignment operator, and reset member function of std::unique_ptr. (Conversely, std::shared_ptr can't be constructed from a raw pointer to incomplete type, but can be destroyed where T is incomplete).
Thus, with a custom deleter you can use a forward declared class if the full declaration is available for the deleter:
#include <memory>
class Foo;
class FooDeleter
{
public:
void operator()(Foo* pInstance);
};
std::unique_ptr<Foo, FooDeleter> pFoo;
class Foo
{
};
void FooDeleter::operator()(Foo* pInstance)
{
delete pInstance;
}
I'm currently remodelling a dynamic library project and removed a lot of STL and other dependencies from its header resulting in conflicting implementations between different toolchains.
The DLL Interface now only contains plain C-types and custom types whom implementation depends solely on the DLL code. But now I'm stuck with two remaining points.
The DLL should return some sort of reference counting smart pointer (with a weak pointer option)
Managing construction and destruction between the DLL boundaries. This more or less looks like this.
.
#include <memory>
class Config;
typedef std::shared_ptr<Config> ConfigPtr;
class CONFIGAPI_DLL Config
{
public:
///...
ConfigPtr getNewNode( char const* query = "." )
{
// construct obj in dll, but construct shared_ptr in header
return ConfigPtr( _constructgetNewNode(query) );
}
ConfigPtr getNewNodeFromHeader( char const* query = "." )
{
// construct obj and shared_ptr in header
auto obj = new Config;
obj->_init(query);
return ConfigPtr( obj );
}
private:
Config* _constructNewNode( char const* query = "." );
void _init( char const* query = "." );
};
I was thinking by creating the share_ptr at the dll headers (getNewNode) it would prevent mixed implementations of std::shared_ptr ...but I don't know if that is a good idea?
But I also construct the new object inside the DLL (_constructNewNode) and this means it should also be destructed there?
I tried to construct it in the headers and so in the user code scope (getNewNodeFromHeader)... this shouldn't cause problems?
The downside is I still export the C++11 header and rule out all older compilers. Is it possible to export the shared_ptr type from the dll as unconflicting code but still be compatible with std::shared_ptr?
thanks!
I suppose you want to mix creation and destruction of the objects (Config and the shared_ptr). If the DLL client is not compiled with the same version and configuration of the compiler you would be in troubles (for example, mixing debug and release modules). The main problem I see here: there is not any type of standard ABI for C++.
I was thinking by creating the share_ptr at the dll headers
(getNewNode) it would prevent mixed implementations of std::shared_ptr
...but I don't know if that is a good idea?
If you define your header file to create the shared_ptr, that would be OK if only a module use that header file. I mean, if the shared_ptr is not to be used for the content of the DLL, for example. BUT if other client module (a binary module, like other DLL) use also that header, you must be sure they are compiled with the same compiler and compiling configuration. If you have not that guarantee, then is not good idea.
But I also construct the new object inside the DLL (_constructNewNode)
and this means it should also be destructed there?
If you construct the object inside the DLL, you'll be better destroying inside the DLL. How to do that? specifying a deleter at shared_ptr construction. Something like
struct ConfigDeleter {
void operator()(Config* c) {
c->destroy(); // or as you want to implement it.
};
typedef std::shared_ptr<Config, ConfigDeleter> ConfigPtr;
I tried to construct it in the headers and so in the user code scope
(getNewNodeFromHeader)... this shouldn't cause problems?
As before, it depends if you can guarantee all modules are homogeneous (same compiler version and configuration, library, etc.). But of you want to implement as that, do it well:
// construct obj and shared_ptr in header
auto obj_ = make_shared<Config>();
obj_->init(query);
It is exception-safe and more efficient: just one allocation to store the object and the reference, instead two allocations in your sample.
If you want your code be safe for mixing modules, implement all allocations (shared_ptr included) into the DLL, if they are shared. Exports a "C" interface, and create header file to wrap that interface in classes. Something like:
class WConfig {
public:
WConfig(): m(IDll->create()) {
}
// other member functions as interface stub
~WConfig() {
IDll->release(m);
}
private:
Config* m;
};
To share this object, you can use copy constructor (that copy the pointer and call to IDll->reference(m), for example) or any other approach.
I'm trying to write a managed wrapper (C++/CLI) around an unmanaged C++ static library and am having two problems:
The unmanaged library uses std::shared_ptr in its headers. <memory> is included, and the header compiles as part of an unmanaged project. When I include this header in the managed project, however, I receive this error:
error C2039: 'shared_ptr' : is not a member of 'std'
How do I access the Values collection of a SortedDictionary<K, V> from C++/CLI? I cannot seem to find any examples of the proper syntax, and the C#-style syntax does not compile.
Code for #1:
// 1>Dummy.h(10): error C2039: 'shared_ptr' : is not a member of 'std'
#pragma once
#pragma managed(push, off)
#include <memory>
class Foo {};
typedef std::shared_ptr<Foo> FooPtr;
#pragma managed(pop)
using namespace System;
namespace Dummy {
public ref class Class1
{
public:
Class1(FooPtr);
};
}
shared_ptr lives in <memory> not <functional>. Make it look similar to this:
#pragma managed(push, off)
#include <memory>
#include "yourUnmanagedLibrary.h"
#pragma managed(pop)
Second question (ask only one please):
using namespace System::Collections::Generic;
...
SortedDictionary<int, String^>^ coll = gcnew SortedDictionary<int, String^>;
coll->Add(1, "one");
coll->Add(0, "zero");
for each (String^ value in coll->Values) {
Console::WriteLine(value);
}
I have found the answer here: Edit $(IncludePath) "macro" in Visual Studio 2010
Visual Studio 2010 is including the headers from Visual Studio 2008, which do not have shared_ptr.
The exact resolution is described here. The Platform Toolset on the General tab defaulted to vs90. Changing this to vs100 resolved the issue.
I have a header file in a managed DLL project like so:
Enums.h:
#pragma once
...
public ref struct ManagedStruct {
Bitmap^ image;
}
...
This header is referenced both from another class in the DLL and from a separate executable. The managed struct alone is generating:
error C2011: 'ManagedStruct' : 'class' type redefinition.
If I move the struct to the main header file in the DLL it works fine, and is publicly accessible, so that's what I'm doing, but I would very much like to learn why this is happening when I just move it to another file.
I have checked all necessary includes and namespaces AND tried the obvious header guards, to no avail; I still get the error.
Thanks very much for any insight!
You have to de-tune the traditional C/C++ header file think a bit when you work with managed code. The principal source of type declarations is the assembly metadata. This is very different from the native C/C++ compilation model where you have to have a header file for types that you make visible to other modules.
I'm going to guess that you get this C2011 error in the EXE project. Where you both added a reference to the DLL project assembly (like you should) and used #include on the header file. Like you should not. That's a guaranteed duplicate definition, #pragma once doesn't fix that.
Don't use header files for exported type definitions. Always use assembly references.
I Know this question is a bit old, but I'm writing this for future usage:
I had the following problem, which was similar:
managed DLL had a managed class.
managed.h:
namespace Managed {
ref class CManagedClass {...}
}
in an unamanged class I wanted to use this above class and so in unmanaged.h
#include "managed.h"
in another DLL I also did:
#include "unmanged.h"
which resolved in the type redefinition error.
I have found a solution to this issue using the following method:
forward declaration in the unmanaged.h
namespace Managed {
ref class CManagedClass;
}
and include the managed.h in the unmanaged.cpp file as usual.