Search Results

Search found 13 results on 1 pages for 'nawaz'.

Page 1/1 | 1 

• C++ : Lack of Standardization at the Binary Level

  - by Nawaz

  Why ISO/ANSI didn't standardize C++ at the binary level? There are many portability issues with C++, which is only because of lack of it's standardization at the binary level. Don Box writes, (quoting from his book Essential COM, chapter COM As A Better C++) C++ and Portability Once the decision is made to distribute a C++ class as a DLL, one is faced with one of the fundamental weaknesses of C++, that is, lack of standardization at the binary level. Although the ISO/ANSI C++ Draft Working Paper attempts to codify which programs will compile and what the semantic effects of running them will be, it makes no attempt to standardize the binary runtime model of C++. The first time this problem will become evident is when a client tries to link against the FastString DLL's import library from a C++ developement environment other than the one used to build the FastString DLL. Are there more benefits Or loss of this lack of binary standardization?

  Read the article

• C++ : Lack of Standardization at the Binary Level

  - by Nawaz

  Why ISO/ANSI didn't standardize C++ at the binary level? There are many portability issues with C++, which is only because of lack of it's standardization at the binary level. Don Box writes, (quoting from his book Essential COM, chapter COM As A Better C++) C++ and Portability Once the decision is made to distribute a C++ class as a DLL, one is faced with one of the fundamental weaknesses of C++, that is, lack of standardization at the binary level. Although the ISO/ANSI C++ Draft Working Paper attempts to codify which programs will compile and what the semantic effects of running them will be, it makes no attempt to standardize the binary runtime model of C++. The first time this problem will become evident is when a client tries to link against the FastString DLL's import library from a C++ developement environment other than the one used to build the FastString DLL. Are there more benefits Or loss of this lack of binary standardization?

  Read the article

