• Advertisement
Sign in to follow this  

Unity A Proposal to Add Strong Type Aliases to the Standard Language

This topic is 1827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I want strong type aliases in C++. I've never written a standard proposal before, so here's my attempt.

 

View PDF online

Download: Word document (20.7kb)

 

Any suggestions, additions, rewordings, and etc... you are able to offer would be much appreciated. After the community reviews and improves it, I'll email it to the standards committee (which are currently accepting proposals for C++ TR2), so it can hopefully be read and discussed at a committee meeting for addition to the C++ standard.

 

Please download the document, annote it in red, and re-post it here. Alternatively, post suggestions in the thread itself.

 

I would really appreciate it! smile.png

Aside from non-static data member initializers, which was added into C++11 (thank you, whoever submitted that proposal!), strong typedefs are one of my most desired C++ features.

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites
Advertisement

Hm... Can I ask why this feature is vital? Conversion between

typedef unsigned int Centimeters;
typedef unsigned int Inches;

are legal as for me, as the real types are the same.

 

For incompatible types gcc (at least) drops an error:

??[santa@yukio ~ $]
?
??> g++ test.cpp -o test -pedantic -Wall
test.cpp: In function ‘int main()’:
test.cpp:9:8: error: cannot convert ‘MyFloat {aka float}’ to ‘MyInt {aka void*}’ for argument ‘1’ to ‘void test(MyInt)’
??[santa@yukio ~ $]
?
??> cat test.cpp 
typedef void* MyInt;
typedef float MyFloat;

void test(MyInt) {
}

int main() {
        MyFloat f;
        test(f);
        return 0;
}

For compatible types you won't get an error even without typedefs:

??[santa@yukio ~ $]
?
??> g++ test.cpp -o test -pedantic -Wall
test.cpp: In function ‘int main()’:
test.cpp:9:8: warning: ‘f’ is used uninitialized in this function [-Wuninitialized]
??[santa@yukio ~ $]
?
??> cat test.cpp 
void test(int) {
}

int main() {
        float f;
        test(f);
        return 0;
}

Share this post


Link to post
Share on other sites
Thanks SiCrane, I assumed there were prior proposals but didn't find them. I'll read over them.
Hm... Can I ask why this feature is vital? Conversion between
typedef unsigned int Centimeters;
typedef unsigned int Inches;
are legal as for me, as the real types are the same.
 
For incompatible types gcc (at least) drops an error: ...

For compatible types you won't get an error even without typedefs: ...
 



That's precisely the point. I don't want Centimeters and Inches to be convertible, except explicitly. Strong aliases should refuse to compile aliases made even from the same base type. You need a function to convert from Centimeters to Inches, because 1 Centimeter is not 1 Inch, and doing myCentimeters = myInches is easy to do and almost always a bug. Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

[quote name='Servant of the Lord' timestamp='1356723633' post='5015148']
I don't want Centimeters and Inches to be convertible
[/quote]

Well and I don't understand why. As I wrote earlier built-in types with similar (in fact equal) semantics _are_ convertible. In your example you are trying to introduce a new type (not an alias in fact, alias is usually just another typename). Simple constructions such as `fancy_typedef old_type new_type' aren't able to describe the type semantics at all (both Centimeters and Inches are just lexems for compiler, you don't define what can be done to them). If you suggest semantics should be copied from the old_type than new_type would be just a typename, not a new type.

Share this post


Link to post
Share on other sites

I don't want Centimeters and Inches to be convertible

 
Well and I don't understand why. As I wrote earlier built-in types with similar (in fact equal) semantics _are_ convertible.



You seriously don't understand why it's desirable to get a compiler error if someone has a quantity in centimeters and tries to use it where a quantity in inches is expected? I am not sure how else to explain it, since SOTL has been very clear.

Share this post


Link to post
Share on other sites

[quote name='Álvaro' timestamp='1356725134' post='5015153']
You seriously don't understand why it's desirable to get a compiler error if someone has a quantity in centimeters and tries to use it where a quantity in inches is expected?
[/quote]

This is not my point. My point is thats not a compiler (c++ grammar) problem. Its worth implementing as a part of an STL.

Share this post


Link to post
Share on other sites

You seriously don't understand why it's desirable to get a compiler error if someone has a quantity in centimeters and tries to use it where a quantity in inches is expected?

 
This is not my point. My point is thats not a compiler (c++ grammar) problem. Its worth implementing as a part of an STL.



