Named std::pair members

Hi all.

I recently stumbled over a discussion that asserted that code using
std::pair<string, int> instead of, say,  struct city_t { string name;
int pcode; };  is hard to read as every time we access the pair we just
work with first and second and the user does not immediately see what
first and second should be.

What do you think of the following solution where std::pair is extended
via a preprocessor macro to contain two arbitrarily named member
references in addition to first and second ... ?

br,
Martin

[code]
#include <map>
#include <string>

#define NAMED_PAIR_TYPE(TNAME, NAMED_FIRST, NAMED_SECOND)  \
template<typename T1, typename T2>                         \
struct TNAME : public std::pair<T1, T2>                    \
{                                                          \
	TNAME()                                                  \
	: pair()                                                 \
	, NAMED_FIRST(first)                                     \
	, NAMED_SECOND(second)                                   \
	{                                                        \
	}                                                        \
	                                                         \
	TNAME(T1 const& val1, T2 const& val2)                    \
	: pair(val1, val2)                                       \
	, NAMED_FIRST(first)                                     \
	, NAMED_SECOND(second)                                   \
	{                                                        \
	}                                                        \
	                                                         \
	template<typename OTHER1, typename OTHER2>               \
	TNAME(pair<OTHER1, OTHER2> const& r)                     \
	: pair(r)                                                \
	, NAMED_FIRST(first)                                     \
	, NAMED_SECOND(second)                                   \
	{                                                        \
	}                                                        \
	                                                         \
	/* first, second aliases:*/                              \
	T1 & NAMED_FIRST;                                        \
	T2 & NAMED_SECOND;                                       \
}                                                          \
/*;*/

NAMED_PAIR_TYPE(named_city_t, name, pcode);
typedef named_city_t<std::string, unsigned int>  city_t;
typedef std::map<city_t::first_type, city_t::second_type>  city_collection;

city_t get_city(std::string const& name)
{
	city_collection dummy;

	if(dummy.find(name) != dummy.end())
		return *dummy.find(name);
	else
		throw std::exception();
}	

int main(int argc, char* argv[])
{

	city_t a;
	city_t b("Foo", 12345);
	city_t c(b);
	a.name;
	a.pcode;

	city_t x = get_city("?");

	return 0;
}
[/code]

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Martin
10/21/2008 10:31:34 PM
comp.lang.c++.moderated 10729 articles. 1 followers. allnor (8506) is leader. Post Follow

9 Replies
906 Views

Similar Articles

[PageSpeed] 44

On Oct 22, 5:31 am, "Martin T." <0xCDCDC...@gmx.at> wrote:

> I recently stumbled over a discussion that asserted that code using
> std::pair<string, int> instead of, say,  struct city_t { string name;
> int pcode; };  is hard to read as every time we access the pair we just
> work with first and second and the user does not immediately see what
> first and second should be.

Makes perfect sense. town->name tells me more than town->first.

> What do you think of the following solution where std::pair is extended
> via a preprocessor macro to contain two arbitrarily named member
> references in addition to first and second ... ?

> #define NAMED_PAIR_TYPE(TNAME, NAMED_FIRST, NAMED_SECOND)  \
> template<typename T1, typename T2>                         \
> struct TNAME : public std::pair<T1, T2>                    \
> {                                                          \
>         TNAME()                                                  \
>         : pair()                                                 \
>         , NAMED_FIRST(first)                                     \
>         , NAMED_SECOND(second)                                   \
>         {                                                        \
>         }                                                        \
>                                                                  \
>         TNAME(T1 const& val1, T2 const& val2)                    \
>         : pair(val1, val2)                                       \
>         , NAMED_FIRST(first)                                     \
>         , NAMED_SECOND(second)                                   \
>         {                                                        \
>         }                                                        \
>                                                                  \
>         template<typename OTHER1, typename OTHER2>               \
>         TNAME(pair<OTHER1, OTHER2> const& r)                     \
>         : pair(r)                                                \
>         , NAMED_FIRST(first)                                     \
>         , NAMED_SECOND(second)                                   \
>         {                                                        \
>         }                                                        \
>                                                                  \
>         /* first, second aliases:*/                              \
>         T1 & NAMED_FIRST;                                        \
>         T2 & NAMED_SECOND;                                       \}                                                          \
>
> /*;*/
>
> NAMED_PAIR_TYPE(named_city_t, name, pcode);
> typedef named_city_t<std::string, unsigned int>  city_t;
> typedef std::map<city_t::first_type, city_t::second_type>  city_collection;

