top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

What is the GCC C++ equivalent implementation of Windows _ MyFirst and _MyLast vector pointers?

+1 vote
512 views

I wanted to ask what is the GCC C++ equivalent implementation of Windows _ MyFirst and _MyLast vector pointers?

These give direct access to the vectors first and last element, but they are not present in the GCC implementation of the vector class.

posted Jan 26, 2016 by Alok Sharma

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

The best thing you can do is read the source. From the file vector, you can see that you need to read the file bits/stl_vector.h. And there you will find 2 private members that you cannot use anyway. Or is this for use in a debugger?

answer Jan 26, 2016 by Majula Joshi
Similar Questions
+1 vote
generating unaligned vector load instructions using gcc

I wonder how one could get the compiler to generate the "movdqu" instruction, since the vector extensions always seem to assume that everything will be aligned to 16 byte.
I tried using a packed struct and this dint help much. Of course one can always resort to inline assembly but this should not be necessary

Compile with:

gcc -O2 -S -msse2 testvecs.c

Using built-in specs.

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' 
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs 
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.7 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --enable-plugin --enable-objc-gc 
--enable-targets=all --with-arch-32=i586 --with-tune=generic 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
0 votes
Extending the core language via a gcc plugin possible?

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this

[variable_definitions;]

Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)
 ...

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.

0 votes
Why GCC prefers global size-unaware deallocation function?

I have the following operator delete replacements:

void operator delete[](void* p)
{
 /* Implementation does not matter. */
}

void operator delete[](void* p, std::size_t size)
{
 /* Implementation does not matter. */
}

My question is why, in the following code, GCC 6.2 calls void operator delete[](void*) and not the second replacement:

char* str = new char[14];
delete[] str;

According to 5.3.5 Delete [expr.delete]:
(10.3) If the type is complete and if, for the second alternative (delete array) only, the operand is a pointer to a class type with a non-trivial destructor or a (possibly multi-dimensional) array thereof, the function with a parameter of type std::size_t is selected.

Therefore, I believe operator delete[](void*, std::size_t) must be called, doesn't it?

+1 vote
gcc compiler didn't error on function with no return statement

I need some help in understanding why my GCC didn't consider this an issue. I have a function that was constructing a path to a daemon program based on the location of the shared object file where this code is. Something similar to this:

namespace {
 std::string ConstructPath()
 {
 int lastSlash(0);
 std::string pathVar;
 Dl_info dl_info;
 memset(

 if((dladdr((void*)ConstructPath, 
 }

 pathVar = dl_info.dli_fname;
 lastSlash = pathVar.find_last_of('/');
 if(std::string::npos == lastSlash)
 {
 // no slashes given ... must be that *.so
 // is in the current directory
 pathVar = "mydaemond";
 }
 else
 {
 pathVar.erase(pathVar.begin() + (lastSlash + 1), pathVar.end());
 pathVar.append("mydaemond");
 }

 // first check if we can find the daemon
 {
 // introducing sub-scope to ensure the file object is closed
 std::ifstream test(pathVar.c_str());
 if(!test.good())
 {
 throw std::runtime_error("cannot find mydaemond");
 }
 }

 // *** the below statement wasn't there originally, the
 // *** function simply exited after the forced-scope block above,
 // *** however, the function *did* have the return type
 return pathVar;
 }
}

My comments above the final return statement illustrate what my question is about. Why wasn't this a problem? There was no return statement and yet, the code compiled fine. I'm using GCC 4.4.4 on CentOS 6.2. Is this just a problem with the 4.4.4 compiler that was fixed? I'm betting there's some subtlety in C++ here that I'm not yet aware of and I'd like to be schooled.

...