Well, it's a problem where the compiler could help, if it implemented what we are discussing.

I have felt the need for something like this when I have classes Vector3D and Point3D, which are essentially the same thing, but I need to define them separately if I want the type system to help me make sure my operations make sense (e.g., you are not allowed to add points, but adding vectors is fine, and so is adding a point and a vector).

Since we are dealing with units, I just wrote this little test that seems to work fine:
#include <iostream>

namespace units {
  template <int m_pow, int kg_pow, int s_pow>
  struct unit {
    double value;
    explicit unit(double value) : value(value) {
    }
  };
  
  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator+(unit<m_pow,kg_pow,s_pow> u1, unit<m_pow,kg_pow,s_pow> u2) {
    return unit<m_pow,kg_pow,s_pow>(u1.value+u2.value);
  }
  
  unit<0,0,0> operator+(unit<0,0,0> u, double d) {
    return unit<0,0,0>(u.value+d);
  }
  
  unit<0,0,0> operator+(double d, unit<0,0,0> u) {
    return unit<0,0,0>(d+u.value);
  }
  
  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator-(unit<m_pow,kg_pow,s_pow> u1, unit<m_pow,kg_pow,s_pow> u2) {
    return unit<m_pow,kg_pow,s_pow>(u1.value-u2.value);
  }

  unit<0,0,0> operator-(unit<0,0,0> u, double d) {
    return unit<0,0,0>(u.value-d);
  }

  unit<0,0,0> operator-(double d, unit<0,0,0> u) {
    return unit<0,0,0>(d-u.value);
  }

  template <int m_pow1, int kg_pow1, int s_pow1, int m_pow2, int kg_pow2, int s_pow2>
  unit<m_pow1+m_pow2,kg_pow1+kg_pow2,s_pow1+s_pow2> operator*(unit<m_pow1,kg_pow1,s_pow1> u1, unit<m_pow2,kg_pow2,s_pow2> u2) {
    return unit<m_pow1+m_pow2,kg_pow1+kg_pow2,s_pow1+s_pow2>(u1.value*u2.value);
  }

  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator*(unit<m_pow,kg_pow,s_pow> u, double d) {
    return unit<m_pow,kg_pow,s_pow>(u.value*d);
  }

  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator*(double d, unit<m_pow,kg_pow,s_pow> u) {
    return unit<m_pow,kg_pow,s_pow>(d*u.value);
  }

  template <int m_pow1, int kg_pow1, int s_pow1, int m_pow2, int kg_pow2, int s_pow2>
  unit<m_pow1-m_pow2,kg_pow1-kg_pow2,s_pow1-s_pow2> operator/(unit<m_pow1,kg_pow1,s_pow1> u1, unit<m_pow2,kg_pow2,s_pow2> u2) {
    return unit<m_pow1-m_pow2,kg_pow1-kg_pow2,s_pow1-s_pow2>(u1.value/u2.value);
  }

  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator/(unit<m_pow,kg_pow,s_pow> u, double d) {
    return unit<m_pow,kg_pow,s_pow>(u.value/d);
  }

  template <int m_pow, int kg_pow, int s_pow>
  unit<m_pow,kg_pow,s_pow> operator/(double d, unit<m_pow,kg_pow,s_pow> u) {
    return unit<-m_pow,-kg_pow,-s_pow>(d/u.value);
  }

  template <int m_pow, int kg_pow, int s_pow>
  std::ostream &operator<<(std::ostream &os, unit<m_pow,kg_pow,s_pow> u) {  
    os << u.value;
    if (m_pow != 0) {
      os << "m";
      if (m_pow != 1)
	os << "^" << m_pow;
    }
    if (kg_pow != 0) {
      os << "Kg";
      if (kg_pow != 1)
	os << "^" << kg_pow;
    }
    if (s_pow != 0) {
      os << "s";
      if (s_pow != 1)
	os << "^" << s_pow;
    }
    return os;
  }

  unit<1,0,0> meter(1);
  unit<1,0,0> centimeter(0.01);
  unit<1,0,0> inch(0.0254);
  unit<0,0,1> second(1.0);
  unit<0,0,1> minute(60.0);
  unit<0,0,1> hour(3600.0);
  unit<0,1,0> gram(0.001);
  // etc.
}

using namespace units;

int main() {
  std::cout << "100 inches/hour = " << (100.0*inch/hour)/(centimeter/minute) << " centimeters/minute\n";
}