[]

It looks wasteful because you add two data members (references) just
to name the same thing differently.

I would rather add a couple of (inline) accessor functions:

     typedef std::pair<std::string, unsigned int>  city_t;
     inline std::string& get_name(city_t& c) { return c.first; }
     inline unsigned int& get_pcode(city_t& c) { return c.second; }

and than:

     citi_t city;
     std::string& name = get_name(city);

-- 
Max


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Maxim
10/22/2008 9:52:54 PM
Martin T. ha scritto:
> Hi all.
> 
> I recently stumbled over a discussion that asserted that code using
> std::pair<string, int> instead of, say,  struct city_t { string name;
> int pcode; };  is hard to read as every time we access the pair we just
> work with first and second and the user does not immediately see what
> first and second should be.
> 
> What do you think of the following solution where std::pair is extended
> via a preprocessor macro to contain two arbitrarily named member
> references in addition to first and second ... ?

It's quite bad, IMHO. There are several drawbacks with this approach:

1) although the C++ standard says that references might not require
storage, in most implementation reference members increase the size of a
class by the size of a pointer. In you case you have to multiply by two
  (that is 8 bytes on a lot of platforms). Frankly 8 bytes per element is
*a lot* for a simple readability improvement.

2) in case none of the two member types is const, pair<> is assignable,
but your type is not, because references forbids the declaration of the
implicit assignment operator (see 12.8/12). In the non-const/non-const
case (and only that case) you should provide an explicit assignment
operator.

3) this use of references can be used to circumvent const-correctness:

   NAMED_PAIR_TYPE(named_city_t, name, pcode);
   typedef named_city_t<std::string, unsigned int>  city_t;
   const city_t city("Segrate", 20090);
   city.name = "Vimodrone"; // Ops! Modifying a const object!

> 
> <snip>
> 
> city_t get_city(std::string const& name)
> {
>     city_collection dummy;
> 
>     if(dummy.find(name) != dummy.end())
>         return *dummy.find(name);

Of course, you realize that dummy is always empty with this code...

This is very inefficient, for two reasons:

1) You should cache the result of the first call:

   city_collection::iterator it = dummy.find(name);
   if (it != dummy.end())
     return *it;

2) the return statement makes a copy of returned object

Moreover, while the map has immutable keys (you can't change the "first"
in elements of maps, because it has an added "const"), the returned
value has a non-const "city" member. This can be misleading.

A better idiom, in my opinion, is the following:

typedef std::map<std::string, int>  city_collection;
typedef city_collection::value_type city_t;

// you can wrap these in a macro if you want:
inline const std::string& city(const city_t& p) { return p.first; }
inline int& pcode(city_t& p)                    { return p.second; }
inline const int& pcode(const city_t& p)        { return p.second; }

int main(int argc, char* argv[])
{
     city_t b("Milano", 20100);
     city_t c(b);

     name(b);
     pcode(b);

     return 0;
}

Just my opinion,

Ganesh

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Alberto
10/22/2008 10:18:05 PM
Alberto Ganesh Barbati wrote:
> Martin T. ha scritto:
>> Hi all.
>>
>> I recently stumbled over a discussion that asserted that code using
>> std::pair<string, int> instead of, say,  struct city_t { string name;
>> int pcode; };  is hard to read as every time we access the pair we just
>> work with first and second and the user does not immediately see what
>> first and second should be.
>>
>> What do you think of the following solution where std::pair is extended
>> via a preprocessor macro to contain two arbitrarily named member
>> references in addition to first and second ... ?
> 
> It's quite bad, IMHO. There are several drawbacks with this approach:
> 
> 1) although the C++ standard says that references might not require
> storage, in most implementation reference members increase the size of a
> class by the size of a pointer. In you case you have to multiply by two
>   (that is 8 bytes on a lot of platforms). Frankly 8 bytes per element is
> *a lot* for a simple readability improvement.
> 