• Implicit conversion : const reference vs non-const reference vs non-reference

  - by Nawaz

  Consider this code, struct A {}; struct B { B(const A&) {} }; void f(B) { cout << "f()"<<endl; } void g(A &a) { cout << "g()" <<endl; f(a); //a is implicitly converted into B. } int main() { A a; g(a); } This compiles fine, runs fine. But if I change f(B) to f(B&), it doesn't compile. If I write f(const B&), it again compiles fine, runs fine. Why is the reason and rationale? Summary: void f(B); //okay void f(B&); //error void f(const B&); //okay I would like to hear reasons, rationale and reference(s) from the language specification, for each of these cases. Of course, the function signatures themselves are not incorrect. Rather A implicitly converts into B and const B&, but not into B&, and that causes the compilation error.

  Read the article

• The C++ Standard: Book Recommendation.

  - by Nawaz

  I'm planning to buy this book: The C++ Standard: Incorporating Technical Corrigendum No. 1 http://www.flipkart.com/standard-british-standards-institution-incorporating-book-0470846747 Since it's cost is too much for me (being an Indian we've the habit of buying only low-price edition books :D), I want to make sure if this is the correct edition/version of the Standard. So I need some good advice if I should go for it, or there is better option for me which I'm unaware of. PS: I want to buy hard copy, not PDF.

  Read the article

• Undefined Behavior and Sequence Points Reloaded

  - by Nawaz

  Consider this topic a sequel of the following topic: Previous Installment Undefined Behavior and Sequence Points Let's revisit this funny and convoluted expression (the italicized phrases are taken from the above topic *smile* ): i += ++i; We say this invokes undefined-behavior. I presume that when say this, we implicitly assume that type of i is one of built-in types. So my question is: what if the type of i is a user-defined type? Say it's type is Index which is defined later in this post (see below). Would it still invoke undefined-behavior? If yes, why? Is it not equivalent to writing i.operator+=(i.operator ++()); or even syntactically simpler i.add(i.inc());? Or, do they too invoke undefined-behavior? If no, why not? After all, the object i gets modified twice between consecutive sequence points. Please recall the rule of thumb : an expression can modify an object's value only once between consecutive "sequence points. And if i += ++i is an expression, then it must invoke undefined-behavior. If so, then it's equivalents i.operator+=(i.operator ++()); and i.add(i.inc()); must also invoke undefined-behavior which seems to be untrue! (as far as I understand) Or, i += ++i is not an expression to begin with? If so, then what is it and what is the definition of expression? If it's an expression, and at the same time, it's behavior is also well-defined, then it implies that number of sequence points associated with an expression somehow depends on the type of operands involved in the expression. Am I correct (even partly)? By the way, how about this expression? a[++i] = i; //taken from the previous topic. but here type of `i` is Index. class Index { int state; public: Index(int s) : state(s) {} Index& operator++() { state++; return *this; } Index& operator+=(const Index & index) { state+= index.state; return *this; } operator int() { return state; } Index & add(const Index & index) { state += index.state; return *this; } Index & inc() { state++; return *this; } };

  Read the article

• Is this code well-defined?

  - by Nawaz

  This code is taken from a discussion going on here. someInstance.Fun(++k).Gun(10).Sun(k).Tun(); Is this code well-defined? Is ++k Fun() evaluated before k in Sun()? What if k is user-defined type, not built-in type? And in what ways the above function calls order is different from this: eat(++k);drink(10);sleep(k); As far as I can say, in both situations, there exists a sequence point after each function call. If so, then why can't the first case is also well-defined like the second one? Section 1.9.17 of the C++ ISO standard says this about sequence points and function evaluation: When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body. There is also a sequence point after the copying of a returned value and before the execution of any expressions outside the function.

  Read the article

• Design of std::ifstream class

  - by Nawaz

  Those of us who have seen the beauty of STL try to use it as much as possible, and also encourage others to use it wherever we see them using raw pointers and arrays. Scott Meyers have written a whole book on STL, with title Effective STL. Yet what happened to the developers of ifstream that they preferred char* over std::string. I wonder why the first parameter of ifstream::open() is of type const char*, instead of const std::string &. Please have a look at it's signature: void open(const char * filename, ios_base::openmode mode = ios_base::in ); Why this? Why not this: void open(const string & filename, ios_base::openmode mode = ios_base::in ); Is this a serious mistake with the design? Or this design is deliberate? What could be the reason? I don't see any reason why they have preferred char* over std::string. Note we could still pass char* to the latter function that takes std::string. That's not a problem! By the way, I'm aware that ifstream is a typedef, so no comment on my title.:P. It looks short that is why I used it. The actual class template is : template<class _Elem,class _Traits> class basic_ifstream;

  Read the article

• C++ : Lack of Standardization at the Binary Level

  - by Nawaz

  Why ISO/ANSI didn't standardize C++ at the binary level? There are many portability issues with C++, which is only because of lack of it's standardization at the binary level. Don Box writes, (quoting from his book Essential COM, chapter COM As A Better C++) C++ and Portability Once the decision is made to distribute a C++ class as a DLL, one is faced with one of the fundamental weaknesses of C++, that is, lack of standardization at the binary level. Although the ISO/ANSI C++ Draft Working Paper attempts to codify which programs will compile and what the semantic effects of running them will be, it makes no attempt to standardize the binary runtime model of C++. The first time this problem will become evident is when a client tries to link against the FastString DLL's import library from a C++ developement environment other than the one used to build the FastString DLL. Are there more benefits Or loss of this lack of binary standardization?

  Read the article

• Handles Comparison: empty classes vs. undefined classes vs. void*

  - by Nawaz

  Microsoft's GDI+ defines many empty classes to be treated as handles internally. For example, (source GdiPlusGpStubs.h) //Approach 1 class GpGraphics {}; class GpBrush {}; class GpTexture : public GpBrush {}; class GpSolidFill : public GpBrush {}; class GpLineGradient : public GpBrush {}; class GpPathGradient : public GpBrush {}; class GpHatch : public GpBrush {}; class GpPen {}; class GpCustomLineCap {}; There are other two ways to define handles. They're, //Approach 2 class BOOK; //no need to define it! typedef BOOK *PBOOK; typedef PBOOK HBOOK; //handle to be used internally //Approach 3 typedef void* PVOID; typedef PVOID HBOOK; //handle to be used internally I just want to know the advantages and disadvantages of each of these approaches. One advantage with Microsoft's approach is that, they can define type-safe hierarchy of handles using empty classes, which (I think) is not possible with the other two approaches. What else? EDIT: One advantage with the second approach (i.e using incomplete classes) is that we can prevent clients from dereferencing the handles (that means, this approach appears to support encapsulation strongly, I suppose). The code would not even compile if one attempts to dereference handles. What else?

  Read the article

• Detection of negative integers using bit operations

  - by Nawaz

  One approach to check if a given integer is negative or not, could be this: (using bit operations) int num_bits = sizeof(int) * 8; //assuming 8 bits per byte! int sign_bit = given_int & (1 << (num_bits-1)); //sign_bit is either 1 or 0 if ( sign_bit ) { cout << "given integer is negative"<<endl; } else { cout << "given integer is positive"<<endl; } The problem with this solution is that number of bits per byte couldn't be 8, it could be 9,10, 11 even 16 or 40 bits per byte. Byte doesn't necessarily mean 8 bits! Anyway, this problem can be easily fixed by writing, //CHAR_BIT is defined in limits.h int num_bits = sizeof(int) * CHAR_BIT; //no assumption. It seems fine now. But is it really? Is this Standard conformant? What if the negative integer is not represented as 2's complement? What if it's representation in a binary numeration system that doesn't necessitate only negative integers to have 1 in it's most significant bit? Can we write such code that will be both portable and standard conformant? Related topics: Size of Primitive data types Why is a boolean 1 byte and not 1 bit of size?

  Read the article

• Access-specifiers are not foolproof?

  - by Nawaz

  If I've a class like this, class Sample { private: int X; }; Then we cannot access X from outside, so this is illegal, Sample s; s.X = 10; // error - private access But we can make it accessible without editing the class! All we need to do is this, #define private public //note this define! class Sample { private: int X; }; //outside code Sample s; s.X = 10; //no error! Working code at ideone : http://www.ideone.com/FaGpZ That means, we can change the access-specifiers by defining such macros just before the class definition, or before #include <headerfile.h>, #define public private //make public private //or #define protected private //make protected private //or #define so on Isn't it a problem with C++ (Macros/access-specifiers/whatever)? Anyway, the point of this topic is: Using macros, we can easily violate encapsulation. Access-specifiers are not foolproof! Am I right?

  Read the article

• How do i bind my ObservableCollection<T> object in my codebehind to my listbox... Silverlight WP7

  - by Nawaz Dhandala

  This is My codebehind public System.Collections.ObjectModel.ObservableCollection FriendList { get; set; } // I want to bind this to my listbox public Friends() //this is constructor { InitializeComponent(); this.DataContext = this; //I think this is what I'm doing is right....:) } How do I bind my FriendList to the ListBox - FriendList has a property of user.UserName which I want to display it in the TextBlock "friendUsername" Please help!!! Thanks for your answers!!!

  Read the article

• Why do we have reinterpret_cast in C++ when two chained static_cast can do it's job?

  - by Nawaz

  Say I want to cast A* to char* and vice-versa, we have two choices (I mean, many of us think we've two choices, because both seems to work! Hence the confusion!): struct A { int age; char name[128]; }; A a; char *buffer = static_cast<char*>(static_cast<void*>(&a)); //choice 1 char *buffer = reinterpret_cast<char*>(&a); //choice 2 Both work fine. //convert back A *pA = static_cast<A*>(static_cast<void*>(buffer)); //choice 1 A *pA = reinterpret_cast<A*>(buffer); //choice 2 Even this works fine! So why do we have reinterpret_cast in C++ when two chained static_cast can do it's job? Some of you might think this topic is a duplicate of the previous topics such as listed at the bottom of this post, but it's not. Those topics discuss only theoretically, but none of them gives even a single example demonstrating why reintepret_cast is really needed, and two static_cast would surely fail. I agree, one static_cast would fail. But how about two? If the syntax of two chained static_cast looks cumbersome, then we can write a function template to make it more programmer-friendly: template<class To, class From> To any_cast(From v) { return static_cast<To>(static_cast<void*>(v)); } And then we can use this, as: char *buffer = any_cast<char*>(&a); //choice 1 char *buffer = reinterpret_cast<char*>(&a); //choice 2 //convert back A *pA = any_cast<A*>(buffer); //choice 1 A *pA = reinterpret_cast<A*>(buffer); //choice 2 Also, see this situation where any_cast can be useful: Proper casting for fstream read and write member functions. So my question basically is, Why do we have reinterpret_cast in C++? Please show me even a single example where two chained static_cast would surely fail to do the same job? Which cast to use; static_cast or reinterpret_cast? Cast from Void* to TYPE* : static_cast or reinterpret_cast

  Read the article

1