Does anyone know if there is a C++ library that does this type of thing? (Oh, and sorry about the hijack...)

Share this post


Link to post
Share on other sites

It would be cool if you could define casting operators for opaque typedefs too*:

// Obviously this would require a few changes to the Standard
Inches operator Centimeters() (Centimeters cm)
{
    // Estimate
    return (cm * 5) / 2;
    // Note that the above is merely example code; I realize that a) the above isn't necessarily the
    // the right data type, and b) casting it to the right data type could cause recursion without some
    // changes or facilities added to the Standard.
}
 
inline constexpr Centimeters operator"" _cm (int cm)
{
    return (Centimeters)cm;
}
 
Inches i = (Inches)(12_cm); // The point of this code is to show this line

 

Also, what would be the implications with promotions? What if you multiplied Inches (which is typedefd as an int) by a float? Or multiplied it by an int?

 

*This is, I would say, related to opaque typedefs, but is also a bit of a separate issue (because declaring a casting operator makes implicit conversions possible, and AFAIK you can't make a casting operator that requires explicit casting). I suppose you could also say it could work for non-opaque typedefs/implicit conversions, but I don't like the ambiguity of Inches i = 12_cm;

Edited by Cornstalks

Share this post


Link to post
Share on other sites

[quote name='Álvaro' timestamp='1356728174' post='5015178']
I have felt the need for something like this when I have classes Vector3D and Point3D, which are essentially the same thing, but I need to define them separately if I want the type system to help me make sure my operations make sense (e.g., you are not allowed to add points, but adding vectors is fine, and so is adding a point and a vector).
[/quote]

 

Ok, I got the idea. Still thats more like a copy of the type, rather than a typedef, so i suggest something like:

 

typecopy unsigned int Centimeters;
typecopy unsigned int Inches;

which should make an exact type copy under the specified name.

 

Also its not clear what to do with types hierarchy. Lets say:

class A {};
class B: public class A {};
typecopy B MyB; // should MyB also be a subclass of A or just copy the public part of an A interface?

Share this post


Link to post
Share on other sites

I can see how this would be useful, but there was one (non technical) thing about the paper that didn't feel right.

 

"(The author of this proposal does not seriously endorse the use of macros for type aliases, and the 

above example was merely used for dramatic effect to trigger the gag reflex of any committee 
members reading this)"
 
I'm not sure if papers like these are an appropriate place for smug jokes, but I would venture they're not.

Share this post


Link to post
Share on other sites

I don't want Centimeters and Inches to be convertible

 
Well and I don't understand why. As I wrote earlier built-in types with similar (in fact equal) semantics _are_ convertible.

 


You seriously don't understand why it's desirable to get a compiler error if someone has a quantity in centimeters and tries to use it where a quantity in inches is expected? I am not sure how else to explain it, since SOTL has been very clear.

 

How about this:

 

class Inch
{
	float mValue;
};

class Centimeter
{
	float mValue;
};

int main(void)
{
	Inch i;
	Centimeter c = i;

	return 0;
}
test.cpp : error C2440: 'initializing' : cannot convert from 'Inch' to 'Centimeter'
        No constructor could take the source type, or constructor overload resolution was ambiguous
 

 

Am I missing something?

Share this post


Link to post
Share on other sites
 
I can see how this would be useful, but there was one (non technical) thing about the paper that didn't feel right.
 
"(The author of this proposal does not seriously endorse the use of macros for type aliases, and the 
above example was merely used for dramatic effect to trigger the gag reflex of any committee 
members reading this)"
 
I'm not sure if papers like these are an appropriate place for smug jokes, but I would venture they're not.

Good point - I was trying to inject a spot of humor, but yeah, probably not the right place to do so.
How about this:

class Inch
{
	float mValue;
};

class Centimeter
{
	float mValue;
};

int main(void)
{
	Inch i;
	Centimeter c = i;

	return 0;
}
 
Am I missing something?



Yes, that makes the entire language very clunky. I would hate to have to do this:
myInch.mValue = 17;
myCentimeter.mValue = 35;

Share this post


Link to post
Share on other sites
How about this:

class Inch
{
	float mValue;
};

class Centimeter
{
	float mValue;
};

int main(void)
{
	Inch i;
	Centimeter c = i;

	return 0;
}
 
Am I missing something?

 


Yes, that makes the entire language very clunky. I would hate to have to do this:
myInch.mValue = 17;
myCentimeter.mValue = 35;

 

 