I agree with you and Maxim that the reference approach isn't that good.
The one using accessor functions seems better.

> 2) in case none of the two member types is const, pair<> is assignable,
> but your type is not, because references forbids the declaration of the
> implicit assignment operator (see 12.8/12). In the non-const/non-const
> case (and only that case) you should provide an explicit assignment
> operator.
> 

OK. Something new for me. Never stumbled over this up to now ...
probably because adding reference members is not exactly a day-to-day
thing :)

> 3) this use of references can be used to circumvent const-correctness:
> 
>    NAMED_PAIR_TYPE(named_city_t, name, pcode);
>    typedef named_city_t<std::string, unsigned int>  city_t;
>    const city_t city("Segrate", 20090);
>    city.name = "Vimodrone"; // Ops! Modifying a const object!
> 

Ouch!! Didn't know that. With pointers it's kinda more obvious.

>> <snip>
>>
>> city_t get_city(std::string const& name)
>> {
>>     city_collection dummy;
>>
>>     if(dummy.find(name) != dummy.end())
>>         return *dummy.find(name);
> 
> Of course, you realize that dummy is always empty with this code...

Just was to test that it compiles.

> 
> A better idiom, in my opinion, is the following:
> 
> typedef std::map<std::string, int>  city_collection;
> typedef city_collection::value_type city_t;
> 
> // you can wrap these in a macro if you want:
> inline const std::string& city(const city_t& p) { return p.first; }
> inline int& pcode(city_t& p)                    { return p.second; }
> inline const int& pcode(const city_t& p)        { return p.second; }
> 

Hmmm ... Both you and Maxim used the free function approach for access.
Personally I much prefer the member-function approach as that can IMHO
help greatly with auto completion / "Intellisense" features.
And it's basically equivalent, or is it?

Here's a modified version:
[code]
#define NAMED_PAIR_TYPE(TNAME, NAMED_FIRST, NAMED_SECOND)  \
template<typename T1, typename T2>                         \
struct TNAME : public std::pair<T1, T2>                    \
{                                                          \
	TNAME() : pair() {}                                      \
	                                                         \
	TNAME(T1 const& val1, T2 const& val2)                    \
	: pair(val1, val2)                                       \
	{ }                                                      \
	                                                         \
	template<typename OTHER1, typename OTHER2>               \
	TNAME(pair<OTHER1, OTHER2> const& r)                     \
	: pair(r)                                                \
	{ }                                                      \
	                                                         \
	/* first, second aliases:*/                              \
	inline T1 const& NAMED_FIRST() const {return first;}     \
	inline T2 const& NAMED_SECOND() const {return second;}   \
	inline T1 & NAMED_FIRST() {return first;}                \
	inline T2 & NAMED_SECOND() {return second;}              \
}                                                          \
/*;*/
[/code]
cheers,
Martin


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Martin
10/23/2008 6:48:05 AM
On 22 oct, 06:31, "Martin T." <0xCDCDC...@gmx.at> wrote:
> Hi all.
>
> I recently stumbled over a discussion that asserted that code using
> std::pair<string, int> instead of, say,  struct city_t { string name;
> int pcode; };  is hard to read as every time we access the pair we just
> work with first and second and the user does not immediately see what
> first and second should be.
>
> What do you think of the following solution where std::pair is extended
> via a preprocessor macro to contain two arbitrarily named member
> references in addition to first and second ... ?

I think you should look into Boost.Fusion.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Mathias
10/24/2008 4:31:37 PM
On Oct 23, 1:48 pm, "Martin T." <0xCDCDC...@gmx.at> wrote:
> Alberto Ganesh Barbati wrote:
> > Martin T. ha scritto:
> >> Hi all.
>
> >> I recently stumbled over a discussion that asserted that code using
> >> std::pair<string, int> instead of, say,  struct city_t { string name;
> >> int pcode; };  is hard to read as every time we access the pair we just
> >> work with first and second and the user does not immediately see what
> >> first and second should be.

[]

> Hmmm ... Both you and Maxim used the free function approach for access.
> Personally I much prefer the member-function approach as that can IMHO
> help greatly with auto completion / "Intellisense" features.
> And it's basically equivalent, or is it?
>
> Here's a modified version:
> [code]
> #define NAMED_PAIR_TYPE(TNAME, NAMED_FIRST, NAMED_SECOND)  \
> template<typename T1, typename T2>                         \
> struct TNAME : public std::pair<T1, T2>                    \
> {                                                          \
>         TNAME() : pair() {}                                      \
>                                                                  \
>         TNAME(T1 const& val1, T2 const& val2)                    \
>         : pair(val1, val2)                                       \
>         { }                                                      \
>                                                                  \
>         template<typename OTHER1, typename OTHER2>               \
>         TNAME(pair<OTHER1, OTHER2> const& r)                     \
>         : pair(r)                                                \
>         { }                                                      \
>                                                                  \
>         /* first, second aliases:*/                              \
>         inline T1 const& NAMED_FIRST() const {return first;}     \
>         inline T2 const& NAMED_SECOND() const {return second;}   \
>         inline T1 & NAMED_FIRST() {return first;}                \
>         inline T2 & NAMED_SECOND() {return second;}              \}                                                          \
>
> /*;*/
> [/code]

At this point it seems to be much simpler just to declare:

     struct city_t { string name; int pcode; };

as you mentioned in your original post and dispense with unnecessary
macro awkwardness.

Is there a reason why you would still like to use std::pair<>?

-- 
Max


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Maxim
10/24/2008 4:31:45 PM
I have seen people doing this:

#include "boost/tuple/tuple.hpp"
#include <string>

int main(int argc, char* argv[])
{
   enum { name, pcode };
   boost::tuples::tuple<std::string, int> np;

   np.get<name>() = "Olso";
   np.get<pcode>() = 12345;

   int n = np.get<pcode>();
   std::string s = np.get<name>();

   return 0;
}

Regards,
eca

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
eca
10/24/2008 4:31:48 PM
Maxim Yegorushkin wrote:
> On Oct 23, 1:48 pm, "Martin T." <0xCDCDC...@gmx.at> wrote:
>> Alberto Ganesh Barbati wrote:
>>> Martin T. ha scritto:
>>>> Hi all.
>>>> I recently stumbled over a discussion that asserted that code using
>>>> std::pair<string, int> instead of, say,  struct city_t { string name;
>>>> int pcode; };  is hard to read as every time we access the pair we just
>>>> work with first and second and the user does not immediately see what
>>>> first and second should be.
> 
> []
> 
>> ...
> 
> At this point it seems to be much simpler just to declare:
> 
>      struct city_t { string name; int pcode; };
> 
> as you mentioned in your original post and dispense with unnecessary
> macro awkwardness.
> 
> Is there a reason why you would still like to use std::pair<>?
> 

Some algorithm or container might work with std::pair so I need 
something "compatible" with it.

br,
Martin

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Martin
10/25/2008 2:33:23 PM
On 10/21/08 23:31, Martin T. wrote:
> I recently stumbled over a discussion that asserted that code using
> std::pair<string, int> instead of, say,  struct city_t { string name;
> int pcode; };  is hard to read as every time we access the pair we just
> work with first and second and the user does not immediately see what
> first and second should be.
>
> What do you think of the following solution where std::pair is extended
> via a preprocessor macro to contain two arbitrarily named member
> references in addition to first and second ... ?
[snip]

Boost fusion's vector:

http://www.boost.org/doc/libs/1_36_0/libs/fusion/doc/html/fusion/container/v
ector.html

does something similar for any number of fields up to some boost
maximum (or at least it did last time I looked at the implementation
several years ago) ; however, the preprocessor generated field names
are just m0,m1,...mn.  Of course those names are even harder to read
than first and second.  However, I'm guessing that the preproccessor
magic that fusion uses to generate the vector could be adapted to
generate more readable names similar to your proposal.


HTH,

Larry



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Larry
10/27/2008 9:19:37 AM
On Oct 27, 4:19 pm, Larry Evans <cppljev...@suddenlink.net> wrote:
> On 10/21/08 23:31, Martin T. wrote:> I recently stumbled over a discussion
that asserted that code using
> > std::pair<string, int> instead of, say,  struct city_t { string name;
> > int pcode; };  is hard to read as every time we access the pair we just
> > work with first and second and the user does not immediately see what
> > first and second should be.
>
> > What do you think of the following solution where std::pair is extended
> > via a preprocessor macro to contain two arbitrarily named member
> > references in addition to first and second ... ?
>
> [snip]
>
> Boost fusion's vector:
>
> http://www.boost.org/doc/libs/1_36_0/libs/fusion/doc/html/fusion/cont...
> ector.html
>
> does something similar for any number of fields up to some boost
> maximum (or at least it did last time I looked at the implementation
> several years ago) ; however, the preprocessor generated field names
> are just m0,m1,...mn.  Of course those names are even harder to read
> than first and second.  However, I'm guessing that the preproccessor
> magic that fusion uses to generate the vector could be adapted to
> generate more readable names similar to your proposal.
>

Fusion provides a macro to adapt the struct of your choice (with
whatever member names you like) as a fusion sequence.

--
gpd


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
gpderetta
10/28/2008 4:23:35 PM
Reply:

Similar Artilces:

workaround to C "typedef struct name *name;" C vs C++
Hi All, This is valid code in C because "struct name" and "name" are distinct { the poster refers to this part of the subj line: typedef struct name *name; -mod } types, but not in C++ where this produces a compiler error. I have a third party C library that uses this extensively in header files and I need to use this in C++ code. Is there a way around this? Thanks, Brian -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Am 25.08.2011 14:30, schrieb Brian L: > Hi All, > > This is valid code in C because "struct name" and "name" are distinct > > { the poster refers to this part of the subj line: > > typedef struct name *name; > > -mod } > > types, but not in C++ where this produces a compiler error. I have a > third party C library that uses this extensively in header files and I > need to use this in C++ code. > > Is there a way around this? What do you mean with a way around? You did not really explain what the actual reason for this construction is. What do you want to realize? The C++ standard is clear that this typedef declaration is invalid in a non-class scope, because the second 'name' does refer to something different than the second one. I can define a construction that works, but I don't know whether this will help ...

SLIME C-c C-k causes name-conflicts
Hello, I have this problem: I visit a file defining a package in emacs slime, compile and load it with C-c C-k, then switch to the REPL, and do (use- package ...) and get a condition sb-int:name-conflict. (emacs 22.1.1, slime 3.0-alpha, sbcl 1.0.6). I believe my lisp file complies with lisp standards, so give me a hint! Here is the lisp file I load (defpackage #:seidel-sparse (:use :cl) (:export *eps* #:seidel-sparse)) (in-package #:seidel-sparse) (defvar *eps* 5d-6) (defun seidel-sparse(A b x) (declare ;(type (simple-array double-float (*)) b x) ;(type (array list (*)) A...

No std::hash for std::pair
std:pair (and tuple) provide lexicographical comparisons using the comparison operators, provided that the types held within the pair have those operators defined. operator< is a particularly useful special case because it allows pairs and tuples to be used as the key elemets in std::set and related containers. The same does not hold true for std:hash and therefore std::unordered set. Is there a rationale behind why std::pair (and tuple) don't have a hash function which, for example, hashes all the elements and xors the results? Or is the lack of such a specialisation simply an oversight? -Ed -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] On 30.08.2012 16:52, Edward Rosten wrote: > std:pair (and tuple) provide lexicographical comparisons using the > comparison operators, provided that the types held within the pair > have those operators defined. > > operator< is a particularly useful special case because it allows > pairs and tuples to be used as the key elemets in std::set and > related containers. > > The same does not hold true for std:hash and therefore > std::unordered set. > > Is there a rationale behind why std::pair (and tuple) don't have a > hash function which, for example, hashes all the elements and xors > the results? Or is the lack of such ...

C and C++ naming issues?
http://www.gubbe.ch/code/libcfgparse/cfgtypes_8h-source.html That page contains a header that when included does not define any of the typedefs or any of the value references that are in that file. For instance, I included that file and then tried this: switch (file.get_type("valid_operating_systems")) { case CFG_ITEM_NONE: cerr << "NONE" << endl; break; case CFG_ITEM_INTEGER: cerr << "INT" << endl; break; case CFG_ITEM_BOOLEAN: cerr << "BOOL" << endl; break; case CFG_ITEM_FLOATINGPOINT: cerr << &qu...

std::pair and move-only types in C++0x ?
Just a quick question: Are std::pair and std::tuple (C++0x) supposed to support move-only types? It sure looks like they don't judging by N3126.pdf. But I can hardly believe this. I was expecting to be able to put a std::unique_ptr into a std::map as mapped type. If I recall correctly someone's working on a refined pair/tuple specification to fix some other errors in the current proposal. It would be great to hear from that someone or anybody else involved. TIA, Sebastian On Oct 11, 2:43=A0pm, SG <s.gesem...@gmail.com> wrote: > Just a quick question: >...

C++14 std::size() non-member function
The C++14 working paper has voted in the following non-member functions, which are missing from the C++11 standard: std::cbegin()/std::cend(), std::rbegin()/std::rend(), std::crbegin()/std::crend(). Seemingly another missing non-member function is std::size(). Such a function would be useful, especially when dealing with legacy functions that expect a pointer to an array and an array size. Many times the array size calculation of the array size is either hard coded or calculated using sizeof, both of which are error prone. Consider the following possible implementation of the std::size() non-member function. // for raw arrays template<typename Arr, size_t Size> size_t inline size(Arr(&Array)[Size]) { return Size; } // for std containers implemented the size member function template<typename Container> auto inline size(Container& Cont) -> decltype(Cont.size()) { return Cont.size(); } Using std::size() to calculate an array size would be as follows: void some_legacy_func(wchar_t * p, size_t s); wchar_t buf[15]; some_legacy_func(p, std::size(buf)); // the line above easier to get right than (sizeof(buf) / sizeof(buf[0])) Is there any interest in such a function? If so, how could such a feature be proposed? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] ...

How to read an input text from keyboard by the std. lang. C?
Hello, how to read an input text from keyboard (on a console) by the standard languace C, please? I really need a tip about this question. TIA, Vinicius. What kind of input? Do you want to read a word? A sentence? A number? There's more than one way to get input from stdin, but for the most part you'll find yourself using fgets: #include <stdio.h> #include <stdlib.h> int main(void) { char buffer[BUFSIZ]; printf("Enter some text: "); fflush(stdout); if (fgets(buffer, sizeof buffer, stdin) == NULL) { fprintf(stderr, "Input error\n"); return EXIT_FAIL...

NAME! and NAME@ versus !NAME and @NAME
Leo Brodie's Forth style guide says: save value of (to stack) @name restore value of !name store into name! fetch from name@ I don't understand when it's appropriate to use @name or !name, and when to use name@ or name!. My research so far: The Standard use the latter a lot: C!, 2! R@, F!, DEFER@, etc. But the former seems to be rare. I found !CSP and !BITS in some traditional Forths. Machine Forth use A!/A@ to access the contents of the A register, and !A/@A to access memory. Any ...

Better C/C++ Than C/C++?
I am looking for a good systems programming language that can be used instead of C/C++. My qualifications for the language are: * mature compiler(s) that produce native-code binaries (for Windows) * open source - preferable, but not 100% necessary Thanks, Kevin "Kevin Albrecht" <kevin@albrecht.net> writes: > I am looking for a good systems programming language > that can be used instead of C/C++. My qualifications > for the language are: > > * mature compiler(s) that produce native-code > binaries (for Windows) Ocaml, D, cyclone, Eiffel, Beta > * open source - preferable, but not 100% necessary what's wrong with using C? Friedrich > what's wrong with using C? Too low level, no built-in garbage collection. -- Kevin "Kevin Albrecht" <kevin@albrecht.net> writes: >> what's wrong with using C? > > Too low level, Well the Smalltalk people say, have a small language and a big library. I assume C's library status beyond that of Smalltalk. > no built-in garbage collection. Use the Boehm Weisser GC. Friedrich "Kevin Albrecht" <kevin@albrecht.net> wrote in message news:<2TiYb.237892$rj7.1641209@twister.tampabay.rr.com>... > I am looking for a good systems programming language > that can be used instead of C/C++. My qualifications > for the language are: > > * mature compiler(s) that produce native-code > binaries (for Windows) > ...

jython and C-c C-c
How do I get C-c C-c to work with jython? I have the jpython command set to jython, and I can start the interpreter with C-C ! and then use C-c C-c, but this is rather frustrating. If I try to use C-c C-c without first starting the interpreter in another window I get wrong type argument: sequencep, jpython Thanks, Dave Cook ...

Mixing C/C++ and Func. Names
Hi, I have a strange error... I am using a C lib with my C++ code. One of the C lib functions requires a non-member callback function pointer defined by the following typedef: typedef void (*Callback)(void *userData, const char *name, const char **atts); I defined a function with this prototype, and marked its declaration with extern "C". The problem is, when my callback function name begins with a capitol letter, the compiler complains that the function pointer that I pass cannot be converted to the expected typedef.... but, and here's the kicker, when the function name beg...

Why is std::sub_match derived from std::pair?
I wonder what where the reasons that lead to the decision, that sub_match<BiIt> is publicly derived from pair<BiIt, BiIt>, as seen in 28.9/1 of N2134? On the first sight it seems to be astonishing, that inheritance is used here, because std::pair is actually not designed for that, being actually an entity usually known as "value type". Furtheron there seem not to exist a relevant number of advantages for this: std::pair has actually no reusable member functions useful for the derived class. Even the predefined comparison operators are not reused but replaced by new ones. Thus the only visible advantages see to be that sub_match is per-se a tuple. Since sub_match also introduces further public data members ("bool matched;"), users could easily stumble accross slicing error. Another point is that the Standard obviously uses a technique, that *usually* is not recommended one (and with no convincing advantages as far as I see). Deriving from member-free tagging classes like iterator_traits, unary/binary_function and similar ones is much easier to explain than in the sub_match/pair case. Just recently we had the thread " STL non virtual DTOR" comp.lang.c++.moderated, http://tinyurl.com/3xk6cv where practically all answers had a similar tone. How should we justify future questions going into the same direction? It's not unusual that people argue by comparison to existing Standard code. And in this case we...

Which container
I am wriing a messaging system and I need to mantain a list of subscribers(object) to topics (string). which of the ff representations is better (and why?) typedef pair<string, list<Subscriber> > topicSubscribers ; typedef list<topicSubscribers> subscriberList ; OR typedef map<string, list<Subscriber> > topicSubscribers ; typedef list<topicSubscribers> subscriberList ; Bart Simpson <eatmyshorts@springfield.com> wrote: > which of the ff representations is better (and why?) > > typedef pair<string, list<Subscriber> > topicSub...

Question Can I use explicit qualifier <C> after member function name of a template class?
Bjarne Stroustrup's "The C++ Language Programming" says at P330: "Within the scope of String<C>, qualification with <C> is redundant for the name of the template itself, so String<C>::String is the name for the constructor. If you prefer, you can be explicit: template<class T> String<C>: String<C> () { /*...*/ }" But in fact, I find I cannot use this 'explicit' form for any member function of a template class with g++ or Comeau. Is it the problem of the compilers or the book? an0 wrote: > Bjarne Stroustrup's "T...

Why are static member variables allowed in c++ and not in C?
Hi All, I have seen this question(mentioned in subject) posted in various forums but some how I am not statisfied with the answer. 1- Is this because of where static variables are placed in c and c++ 2- or There is a constraint from the language(C) (didn't understand this much) and also related to this any links where I can find differences in c and c++ not related to language ie not like c++ has class and c has not but like const has external linkage in c but in c++ it has external linkage. Thanks, Manas -- [ See http://www.gotw.ca/resources/clcm.htm for ...

member function names identical to class names
When adopting the coding style of the standard C++ library, you often run into naming problems because class names are lower case, and member functions do not have get/set prefixes. For example: - The class stringstream has a member function "string stringstream::str()". It would be more logical to name it "string stringstream::string()". - The class ios_base has a member function "locale ios_base::getloc()". It would be more logical to name it "locale ios_base::locale()". Especially because the "get" prefix is never used in the standard libra...

C++ class DLL export name for C#
Hi: I am writing an .NET C# application. I know the way to call C function from P/Invoke. But P/Invoke doesn't provide C++ hook. Is there a way to control C++ export name like C style? thank you. steve ...

C as a Subset of C++ (or C++ as a superset of C)
Isn't it a lame use of human time and effort to maintain completely separate C and C++ standards? As in the words of Betty White about Facebook: "It seems like an incredible waste of time". Why don't the two standards groups get together and agree on a common specification for the ground which both standards cover? There would still be two separate standards, but they'd both be exactly the same for the common ground. The common ground document could be referred to by both standards instead of being maintained by both groups in individual efforts resulting in...

C/C++ in MATALB or MATLAB in C/C++?
Hi I've been asking on the net how to use MEX properly so that I can use C/C++ in MATLAB, but information is not forthcoming. There seems to be a lot on using MATLAB in C/C++ but not the other way around. I understand Mathworks is trying very hard to sell the Matlab Compiler, but even so, why is it SO hard to get information about MEX? Or is it that I've missed something very fundamental, meaning that I'm struggling over something that is actually quite easy? Any thoughts and info would be great. Thanks BullDog BullDog wrote: > Hi > > I've been asking on the net ...

c------->c++ and c++------>c
We can write c program in turbo c++ editor.But reverse is not true why? i.e The program will not compile if u write c++ program in turbo c editor vim wrote: > We can write c program in turbo c++ editor.But reverse is not true why? > i.e The program will not compile if u write c++ program in turbo c > editor This isn't about C; this is about some editor. Why the fircone should /we/ know? Ask in a relevant group. [And /why/, in an editor specialised to some specific programming languages, would you expect it to compile a /different/ one? Would you expect turbo perl to compi...

C/C++ in matlab and matlab in C/C++ ?
Is it possible to read C/C++ code in matlab and the other way around too? Hi, as long as C or C++ are written in text files you can edit them in the matlab editor. To see the special character of C or C++ coding language, in the editor go to menus: file>preferences>Edito/Debugger>language and on popup "Language" select "C/C++". This does not allow you to run the C/C++ code, just to view it i nicer way... regards, chris saneman <asdfsdf@asd.com> wrote in message <frl846 $f8i$2@news.net.uni-c.dk>... > Is it possible to read C/C...

slime C-c C-c annoyance
Does anyone have a good workaround for this problem other than: just be careful! When I've compiled a large package and slime has given me a *slime-compilation* buffer, I like to work through this buffer issue by issue, fixing the errors, warnings, etc. But If I ever press C-c C-c in the editor window while fixing an error, slime destroys the *(slime-compilation* buffer with the compilation output of C-c C-c. Jim Newton <jimka.issy@gmail.com> writes: > Does anyone have a good workaround for this problem other than: just be careful! > > When I've compiled a ...

Make a python property with the same name as the class member name
Is it possible in python to create a property with the same name as the member variable name of the class. e.g. Class X: ... self.i = 10 # marker ... property(fget = get_i, fset = set_i) Please tell me how I can do so. Because if I do so, for the statement at marker I get stack overflow for the assingm On Fri, Feb 27, 2009 at 5:59 AM, Ravi <ra.ravi.rav@gmail.com> wrote: > Is it possible in python to create a property with the same name as > the member variable name of the class. e.g. No, because accessing the property and the instance variable are *syntactically...

c,c++,obj-c
Of the 3 languages titled in this post is c++ older than obj-c ? Would someone experienced in C be able to dive right into C++ rather than obj-c ? Java is out for me now except applet programming I think I'm going to go with just C and C++. Bill Bill Cunningham wrote: > Of the 3 languages titled in this post is c++ older than obj-c ? Why does that matter? Do you want to use an old language? Try Fortran or LISP. > Would > someone experienced in C be able to dive right into C++ rather than > obj-c ? Not quite dive in, at least not into the OO parts of C++. ...

Web resources about - Named std::pair members - comp.lang.c++.moderated

Resources last updated: 3/8/2016 8:27:01 AM