First, that code will not compile because mValue is a private member.  Second, you can define the constructors and assignment operators so that you dont need to directly access mValue at all.  Yes, there's some code you need to write for the class, but using it would be no different from using a built-in type, and you actually now have more flexibility in what operations you can do on your types and how to convert them, which get automatically converted and which result in compile errors, etc.

 

So I still dont understand why simply using a class is not an acceptable solution.  You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.

Share this post


Link to post
Share on other sites
So I still dont understand why simply using a class is not an acceptable solution.  You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.


The point is that we don't want to have to write identical classes if we can help it.

Here's another example:
struct Vector3D {
  double x, y, z;
  
  Vector3D(double x, double y, double z) : x(x), y(y), z(z) {
  }
  
  void print(std::ostream &os) const {
    os << '(' << x << ',' << y << ',' << z << ')';
  }
};

struct Point3D {
  double x, y, z;
  
  Point3D(double x, double y, double z) : x(x), y(y), z(z) {
  }
  
  void print(std::ostream &os) const {
    os << '(' << x << ',' << y << ',' << z << ')';
  }
};

It would be nice to say "a Point3D works exactly as a Vector3D". A typedef would allow that, but then you won't actually get two separate types.

Share this post


Link to post
Share on other sites
First, that code will not compile because mValue is a private member.  Second, you can define the constructors and assignment operators so that you dont need to directly access mValue at all.  Yes, there's some code you need to write for the class, but using it would be no different from using a built-in type, and you actually now have more flexibility in what operations you can do on your types and how to convert them, which get automatically converted and which result in compile errors, etc.
 
So I still dont understand why simply using a class is not an acceptable solution.  You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.
 
No, I want a new type with identical data and identical behavior, with the only change being no implicit conversion between the original type and the derivative.
It'd be a huge amount of unnecessary boilerplate code for virtually identical classes.
 
Here's a copy+paste of real code from my current project, using my macro version (which hides all the boilerplate, but has some flaws):
strong_typedef(cPoint, SubTileLoc, Point); //The position (in tiles, not in pixels) of a tile within a tileset image.
strong_typedef(cPoint, PosInImage, Point); //The pixel position in an image.

strong_typedef(cPoint, PosInMonitor, Point); //The position (in pixels) in the monitor itself.
strong_typedef(cPoint, PosInWindow, Point); //The position (in pixels) in the game window's client area.
strong_typedef(cPoint, PosInVirtualWindow, Point); //The position (in pixels) in the game's window, after accounting for the virtual window size.

strong_typedef(cPoint, PosInWorld, Point); //Position within the world, in pixels.
strong_typedef(cPoint, VisiblePosInWorld, Point); //Position within the loaded portion of the world, in pixels.
//strong_typedef(cPoint, PosInArea, Point); //Might be needed in the future (if I ever allow multiple _areas_ side by side).
strong_typedef(cPoint, PosInCell, Point); //Position within a cell, in pixels.
strong_typedef(cPoint, PosInTile, Point); //Position within a tile, in pixels.

strong_typedef(cPoint, TileLoc, Point); //The position of a tile within a cell, in tiles (not pixels).
strong_typedef(cPoint, CellLoc, Point); //The position of a cell within the area, in cells (not pixels).
strong_typedef(cPoint, VisibleCellLoc, Point); //The position of a cell within the loaded chunks, in cell (not pixels). VisibleCellLoc(0,0) is usually the cell the player is in.

strong_typedef(cPoint, TileOffset, Point); //The offset from the grid, in pixels, at which a tile is drawn. (0,0) is aligned with grid.

strong_typedef(cRect, AreaBounds, Rect); //Bounds of the area, in cells.
Ignore the third parameter, and read it as "typedef cRect AreaBounds;". (The 'c' in my classes are part of an abbreviated namespace, and do not stand for 'class'. Only a few basic times have that prefix)

Notice a common theme there? 13 of the 14 strong typedefs actually are identical classes. You'd have me manually create 13 different classes? No, I wouldn't bother. One or two, maybe. But since it's so easy with a good strong typedef, I can do a dozen with zero extra programming work, and gain the following benefits for free:
1) The code is more self-descriptive. cPoint is generic name, CellLoc tells much better what the variable is, so the variable name can tell its use. Example: "CellLoc centerCell;"
2) Compile-time bug catching of simple mistakes where data of one type (like inches, or tiles) is given when another measurement (like centimeters, or pixels) is expected. This is the primary motivation for me doing this, after several times (over the course of my current multi-year project) I got burned by subtle bugs that the compiler could've caught (and now does!) where I made a simple mistake that went uncaught for quite awhile. After implementing the system and recompiling, the compiler balked and gave a false positive... so I thought, until I looked closer and realized it caught a bug that I didn't yet know existed.

Again, it takes zero programming effort to get these benefits, if strong typedefs are available. Regular typedefs provide the first benefit only, and people only use regular typedefs in less than half the situations where they'd be beneficial, because the benefit they provide is so minor. Mostly people use typedefs for minimizing the typing work they have to do on long class names (which is a valid usage), instead of using the benefits of typedefs to increase code clarity.

My typedef'd items above may have gone a little overboard, and two or three of them probably don't make much sense (but do no harm either). The rest are very significant improvements to the readability and stability of my code. Edited by Servant of the Lord

Share this post


Link to post
Share on other sites
So I still dont understand why simply using a class is not an acceptable solution.  You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.
 

The point is that we don't want to have to write identical classes if we can help it.

Here's another example:
struct Vector3D {
  double x, y, z;
  
  Vector3D(double x, double y, double z) : x(x), y(y), z(z) {
  }
  
  void print(std::ostream &os) const {
    os << '(' << x << ',' << y << ',' << z << ')';
  }
};

struct Point3D {
  double x, y, z;
  
  Point3D(double x, double y, double z) : x(x), y(y), z(z) {
  }
  
  void print(std::ostream &os) const {
    os << '(' << x << ',' << y << ',' << z << ')';
  }
};

It would be nice to say "a Point3D works exactly as a Vector3D". A typedef would allow that, but then you won't actually get two separate types.

 

So, like this?

 

class UnitOfLength
{
public:
	// Add your constructors and overloaded operators here

private:
	float mValue;
};

class Inch : public UnitOfLength {};
class Centimeter : public UnitOfLength {};

int main(void)
{
	Inch i;
	Centimeter c = i;	// <--- compile error

	return 0;
}

Share this post


Link to post
Share on other sites

The constructors don't get exposed when you do that, so you'll have to rewrite them for Inch and Centimeter. Also, you can't do that with primitive types.

 

Of course there are alternative ways to do this, but having this feature in the language would make certain things easier, that's all.

Share this post


Link to post
Share on other sites
The constructors don't get exposed when you do that, so you'll have to rewrite them for Inch and Centimeter. Also, you can't do that with primitive types.

 

Of course there are alternative ways to do this, but having this feature in the language would make certain things easier, that's all.

 

Ahh, that's right, I forgot that the constructors and operators wont be inherited and you'll need to declare them in the child classes.

 

Ok, I can see where the motivation for this comes from, but on the other hand I've never seen a real case where I'd save enough typing/code duplication to make me want this.  In the Inch/Centimeter example, it's only 2 classes.  But even if more, this is stuff that you write once and then it'll sit in a lib untouched afterwards.  And, with a class you do get the additional abilities like operator overloading, and controlling which ones to allow and which to not allow.

 

In the code sample you gave... it just seems out of control.  You really just need a single 2D Point object (you have 13!), but somehow it looks like you're trying to prevent your high-level code from doing the wrong thing by moving your error checking to the lowest levels, and in doing so actually making more work for yourself with all these different typedefs that all cant be automatically cast to each other.  If I saw this code anyplace I worked I'd seriously have to wonder what the heck was going on.

Share this post


Link to post
Share on other sites

[quote name='0r0d' timestamp='1356845707' post='5015653']
In the code sample you gave... it just seems out of control.  You really just need a single 2D Point object (you have 13!), but somehow it looks like you're trying to prevent your high-level code from doing the wrong thing by moving your error checking to the lowest levels, and in doing so actually making more work for yourself with all these different typedefs that all cant be automatically cast to each other.  If I saw this code anyplace I worked I'd seriously have to wonder what the heck was going on.
[/quote]

 

I guess that paragraph was responding to SOTL, not me. I'll reply anyway. :)

 

I have to admit that those 13 classes seem a little overwhelming, but I don't see his code as moving error checking to the lowest levels. It is simply making the type system work for him, by forbidding operations that are most likely bugs. I can see myself doing something similar for vertices in a 3D pipeline: If you add model coordinates and world coordinates together, you probably have a bug, and having separate types for them makes total sense.

 

At work we deal a lot with orders to buy or sell stocks. Whenever I use a double in that context, I actually know more about it than that: It's an order size in shares, or a price in dollars/share, or a price in euros/share, or a dollar value for the order (or sometimes more exotic things, but let's keep it simple). It would make total sense to use separate types for these things, although in the end they are all just doubles when you get down to assembly level. I just would like my compiler to bomb if I ever try to add a quantity and a price.

Share this post


Link to post
Share on other sites
Ahh, that's right, I forgot that the constructors and operators wont be inherited and you'll need to declare them in the child classes.
Though see n2141 and forwarding constructors in C++11.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By BTO_Dev
      Hi Guys, I am developing an Online Multiplayer game and I am creating devlogs every few weeks and it will be great if you could subscribe! I also upload other videos that I assume could help you too  
       
      THANKS FOR READING!
    • By 3dmodelerguy
      So I am building a turn based rogue-like (think CDDA). The game is going to have a very large map (up to 1000's x 1000's) however to alleviate most of that I obviously can't render everything so there will just be render a certain radius around the player and just load in and out data as the player moves.
      The next major system I am prototyping is making interactive tiles destructible and pretty much everything will be destructible besides basic landscape (cars, doors, windows, structures, etc. will be destructible)
      While I am only rendering a certain amount of tiles around the player, I want to keep the amount of colliders active at one time to be as small as possible for performance and currently the tilemap tool I use automatically merges colliders together.
      So instead of creating a separate colliders for each of these tiles and having the destructible behavior tied to that object (which my tilemap tool would allow me to do) I was thinking that I would store an array of all the X and Y locations for the interactive tilemap layer and let the tilemap manage the colliders. 
      Then when I hit a collider on the interactive tilemap layer, instead of of getting the behavior for how to deal with the destruction for that tile from that game object, I would pull it from the array I mentioned earlier based on the tile I attempt to interact with which I already have.
      Does this sound like a good approach? Any other recommendations would be welcomed.
    • By NDraskovic
      Hey guys,
      I have a really weird problem. I'm trying to get some data from a REST service. I'm using the following code:
       
      private void GetTheScores() { UnityWebRequest GetCommand = UnityWebRequest.Get(url); UnityWebRequestAsyncOperation operation = GetCommand.SendWebRequest(); if (!operation.webRequest.isNetworkError) { ResultsContainer rez = JsonUtility.FromJson<ResultsContainer>(operation.webRequest.downloadHandler.text); Debug.Log("Text: " + operation.webRequest.downloadHandler.text); } } The problem is that when I'm in Unity's editor, the request doesn't return anything (operation.webRequest.downloadHandler.text is empty, the Debug.Log command just prints "Text: "), but when I enter the debug mode and insert a breakpoint on that line, then it returns the text properly. Does anyone have an idea why is this happening?
      The real problem I'm trying to solve is that when I receive the text, I can't get the data from the JSON. The markup is really simple:
      [{"id":1,"name":"Player1"},{"id":2,"name":"Player2"}] and I have an object that should accept that data:
      [System.Serializable] public class ResultScript { public int id; public string name; } There is also a class that should accept the array of these objects (which the JSON is returning):
      [System.Serializable] public class ResultsContainer { public ResultScript[] results; } But when I run the code (in the debug mode, to get any result) I get an error: ArgumentException: JSON must represent an object type. I've googled it but none of the proposed solutions work for me.
      Also (regardless if I'm in the debug mode or not) when I try to do some string operations like removing or adding characters to the GET result, the functions return an empty string as a result
      Can you help me with any of these problems?
      Thank you
    • By nihitori
      The Emotional Music Vol. I pack focuses on beautiful and esoteric orchestral music, capable of creating truly emotive and intimate moods. It features detailed chamber strings, cello and piano as the main instruments, resulting in a subtle and elegant sound never before heard in video game royalty-free music assets.

      The pack includes 5 original tracks, as well as a total of 47 loops based on these tracks (long loops for simple use and short loops for custom / complex music layering).

      Unity Asset Store link: https://www.assetstore.unity3d.com/en/#!/content/107032
      Unreal Engine Marketplace link: https://www.unrealengine.com/marketplace/emotional-music-vol-i

      A 15 seconds preview of each main track is available on Soundcloud:
       
    • By RoKabium Games
      Another one of our new UI for #screenshotsaturday. This is the inventory screen for showing what animal fossils you have collected so far. #gamedev #indiedev #sama
  • Advertisement